Originally posted by Sam Moran:
Brian, at our company one of our web servers takes a lot of hits. It is an NT box running IIS, with Domino DBs. Is there a way, through a servlet, to monitor ports and kill any requests from hackers? Does your book cover instances like this? Thank you very much.
Originally posted by Ahmad, Usman:
Ok, so I was aked to make this JSP website the other day. Now this site is no ordinay site. It requires approvals of some of the REALLY BIG shots in our organizations so it has to be air-tight secure. I have Websphere 4.0.2 Application Developer Studio and WepSphere app Server. Any suggestions are welcome coz I am totally lost where to begin.
Originally posted by Bill Ngu:
Could someone tell me how can I implement a MD5 method for my password field ?
Originally posted by Tom Stevns Nielsen:
Hello Brian Buege !
Please mention some of the most "popular" ways
to java-hack into an application server, a WAS 4.0 as an example.
And especially how to avoid them
Thanx in advance
Originally posted by Michael Zalewski:
The MD5 digest of your password will now be in abDigest. The digest is always the same length -- I forget how many bytes exactly. It will also be binary, so it may not store into a database CHAR or VARCHAR column without further encoding.
Originally posted by Ahmad, Usman:
... It requires approvals of some of the REALLY BIG shots in our organizations so it has to be air-tight secure.
Originally posted by Rick Rodriguez:
I have a really dumb question. What is the difference between "system-level" and "app-level" security?
It would seem to me that if the system-level security is "lax", then the application is "open" to attack, as far as getting information packets that it may be sending across the network.
Given this, it would seem that the application does not have a chance against a hacker that is already in the "system".
Could you help me to clarify this Brian, in terms of your expertise?
Originally posted by Daniel Ng:
Are there any examples on password encryption in the book?
Originally posted by Ben Sullins:
I am interested in EJB security, and I would like to hear what you have to say on the subject. Other than the access control provided by security roles, what are some other things I can do to secure my EJBs? Is that open-ended enough?
Originally posted by Roger Goerke:
The J2EE specification speaks directly to Security and has several goals that are clearly explained. It also has specific non-goals. One of the non-goals that puzzles me is this:
This specification does not mandate a specific security technology, such as
Kerberos, PK, NIS+, or NTLM.
Could you briefly compare/contrast the Security technologies listed (Kerboros, PK, NIS+ and NTLM) and identify vendor(s) that use them? Is PK the Public Key Infrastructure touted by IBM?
Originally posted by Rick Salsa:
What's your take on the security interface used provided by most app servers? I have yet to use it in an application myself, but I'm told that is it very unflexible.
I guess I'm looking for something more dynamic that is configurable at runtime. From what I can make out, most container provided security features must be defined in descriptors when deploying.
Is there any way to get around this or do you need to roll your own?
Also, does the book mention securing client-server communication? How does that work, ssh tunneling?
Sorry for the load of questions. Thanks in advance!
Originally posted by Brian Buege:
Both great questions!!
Here are a few answers (I'll start from the bottom and work up):
The book includes working sample code for a Java-based SSL tunnel using the JSSE. It also discusses other tunneling products like stunnel. And it discusses them specifically in the context of securing a client-server app. AND, it has working sample code that includes a standalone client talking JDBC to a database, an applet client talking JDBC to a database, and a Java Web Start client talking JDBC to a database.
I think that one of the common misconceptions about J2EE security is that it's inflexible. I haven't found that to be the case. There are some things that it doesn't do well, but that's the case with any product.
For example, in SQL it's hard to do some things, but most people would think you were nuts if you suggested rolling your own database. It's kind of the same with J2EE security. There's some stuff that isn't elegant, but I haven't found anything that I couldn't work around yet... Again, just like SQL queries.
J2EE security provides for both declarative (specified in the deployment descriptor) and programatic (handled at runtime) authorization. This allows you to have the best of both worlds: For simple stuff, you can use the authorization in your DD, then when you need to get dynamic, you can interrogate your container to find the identity of the person calling your method and make authorization decisions in your code.
With the advent of JAAS in the newest app servers, this dynamic capability is increased even further and the possiblities are pretty endless.
If you'd like me to be more specific about any of the generalizations I've made above, let me know...
[ October 22, 2002: Message edited by: Brian Buege ]