We are going to have a Java Key Store which will store certificates & public/private keys. This keystore will be protected with the password. However, access to the keystore is only from the program. There is no way of providing input as it is only based on api access.
What is best place to store the Java keystore password & in what format it should be stored?
If you hope to keep the private keys out of the hands of whoever runs your program, then it will not work. Secrets embedded in code do not resist reverse engineering (especially when using Java, which is quite easy to reverse-engineer).
Though you do not give any detail about your situation (you just say "Java" and "the program"), I can give the following generic advice: arrange for your private key to be user-specific, and such that it is the user's best interest that the private key remains private. In that case, the user will collaborate to the key security. You may then store the private key (or a password which unlocks the private key) in the Java preferences.
This is a really good question and I would like to see more good answers. Here are the ones that I am aware of:
Of these the first is the most common and often the password is 'password' or 'changeit' etc. The second option might seem better at first glance but it's hard to explain how exactly. The last option is probably the only one that has a hope of doing anything meaningful. I know of vendor solutions that do this kind of thing and claim to improve security.
The fundamental issue here is that if an attacker is on the host with enough access to see the application space, there's really nothing you can do to keep them from getting this password. At some point it must be in memory in the clear.
As I see it, the password on the keystore protects it mainly in situation that the keystore itself has been retrieved from the machine without actually having access to that machine directly. With that file, an attacker can hammer it at will to get the secrets out of it. If you don't have a strong password on it, game over. If the attacker can pull that file, then they likely can pull other files that the password could be stored in. This puts options 1 and 2 in doubt.
As far as the 3rd option goes, the problem now moves to how you authenticate the clients in order to retrieve the password. I know there are a number of schemes for doing this such as depending on the host/network and using signatures on the binaries. You could have an entire discussion just on how to do this and what level of protection it brings.
I am in the process of finishing up a Java application that will run a Grizzly web/REST server. The entire application will be deployed as a VM image product that people can purchase in the Microsoft Azure cloud.
In my situation I want the customer to be able to run my product's web server on the domain name of their choice. This requires that the customer go through the process of acquiring a domain name and the associated keys. Those keys will be installed into a key/trust store located on the VM where the web server will be running. My application allows the user to provide the keystore and truststore file paths and passwords three different ways:
If the user is comfortable that no one will ever scroll back through the command window, they can use option #1.
If the use is comfortable putting those details in a properties file on the server, they can use option #2.
Using option three ensures that the passwords are never stored on disk and can't be recovered from the command window. But, it also means that a user must be present to restart the server.
