Where to put keystore password

Question

I am sure this topic has been discussed.. but the forum search seems to be cactus at the moment so:
I have a keystore (java.security.KeyStore) into which I am putting encryption keys (as you would expect). I need to encrypt data because although it's on a server behind a firewall, it's pretty important info. I am securing the keystore with a password, but I now have a problem of what to do with the password. I can't store it in a database because I am using one of the keys from the keystore to encrypt the configuration file used to access the database (again, for security).
I realise that there will always be one weak point in the system, but I was wondering what the best-practice approach for storing keystore passwords was.
A couple of considerations:
1. I am in a web (tomcat) environment
2. I don't have (and don't want to have) an EJB layer
3. I can't leave it up to the user to enter, because I (the system) needs to encrypt/decrypt data without the user's intervention
4. I can't store it in the database as already mentioned
5. I can hard code the password(s) in compiled java code, but this can be decompiled and it means I can change them (easily)
Any ideas?

Answer 1

There are three key questions you have to answer before you can do "the right thing" for your environment in this context. The first is, "How much do you trust the physical security of your hardware?" The second is "How hard do you need to make life for would-be Bad Guys?" And the third is "How hard are you willing to make life for your sysadmins?"
Take #3, for example. If you're willing to make your admins miserable, or pay for 24x7 on-site coverage - don't write your ultimate key down anywhere, ever. When your system goes down, an admin has to restart it by re-entering the password/key info for unlocking all of your secrets. This approach chooses security over convenience in a very large way.
#2 and #1 are interrelated. If you trust your machine-security, you can make life hard for the Bad Guys even while leaving your startup password in the clear in your init scripts. If you don't trust your system too much, but you only care about deterring the "casual cracker," then you can do the same. If you want to make life REALLY hard for the Bad Guys, you can't leave the key available anywhere near your machine - even the specialized hardware approach can be defeated by a dedicated assault that has access to the machine. (At which point, you need to see #3 above).
In general, putting the key into your .class files is always the wrong answer. You can't change the password without recompiling, and everyone who uses the app is forced to have the same password, which is A Bad Thing. In addition, it's no more secure than having the pasword in a config-file that's protected to the same degree as the classfile itself. If the JVM can read the classfile, it can find and read a config file - and if a Bad Guy could find the plaintext config, he can find the classfile and extract the password nearly as easily.
In the vast majority of cases, keys in config files protected by the OS of the server machine will keep your system's secrets safe while allowing for "hands off" restarts. In the small number of instances where that's not sufficient, be prepared to pay a heavy price in hardware and convenience.
Grant