Many application designers use md5-hashing mechanism to store the user's password in an insecure storage (e.g. file or DB). Since the passwords are stored as hashes they are protected from anyone with read permission to the file or DB. The downside of this method is that you cannot send the password to the user if he/she requests it, since md5 is a oneway hashing algorithm. Instead the password must be generated everytime anew. The new password is likely a cryptical one and the user must change it again.
The following method allows both hashing and decrypting the password.
- PKey - the public key
- username - the id of the user
- password - user's password as clear text
[Fig. 1]
The basic idea is to use a public-key encryption. In my Java(TM) proto-type the RSA was chosen with a 768-bit key-pair. The encryptions needs 3 parameters:
(1) To be able to generate the idempotent output we must initialize the SecureRandom-Generator with a deterministic seed. The md5 hash of PKey and the username is used as seed (salt).
(2) To be able to generate the idempotent output we must omit the padding mechanism, otherwise it would create random outputs!
(3) The encrypted password can be used like the md5 hash.
Note that the above steps decrease the security of RSA algorithm, so do not use it for real encryption!
The Fig. 2 illustrates that it can be used just like the md5 hashing. Note that the SKey (secret key) is never involved to create, change or read the hash.
[Fig. 2]
To increase the security the SKey is only deployed to an extra service. Fig. 3 illustrates the asynchronous password sending:
[Fig. 3]
Have fun and cheers,
Chadong
Technorati Tags: Security Cryptography Hash Publich-Key encryption
Wont this require huge trust from the pw-recovery-service?
Also, while you are sending the user the decrypted password through insecure-channel you are rendering the whole scheme void.
If however, you would somehow be able to store and authenticate using just the stored (or looked up) public key..
Then in the recovery phase you could send user the public key encrypted password over untrusted network (SMTP).
However, there must be some serious drawbacks here as well, as it's not a widely deployed solution. I'm afraid not qualified to discuss those :) At least it doesn't require the user to turn over private key at any time.