Hacker News Reader

Comment by pjscott | Hacker News Reader

How many sites need to be humiliated like this before people learn to hash passwords with something like bcrypt? It's like two damn functions. You just call them! It's so easy that even a baby squirrel could do it! There is no excuse.

Until then, I hope everyone is using a throwaway password for accounts that can be non-disastrously stolen, and using strong unique passwords for the important ones.

View on HN

Based entirely on the format of the data that was publicly accessible, it looks like this data, including usernames and passwords, are raw $_POST server variables spit out in a debug log. All the hashing and encryption in the world can't protect you against saving the data to disk, above your webroot, in plain text before you hit your security component. This was pure programmer error, a form of ignorance, but not necessarily a sign of incompetence.

My point still stands in general, though apparently not in this particular case. :-)

Nice catch, by the way.

It'll just take one congressman's e-mail password to be the same as his YouPorn password, then it'll be law to encrypt.

Really, all it takes is a congressman's email address being on his porn site account, even sans password, if it gets leaked somehow.

Then it'll be law to encrypt email addresses! :D

Besides "use bcrypt" I've never really seen decent guidance on how to actually store passwords (what sort of salt to use, where to store the salt, if and where to store the hash method, how/where to store the key, etc).

"Use bcrypt" is the answer to all those things. Bcrypt includes a salt, which is stored along with the method in the hash string. Hashing is not the same as encryption, so there is no key involved.

If you are using PHP then do this:

    $salt = '$2a$08$' . $random_data;
    $hash = crypt($password, $salt);

$random_data is 22 random letters from A-Za-z0-9.= (16.5 bytes)

(08 is the cost factor - you can change it, but 8 seemed reasonable in my tests.)

If you google bcrypt and php you'll find a very complex and large class for doing this. It's no longer necessary - current versions of PHP have it built in.

Marco Arment (marco.org) has written a nice wrapper for it.

https://gist.github.com/1053158

I'll write one for you right now, because it really is as simple as I made it sound. I'll use the API from py-bcrypt here, but they're all pretty much the same. When a user gives you their password for the first time, here's what you store in your database:

    hashed_password = bcrypt.hashpw(password, bcrypt.gensalt())

Store hashed_password in your database for later. Then, when a user tries to log in, they will tell you their password. You'll need to check that it matches the hashed_password value you have stored. Here's how:

    if bcrypt.hashpw(password, hashed_password) == hashed_password:
        print 'Password is correct!'
    else:
        print 'Wrong password.'

That's all there is to it. The bcrypt library handles everything else. It is this simple because if it weren't, people would mess it up.

Your verification code is wrong. See http://codahale.com/a-lesson-in-timing-attacks/

Edit: I'm wrong, sorry.

Wait, what? What's the attack you're thinking of here? How would it actually work?

Hah, you're right. It's practically impossible to generate passwords in such way that they will give hashes differing by only a byte. Sorry, I see timing attacks everywhere.

Have you actually ever written an exploit for one? It'll cure you of that problem really fast.

(I'm being serious, not snarky).

This is actually a very good advice, especially for people like me who have hard time visualizing how complex things work. For example, when I tried to understand what the meet-in-the-middle attack is, and couldn't, it was incredibly helpful to implement it (https://gist.github.com/1062437). Then I understood.

Okay, let's say you have to integrate with a third party product that can only deal with passwords in normal crypt(). What do you do then? (Rewrite third party product is not a valid answer).

What if you're integrating with something like a Windows VPN w/RADIUS, which needs the plaintext password?

Bcrypt, while trivial for many applications, is not the answer to everything.

>hash passwords with something like bcrypt? It's like two damn functions. You just call them!

I estimate that the average web user understands about 66% of those words. And that's if we give them 'password'.

> I hope everyone is using a throwaway password for accounts that can be non-disastrously stolen, and using strong unique passwords for the important ones.

Why even bother with the distinction. Use a unique password for every login. Use something to manage your passwords. If someone is unwilling to generate a password for an unimportant site, they're probably also too lazy to properly generate unique passwords for sites that matter.

Reply on news.ycombinator.com