Collective Idea

Collective Idea Logo

Daniel Morrison

The Password Rant

By Daniel Morrison on June 07, 2012 in passwords, rant, security, and ssl

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 most2 sites don’t do it right.

The steps:

  1. 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.

By Daniel Morrison on June 07, 2012 in passwords, rant, security, and ssl

2 Comments

  1. Anthony Vigneron

    Anthony Vigneron July 04, 2012 http://blog.vigneron.biz/how-secure-passwords/

    ;) 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/

  2. Socal

    Socal July 06, 2012

    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.

Post a Comment

Contact Us

Find us on Google Maps
Collective Idea
44 East 8th Street, Suite 410
Holland, Michigan 49423 USA 42.790334-86.105251

Follow us on the Interwebs

We are currently available for medium and long term projects. Please get in touch if we can be of service.