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 ]