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.
As others have said, taking the client and your system in isolation this doesn’t really buy you anything – the first hash simply becomes the password.
The value comes if (as is likely) the client uses that same password on other systems. In this case, should the client machine be compromised then at least your local copy of their hashed password doesn’t allow the attacker access to other systems. Obviously the attacker of the client will now be able to access your server – they have, after all, got the password.
An attacker having access to the double-hashed value on the server won’t buy them anything, since they can’t reverse that to get the single hash (i.e., the “password”). Of course, if the attacker is in a position to read your security database then I suspect they have other attack vectors available 🙂
Also, as another poster said, make sure you are using a salt on both hashes. Without doing so, reversing the hashes may actually be quite simple if the passwords are not strong.
EDIT – actually, thinking about it, since you are using a hash as the password you don’t really need to use a salt on the server. No way anyone is going to be able to create a rainbow table that’s effective 🙂 Still need one on the client though.