Where do you store your secret key in a Java Web Application? [closed]

Question

Cryptography is a widely adopted techonlogy to ensure confidentiality. Not considering implementation flaws, it has a single critical point: the secret key storage. If the secret key is stolen, the whole system will be compromised.

EDIT :

let me specify the context to make the question less broad:

1. here a java web application is addressed
2. more specifically it is used the spring framework version 3
3. spring security 3.1 is used to secure the application
4. a mysql5 database is available
5. the application server is tomcat6 or tomcat7
6. the server machine is not under my control

Maybe the questions can be focused on this scenario but, as pointed out, the problem of the secret key storage is transversal to the adopted technologies. However some libraries might offer peculiar features that can somehow facilitate the work. A clear point is that a tradeoff has to be found between security and the need to do practical things. To complete the analysis it is obvious that the required security level depends on the value of information to secure. It is senseless to flip our minds to enforce super-secure strategies (demanding a very lot of efforts) to keep secret the shoe size of a customer.

Here, I have to secure an email password (that will be stored in a db). I consider this information average critical.

What I'm looking for here, is the best solution with reasonable effort.

So the question is very clear: where would you store this information?

1. do you store it in a database? So it should be encrypted and this requires another key (and where do you store this second key?)
2. do you store it inside the .war package? How do you prevent unauthorized accesses to the sources?
3. do you adopt a different strategy?

motivations for your strategy will be appreciated. thank you

Answer 1

I take the liberty to write an answer even if this doesn't have anything to do with a Java Web Application: I think the problem exists in only minor variance with all platforms.

Basically there are 3 candidates for key storage, the first 2 of which you mentioned:

• The DB
• The App ("hardcoded")
• Somewhere else on the server, that runs the WebApp, most often a file

You already put your finger on the weak points of the first 2, so no need to repeat, I fully agree.

This is also the motivation for me to use the third candidate. The reasoning is this:

• Different instances of the same app can easily have different keys, so a compromise of one will not automatically spread to all others
• If the server is compromised in a way, that allows the attacker to read any file, it is game over anyway: You wouldn't be able to stop him from reading the app binary or the DB
• File system security on a web server is a quite well-understood subject
• Break-ins, that allow full filesystem access are statistically much less often, than application or database break-ins

Answer 2

No matter what you always need to store somewhere the secret key. Even if you decide (which is silly) that you provide key manually, then the key resides in memory and someone can find it.

Where you store it depends on your choice. However it should not be in plain text. So if you store a key in database, then use hard-coded secondary key in application. So if intruder has only access to db, then the encrypted main key is protected.

I would go for application configuration to store secondary key in container. That way only your application will have access to this properties. So the attacker will have to take control over your application or container to get access to that key.

So assuming following scenarios:

1. Your application get hacked: attacker has the same permissions as you have. One can try to use your API to get sensitive information without playing at all with encryption. Your code will do it for them. Next option: she can try to get your war file or class files and decompile them to find out the hard-coded key, or learn about encryption mechanism you used.
2. Only database is hacked: you should be fine having data encrypted with the key that is not in database itself.

To make it harder for attacker. You can place file in file system. As described in other answer add appropriate FS permissions to it. But additionally use java Security Manager to restrict access for all java classes except the one that really needs to read it. Also restricting modification to your jar and class files would be a good idea.

The more locks you have the more secure you are. As it is with standard door lock. The locks should be from different vendors and with different mechanisms. But at the end the skilled burglar will get into anyway.