The Password Rant
seriously, LinkedIn, no salt?!?. Ugh, I feel a rant coming on.
— Daniel Morrison (@danielmorrison) June 6, 2012
Yep, it happened. LinkedIn’s password breach has led me to rant. Hold on.
Passwords are bigger than your site. Passwords stored on your site are private data that may be the key to other secrets elsewhere. How many of your users use the same password for their email as your site? Probably a much higher number than you’d think.[1]
When you store a password, you’re holding a key to untold secrets. The goal is to keep that key safe from everyone, even you.
What angers me is that the solution is simple and free, yet most[2] sites don’t do it right.
The steps:
- Use BCrypt.
That’s it. LinkedIn can’t do it right, but you can.
It won’t happen to me.
This is the most common excuse I hear for having bad password systems. I don’t care if you have 1 user or 1 million, you’re a target. You can put many things off for once you scale, but you should start with good passwords.
No Clear Text
There is never a reason to store a password in clear text. Never.
Neither you, your sysadmin, or anyone else should be able to retrieve a password and display it in plain text. I’ve heard all the excuses, and they’re all wrong. If anyone can access the password in plain text, no matter how much you trust them today (don’t even trust yourself), you’re a moron.
LinkedIn used SHA-1 as their hashing algorithm, which isn’t totally horrible, but is made completely worthless without a salt. Honestly, there’s no excuse for this.
You’ll hear lots of nonsense focusing on the wrong thing: the hashing algorithm. Don’t use MD5, or SHA-512, and please don’t ever write your own. We already have the solution.
BCrypt All the Passwords!
Seriously. BCrypt is free, this isn’t something you skip.
If you don’t know what BCrypt is, stop what you’re doing and learn right now. If you don’t understand it, use it anyway.
You had better have something proven to be better if you’re using anything else. No excuses.
Next steps
Passwords should never show up in the logs. Rails makes this easy, other systems might be tougher. Figure out how to do it.
You should also be using SSL all the time to avoid passwords showing up in network logs, but you do that already, right?
“My boss/client doesn’t think this is important.”
That’s your problem. If you can’t use this opportunity to make your case, you’re not a good enough programmer. Give a shit. Care about what you do. Do it and bill them for it. Tell them I sent you.
Make it easy
If you do all of the above correctly, then give up on trying to have rules for your passwords. If people want their passwords to be “password”, then that’s their problem. Encourage the use of strong passwords, but you don’t need rules. At all. But that’s a rant for another day.
[1] Of course, you’d never do that, right? You use something like 1Password and make each one unique, right? Right?!?
[2] Please prove me wrong here.
About Daniel Morrison
Daniel founded Collective Idea in 2005 to put a name to his growing and already full-time freelance work. He works hard writing code, teaching, and mentoring.
Comments
;) loud and clear!
Even if some still haven’t implemented those practices, users also have some responsibility to take.
I shared some here and how to mimise those risks: http://blog.vigneron.biz/how-secure-passwords/
Completely agree. This is actually an area the government should put some min standards to. Anybody that uses SHA whatever without per user salts and a method of increasing the workload is screwing their users. Security is an afterthought for many of these sites as the push is to get users, have user value, etc. LinkedIn is a publicly traded, venture backed Company that has NO Excuse for this. None and they should be fined for failing to have security that would meet any minimum standard. $5 per user might be a nice fine for any company that has more than a certain number of users. As part of the IPO process there should also be a tech audit for web facing companies.
For BCrypt I would add:
1) Use per user random salts
2) Make your system changeable by allowing you to increase the workload over time (i.e. able to change rounds=100000 to rounds =1,000,000 and have it apply to all new users and anyone that re-logs in.
3) Create a minimum length of a password. Strength meters are good but many people want simple passwords they can remember.