aspose file tools*
The moose likes Security and the fly likes keystore password Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "keystore password" Watch "keystore password" New topic
Author

keystore password

John Pradeep.v
Ranch Hand

Joined: Jul 21, 2008
Posts: 59
Hello All,
I am aware that keytool creates a keystore and restricts access to the keystore without a keystore password. I just want to understand where does the keytool store the "keystore password" itself? how does it secure the "keystore password"

Thanks,
John
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

John Pradeep.v wrote:Hello All,
I am aware that keytool creates a keystore and restricts access to the keystore without a keystore password. I just want to understand where does the keytool store the "keystore password" itself? how does it secure the "keystore password"

Thanks,
John


It doesn't need to directly secure the password. All it needs to do it be able to prove that the password presented is the almost certainly the same as the one used originally so it only needs to store a non-invertible secure digest (such as sha-1) of the password. It can then be used through some form of PBE to encrypt the content of the keystore.

Retired horse trader.
 Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.
John Pradeep.v
Ranch Hand

Joined: Jul 21, 2008
Posts: 59
James Sabre wrote:
It doesn't need to directly secure the password. All it needs to do it be able to prove that the password presented is the almost certainly the same as the one used originally so it only needs to store a non-invertible secure digest (such as sha-1) of the password. It can then be used through some form of PBE to encrypt the content of the keystore.


Thanks James... i know my next question is more of an implementation detail, but consider the case that if keytool stores the password as a secure digest, it should store it somewhere in the file system and as a result there could be a case where someone can manually replace the message digest with a valid digest of a different password. it is leading to a chicken and hen kind of problem

but i am just curious to know what level of measures has been taken in keytool against such attacks, and i do admit that this would be lead to a more fundamental question of how to store sensitive information, but i have taken keytool as a example to understand a practical implementation which has been accepted already.




James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

How would this help the attacker? It would be very poor security if it were as simple as this.

I can't vouch for the detail (you might get that from looking a the source in the openjdk project) but it is my understanding that the password does more than just authenticate the user. Using some form of PBE it encrypts the key store so without the correct password you can't decrypt the keystore to get at the keys. Knowledge of the digest of the password does not help at all - the password is required.
John Pradeep.v
Ranch Hand

Joined: Jul 21, 2008
Posts: 59
James Sabre wrote:How would this help the attacker? It would be very poor security if it were as simple as this.

I can't vouch for the detail (you might get that from looking a the source in the openjdk project) but it is my understanding that the password does more than just authenticate the user. Using some form of PBE it encrypts the key store so without the correct password you can't decrypt the keystore to get at the keys. Knowledge of the digest of the password does not help at all - the password is required.


James, I understood your point, may be i didnt put the question properly... the sensitive details like the private key etc which is stored in the keystore is safe, i agree to that!! it is safe because of the password protection. but my question is how the tool would have safe gaurded the password itself before storing it somewhere in the file system. for which i guess it can store the digest of the password which is irreversible for someone to extract the password out of the message, but the question here is that anyone can easily "replace" the digest itself.

James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

You have lost me. The password is not stored anywhere! There is no need to store it anywhere.
John Pradeep.v
Ranch Hand

Joined: Jul 21, 2008
Posts: 59
James Sabre wrote:You have lost me. The password is not stored anywhere! There is no need to store it anywhere.


my bad! i got the point cleared - the password is taken on the fly, use it as a key (or the hash of the password as akey) to decrypt the keystore itself!! right?

this sounds great to me.. but this involves a manual submission of the password to the jvm at startup everytime?
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

John Pradeep.v wrote:
James Sabre wrote:You have lost me. The password is not stored anywhere! There is no need to store it anywhere.


my bad! i got the point cleared - the password is taken on the fly, use it as a key (or the hash of the password as akey) to decrypt the keystore itself!! right?

In essence yes but I hope it uses one of the better algorithms for converting a password to a key.

this sounds great to me.. but this involves a manual submission of the password to the jvm at startup everytime?


Err ... of course. What would be the point of having a keystore if the password was stored in the clear somewhere on the hard disk!

I find even this single password approach unacceptable. It allows people to deny making transactions since they can claim that the person who knows the password has committed fraud and made the transactions. The person who knows the password is therefore vulnerable to accusations of fraud with little or no defence. The only pure software approach that I know of that can in any way deal with this is to use an N from M password (or even just and N from M key) so that N people have to conspire to commit a fraud. The only really safe way is to use hardware encryption that requires an N from M smart card and password approach.
John Pradeep.v
Ranch Hand

Joined: Jul 21, 2008
Posts: 59
James Sabre wrote:
I find even this single password approach unacceptable. It allows people to deny making transactions since they can claim that the person who knows the password has committed fraud and made the transactions. The person who knows the password is therefore vulnerable to accusations of fraud with little or no defence. The only pure software approach that I know of that can in any way deal with this is to use an N from M password (or even just and N from M key) so that N people have to conspire to commit a fraud. The only really safe way is to use hardware encryption that requires an N from M smart card and password approach.


good response! I am satisfied with the answer James.

Now i wonder how many organizations (small or big) really give importance to this problem of protecting "single password" access in their security surveys. Not sure if PCI standards talk about this somewhere, need to have a look at it.




 
 
subject: keystore password