What is the point of the Java keystores (JKS, JCEKS) when the keystore password is just as vulnurable as the keys themselves?

Question

I have some code that encrypts some user data. Currently I have the key stored in a configuration file that gets loaded at runtime. This sucks for a number of reasons, namely that if someone gets access to the config file they have access to the secret key. So I started looking into the Java keystores, but I can't seem to justify them. The keystores require a password, which would be just as vulnerable as hardcoding the key. Am I missing something, or do key stores suffer the same weaknesses as hard coding the secret keys?

Answer 1

By using the JKS or any keystore really you are taking the first step toward offloading the key protection requirements from your application or server to the keystore or the user of that keystore. There are plenty of guidelines for protecting keys and keystores that can get quite fancy (HSM's, etc..), but leveraging the JCE architecture is just first step. In the meantime might as well start baking security into your application.

https://security.stackexchange.com/questions/11517/storage-of-secrets-keystores-hsms-and-the-rest

Answer 2

A common architecture I see is the application encrypts the data using a private key, or the application must decrypt database credentials for a specific dev/test/prod environment. Developers commit code and configuration to a code repository. However, the key used to encrypt/decrypt is created by another team and stored somewhere else. When the server or container is deployed, the keystore is deployed with it. The codebase including the configuration files is built and deployed onto the the server. The developer never have access to the decryption keys, the keys are never in the code repo.