Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Double hashing passwords - client & server

Hey, first, let me say, I'm not asking about things like md5(md5(..., there are already topics about it.

My question is this:

We allow our clients to store their passwords locally. Naturally, we don't want them stored in plan text, so we hmac them locally, before storing and/or sending. Now, this is fine, but if this is all we did, then the server would have the stored hmac, and since the client only needs to send the hmac, not the plain text password, an attacker could use the stored hashes from the server to access anyone's account (in the catastrophic scenario where someone would get such an access to the database, of course).

So, our idea was to encode the password on the client once via hmac, send it to the server, and there encode it a second time via hmac and match it against the stored, two times hmac'ed password. This would ensure that:

  • The client can store the password locally without having to store it as plain text
  • The client can send the password without having to worry (too much) about other network parties
  • The server can store the password without having to worry about someone stealing it from the server and using it to log in.

Naturally, all the other things (strong passwords, double salt, etc) apply as well, but aren't really relevant to the question.

The actual question is: does this sound like a solid security design ? Did we overlook any flaws with doing things this way ? Is there maybe a security pattern for something like this ?

Addendum: the reason we don't want to locally store the password in plain text on the client is because as sad as it is, many people still use the same password for multiple services, so getting the 'real' password would be a bigger security breach for the user than getting his hash stolen.

like image 558
J. Stoever Avatar asked Jun 10 '10 20:06

J. Stoever


People also ask

Should you hash password on client?

Hashing passwords makes it possible to use them for authentication, while making it hard to reconstruct the original password. Hashing passwords on the client may be beneficial: even though it does not protect against attackers, it does protect against accidental mistakes.

Can you double hash a password?

"Double" hashing (or the logical expansion of that, iterating a hash function) is absolutely secure if done right, for a specific concern. To those who say it's insecure, they are correct in this case.

How do hackers get hashed passwords?

The problem is that the hashes still have to be stored, and anything that is stored can be stolen. Hackers could get the password hashes from the server they are stored on in a number of ways. These include through disgruntled employees, SQL injections and a range of other attacks.

Why is client side authentication a poor choice for security?

Client-side authentication is extremely weak and may be breached easily. Any attacker may read the source code and reverse-engineer the authentication mechanism to access parts of the application which would otherwise be protected.


1 Answers

Caveat: I'm not a security expert. I'll ping blowdart to see if he fancies joining in.

If the client is just storing the hash, and effectively transmitting something just based on the hash, then they're effectively storing it in plain text. The only benefit that the first hash is providing is that if they've used the same password on a different system, that other system won't be compromised if the hash is revealed.

To put it another way: if someone can get hold of the hash that's stored on the server, that's all they need to log into the system... just like plain text storage.

like image 137
Jon Skeet Avatar answered Oct 01 '22 20:10

Jon Skeet