Recommendations For Password Hashing

Recommendations For Password Hashing

Old forum URL:

MadGerbil posted on Wednesday, November 09, 2011

I've a user object with a password field.

The site will be hosted in an SSL and while it would be rather trival to hash  the password server side in the Insert/Update region it occurs to me that it may make sense to hash it client side before sending it over the wire.   This would happen on the creation of a new user or the update of a user.

I suppose I could place the hashing code inside the property set but I've read cautionary notes about doing that since, I guess, binding can sometimes bypass the official set and do a loadproperty instead - I'm foggy on that, I just have the sense that it's a bad idea.

The next possible location would be a business rule but I wonder about the UI impact when a value is hashed and goes from 8 characters in length to 200 characters in length - I don't think people want to see the password box value change (even if it goes from 8 dots to 200 dots) when they tab off the box.

So it seems like a good idea to hash the password before sending over the wire, even with SSL, but I'm not sure where this should occur.  Any recommendations?

Peran replied on Wednesday, November 09, 2011

I would be cautious about allowing your hashing algorithm code on the client side as it can be decompiled and is useful information to an attacker.

For passwords you should probably be using a one way salted hash, so placing the code in a property would be useless, because in your getter it would be impossible to convert the hash back into the clear text password.

I would leave SSL to encrypt over the wire, and do your salt creation & hashing on the server.





RockfordLhotka replied on Wednesday, November 09, 2011

There is the SecureString type that can be used to store values in memory so they are hard to acquire. But you still need to send the value over the wire to the server.

If you are using SSL though, I am not sure why you feel the need to encrypt the value before allowing SSL to encrypt it too?

In any case, Peran is right - encrypting things on the client is challenging, because the key is, by definition, also on the client, so it can't be made secure without low-level hardware support.

Windows itself relies on such low-level hardware support (starting with Vista at least) to switch into that admin mode you see when installing software or manipulating client-side certificates/keys. I don't know if you can tap into that yourself or not though.

StefanCop replied on Wednesday, November 09, 2011

That depends on what are your risks, where you expect volunerable and protected places. I hope you don't have very strong security requirements, because ordinary software engineers like myself will always leave or introduce leaks.

Password hashing on the server can be used to store it in a way that the plain pwd only can be guessed.

If you do the hash on the client side without some salt (i.e. a challange from server), the hashed password would always be the same, and an attacker could replay the hash (man in the middle attack).

My understanding of SSL is a secure, session-specific channel (handshake protocol is public key, session is AES). So for protecting the password on the wire, SSL is a good solution.

Hw to protect a password on the client side? Very difficult. If possible keep the password only in local variables (on the stack) until it's sent over the SSL wire. You could receive a token or the server remembers this session is authenticated.

If you need to protect values locally for the time of a session, the you can get a random key and use a symmetrical crypto algo,  i.e. AES/Rijndael, DES3 (but where to hide the random key...). I've seen a SecureString, which is basically doing that.
Commonly used Hashes are SHA-1, MD5, usually combined with RSA.

Copyright (c) Marimer LLC