Welcome Brian. I like your pragmatist when you say that it's better to have a moderate level of security consistently implemented, than to have probably perfect security implemented inconsistently or incorrectly because of its complexity. I want to ask you, following that point of view, what do you consider the best approach for a simple but often scenario: Let's say a non very complex servlet/jsp app which main security issue is how to keep the user/pass of a database protected. MD5 hash? pass for a properties file? pass stored in the servlet code? I know people using very different ways, and it seems a so often case that the sec issue should be already "standard"...what do u think? Thank u.
One easy solution is to use the deployment descriptors. They aren't available to public Internet, are easily accessible from code, and the files can be secured using OS features so that the authority who started the application server can read the files.
You are right, but that solution implies some system level security. What if i don't want the person who starts up the server to read(and be able of "understand") my files? I can not encrypt the deployment descriptors. I can redo the question as: From the point of view of the app-level security, what would be a good implementation for a within reason sec level?
To quote 'Cool Hand Luke': "If you can't trust the trustee, who can you trust?" We have three (actually more) instances of our applications: Development, Integration, and Production. Integration and Development are essentially locked-down instances. Only those who are blest can access these servers. Top clearance. I LOVE the idea of putting usernames and passwords in deployment descriptors. That we we can write code that access those attributes, and not have to worry about which instance we are in. Our code has no idea where it is running. Great. Eventually you have to trust someone. At least this way, you know who you are trusting.
Good points so far! Password storage is a common problem... The only thing I would add is that whether the passwords are stored in the DD (as an init param) or in a properties file loaded as a resource, or as an entry in the java:comp/env namespace, or even on a remote server loaded via a client-cert authenticated HTTPS connection, an effective technique is to encrypt the passwords (then base 64 encode them) before you put them in the file. That way, a casual observer of the file can't discover the password. They see the encrypted password. Your app reads the encrypted password (from whatever source) and decrypts it. A small application can be written to encrypt passwords for use in this way. You need to use encryption though (DESede, Blowfish, etc) instead of a digest (MD5, SHA-1) because you have to be able to retrieve the plaintext password from the ciphertext. <PLUG>There are several examples in the book of using symmetric encryption to encrypt text</PLUG> By writing about 10 lines of code, you've raised the stakes even higher... Now someone has to breach the server, and get your secret key in order to get the password. And, you've shielded it from casual observation by the sysadmins (or someone looking over their shoulder). Another common solution is to use DataSources and then handle the authentication at the naming service level (the DataSource is pre-configured to contain the correct DB password). The DS can be bound into a locked-down context of the naming service, then mapped at deployment time to the app namespace (using java:comp/env and ResourceReferences). Now, only the application can access the datasource (it's in the apps private namespace) and the credential information is in the DataSource, not in a file on disk somewhere. The application doesn't know the DB credentials, and they're not apparent to the server admin either. If you'd prefer for your application group to manage the DB credentials for your app, use the encrypted credential in the DD or environment. If you want admins to manage them (and keep your application unaware), use DataSources (of course, some DataSources aren't too secure either, so check that out before following this path). Hope this helps... [ October 22, 2002: Message edited by: Brian Buege ]
Brian Buege<br />Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0072225653/brivacom-20" target="_blank" rel="nofollow">Hacking Exposed J2EE & Java: Developing Secure Web Applications with Java Technology</a><br />Visit the <a href="http://www.hackingexposedjava.com" target="_blank" rel="nofollow">Companion Website</a>
A magnificient life is loaded with tough challenges. En garde tiny ad: