Is it safer to double hash passwords with salt? (a little more complicated)

Question

In this case one wants to authenticate a user via http/s.

In the registration progress the server generates a salt. This salt is send to the user. He then procedes to hash his password with the salt via js and send it to the server. There the hash get salted again with the same salt and the twice hashed and salted password gets written into a db with the cleartext salt.

If one tries to authenticate he sends his username, gets the salt and hashes the password. This is send to the server who hash it again and if the saved hash and this is the same the user is authenticated.

I was wondering because of the recent heartbleed bug it would be nice to never expose the real password. But I've read that double hashing can increase the risk of collissions.

Is the way I imagined that the safest way or do I get soimething wrong?

Answer 1

I was wondering because of the recent heart bleed bug it would be nice to never expose the real password.

I can see where you're coming from, but you haven't thought this all the way through. If you hash the password client side and send the hash to the server, then this hash is essentially the user's password. If an attacker were to gain possession of this hash that the client sent to the server, whether it be through heartbleeding, MITM attacks or otherwise, all the attacker has to do is send this hashed password to your server (without hashing it again client side obviously) in order to log in. Hashing it client side gains you nothing.

But I've read that double hashing can increase the risk of collisions.

Theoretically yes. If the password is longer than the resulting hash, the entropy of the input is guaranteed to be reduced. Even with input shorter than the resulting hash, chances are that the entropy is reduced somewhat. Hashing this reduced entropy data again reduces entropy further (theoretically). In practice this will hardly matter at all.

Answer 2

"In the registration progress the server generates a salt. This salt is send to the user. He-" I'm going to have to stop you right there.

In principle, there is nothing wrong with client-side hashing, as long as you understand that it doesn't increase the security of your system. However, hashing/digesting does mean passwords received are always of a very specific form, regardless of the shape of the actual password the user chose, and it means you (as a server owner) don't theoretically know the password of the user that's sending it to you.

It's not secure, because you -and anyone listening in- can take that hashed password and crack it (because you're no different from an attacker in that respect). However, it does add a layer of trust: "I have to go out of my way to find out what your password is".

Taking that into account, salting at the client isn't useful, and if you get the salt from the server, is a false sense of security: if you are sending the salt from the server to the client, anything that can see the user's password client-side can also see the salt client-side. You might as well write the salting value as an <h1> title on the page, there is no security there, and you're just going to waste processor time salting.

Now, you still want to hash properly on the server, with salt, but there is no point in having the client do any salting. Simply give them a client-side digester/hasher (like a SHA256 library) and leave it at that. Then on the server, you receive the password, validate it against what you know about what hashed passwords should look like (right length? no characters outside the hashing space? etc) and then you hash that input with your own salt and store that/use that to validate against your user database.