There’s a big problem with all sites that store a password to perform authentication – you have no idea what security measures are being taken to protect the stored passwords. How do you know how your password is ‘secure’ once it’s at the other end? How can you know?
As the recent LinkedIn Password Leak showed, even tech-savvy companies can get it very wrong. Unsalted SHA-1 is not good enough. Hashes can be calculated at 8 thousand million per second on a modern GPU. The scary thing is that it’s one of the least bad leaks recently, the Sony Password Leak revealed that they were storing millions of passwords in plain text.
Clearly, something needs to be done, and here is what I propose:
Sites should publish some hashed passwords
On my website, yetanothersocialnetwork.com, I provide a page with some sample database rows from my user table (with fake data):
| username | password_hash |
|---|---|
| abc123 | bbd09e976e29f1721a4203f0bc75d754f0b91dff350aee6ae9952a0056eeb652 |
| fred99 | 8b0afe8cd1d9a3d27bf0f5ab1117865fe892afc7234a4d0a9dbb5a13e9b4d2dc |
| sparkle_grl_78 | f720996783311dfed97c5c5945164c4b475709c9d8db6f043b2bf86f8db79211 |
| gareth-smith | 912b22309b5739f5b4f3d392a9ece12e7d49dd4a1fce4b802ce7f40beae14eea |
| megatroid | b5599f978865d965d4f796a36088d88155eae094734245309999838155baa5c0 |
This makes the security of the site transparent. For those who care, they can easily see that decent security measures are being taken with the storage of passwords. For those that don’t, if there is a problem, a fuss will hopefully be made about it before a leak, rather than after.
If you run a site that stores user passwords, please consider doing this. If your hashes are good, this should be a trivial thing to do. If they aren’t, well it’s probably time you sorted that out…









No! protect users from themselves! No hash is unbreakable if you choose something based on a dictionary word, and people will. And, once you have a user/pass, it’s often good on many sites. Protect users, and don’t be the weak link by disclosing data about them gratuitously. If you must, at least use cracklib to make sure that their password isn’t simple, but that still doesn’t guarantee that disclosing the hash doesn’t give away too much about the password (it might contain a simple permuation of their birthday, which you don’t collect, so cracklib can’t spot the easy password, but an attacker from another website already knows it).
Above even bad hashing algorithms, my #1 gripe is allowing too many queries, with no backoff (CAPTCHAs are beatable; time isn’t: always use a backoff). Hermes for example has no backoff, which I verified by running more than 50000 passwords through it once in a few hours from one IP (I got in a lot of trouble, but even though their log analysis didn’t even catch me and I had to go to them, they still didn’t admit fault at the end of the day).
| June 9, 2012 @ 12:14 am
You don’t publish user data! A explained, this is sample, fake data. Cracking it would achieve nothing!
| June 9, 2012 @ 6:37 am
Also, OpenID? I made a Google/Yahoo/etc selector for my long-form blog to make it fairly easy.
| June 9, 2012 @ 12:18 am
Yes, but all you’re doing is handing over the problem to someone else. How do you know Yahoo’s password material is properly protected?
| June 9, 2012 @ 6:39 am