How is passphrase for a keystore to be stored? we have all passwords encrypted and the key to encrypt is stored in keystore , so how is the passphrase for the keystore to be stored? in clear text? if encrypted then where should we store the key to encrypt? ie seems recursive issue, how to solve without using Hardware security product HCM or whatever acroynm is for that kind of stuff. what is best practise in terms of storing the keys for encryption?
3 Answers
Best practice is not to encrypt the passwords at all, but to hash them instead, for precisely this reason: if you encrypt, then you need to have the key available to the server.
If your system is such that it absolutely MUST store the actual passwords - for example, your server connects to some other service impersonating the user - then there are a few things you can do, like using an HCM, or storing the key on a different server in the hope that it doesn't get stolen along with the main one, or using something like OAuth so that the credentials you store are only usable by the server and hence of less use to an attacker.
But these are only partial mitigations. If you store passwords on the server then the server knows them and if someone compromises the server they can learn them too.
-
but what about passwords for database connections etc... if you one way encrypt ie hash, how do you compare the two to allow access for the connection. is there no way to store encyrpt / dycrpyt passwords easily . from what i understand you would have the password somewhere offline - (poss deployment team) use its md5 hash in properties file compare that to a equally computed md5 from database and allow connection etc??? and never have the actual password in code or server - is this correct understanding?– blissApr 28, 2014 at 11:04
-
how do i hash the password for a keystore? and how do i then use the hash to retrieve something from keystore?– blissApr 28, 2014 at 12:25
The best way of doing this, in my understanding, is to hash the passwords and not encrypt them. Yes hashing is a one way method, but you don't need to retrieve the passwords anyway, so being one way is pretty much what you want.
Imagine that a user sends you his username and his password in order to authenticate. In this scenario you just need to hash the incoming password and compare it with the one you have stored, also hashed, associated with that username. If you have a match you can authenticate the user.
They should be stored in plaintext, or base64 encoded. You can refer to how Tomcat is configured
<!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->
<Connector
protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"
keystoreFile="${user.home}/.keystore" keystorePass="changeit"
clientAuth="false" sslProtocol="TLS"/>
If your encrypted text is in the database, then this method can only protect you if the attacker get hold of the database but do not have access to the filesystem to discover the passphrase. If the attacker are able to get access to the filesystem, then you will be out of luck here.
The only other method is to get the user to key it in everytime the application runs, which is cumbersome and not very common.
