Secure Password Storage and Transfer

Question

I'm developing a new user store for my organisation and am now tackling password storage. The concepts of salting, HMAC etc are all fine with me - and want to store the users' passwords either salted and hashed, HMAC hashed, or HMAC salted and hashed - not sure what the best way will be - but in theory it won't matter as it will be able to change over time if required.

I want to have an XML & JSON service that can act as a Security Token Service for client-side apps.

I've already developed one for another system, which requires that the client double-encrypts a clear-text password using SHA1 first and then HMACSHA1 using a 128 unique key (or nonce) supplied by the server for that session only.

I'd like to repeat this technique for the new system - upgrading the algo to SHA256 (chosen since implementations are readily available for all aforementioned platforms - and it's much stronger than SHA1) - but there is a problem.

If I'm storing the password as a salted hash in the user-store, the client will need to be sent that salt in order to construct the correct hash before being HMACd with the unique session key. This would completely go against the point of using a salt in the first place. Equally, if I don't use salt for password storage, but instead use HMAC, it's still the same problem.

At the moment, the only solution I can see is to use naked SHA256 hashing for the password in the user store, so that I can then use this as a starting point on both the server and the client for a more secure salted/hmacd password transfer for the web service.

This still leaves the user store vulnerable to a dictionary attack were it ever to be accessed; and however unlikely that might be - assuming it will never happen simply doesn't sit well with me.

Greatly appreciate any input.

Answer 1

A salt does not need to be secret - it must be unique. a salt is designed to mitigate the threat of two users having the same password and hence the same resulting hash. so you can use the user's name as the salt if you wish. a salt makes a dictionary attack much much harder because the attacker has to compute each result for every dictionary word and every possible salt.

in my opinion, i would use a password-based key derivation function (PBKDF) with a high iteration count and a salt.

http://www.bing.com/search?q=pbkdf2

Here's sample code in C#, but it's avail in most any popular framework today http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

Answer 2

HTTPS is the best solution for this problem.

You are throwing a lot of crypto primitives at this problem in hopes that it will go away. In general the protocol that you are proposing seems to wasteful of resources, I recommend doing research into other authentication protocols and think of ways of simplifying your protocol. Practical Cryptography is an excellent book.

The biggest problem is see is in transfer of secrets between the client and server. In order to implement this correctly you need to use a Diffie-Hellman key exchange. Luckily one has already been written in javascript:
http://enanocms.org/News:Article/2008/02/20/Diffie_Hellman_key_exchange_implemented

Another problem is that i don't see how the client can determine that its talking to the correct server. SSL uses asymmetric cryptography, backed by a PKI, which you will not be able to implement in JavaScript.

A message digest is not an encryption algorithm. It is never okay to spill a password hash, where as cipher text is meant to protect against an eavesdropping.

Spilling a password salt to an attacker will make your passwords less secure. If the attacker has a salt then they can use a dictionary to attack the password, without the salt they will have to guess randomly, making the password storage system far more robust.