How to not store your users’ passwords
November 21, 2013  

In response to the Adobe password breach, Sophos has come out with a well-intentioned post, How to store your users’ passwords safely. Unfortunately, Sophos started from a bad premise: that you should ask to see your users’ passwords in the first place.

If you require users to send you their passwords at all, you are already in trouble. For example, if your server has become compromised, then the attacker gets to see the passwords at the moment that users send them, no matter what you do with them after that.

The idea of “storing” passwords is also a bad idea. That’s what Adobe did: they stored user passwords, after encrypting them. Since the encrypted passwords were stored, they became vulnerable, and, once leaked, have caused all sorts of problems.

Now the Sophos article does not actually suggest storing passwords, they suggest storing hashes (of hashes of hashes) of passwords, which is not the same thing. But the fact that they put “storing passwords” into their title shows that they aren’t thinking clearly.

The problem of using a password for authentication without revealing the password to the server has been studied extensively, beginning with the work of Bellovin and Merritt on EKE. Nowadays, the most likely candidate for deployment is SRP.

In my last post, I said that you should use SRP because you can’t trust Adobe or any company to keep your password safe. I’m not really interested in bashing Adobe; perhaps it’s better to say that from Adobe’s point of view, they would have been far better off if they hadn’t taken on the responsibility of safeguarding user passwords. That has proven to be a huge liability that they could have avoided completely if they had used SRP. SRP is a win-win for both users and service providers.