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