Hacker News Reader

Comment by tptacek | Hacker News Reader

Using MD5 with a salt is asking for trouble.

Using SHA256 with a salt is asking for trouble.

Use bcrypt, scrypt, or PBKDF2. Do not DIY your password hash.

PostgreSQL does this right by supporting adaptive Blowfish hashing in their pg_crypto extension[1]. I checked to make sure since we do use pg_crypto.

1. http://www.postgresql.org/docs/current/static/pgcrypto.html

Thanks for the enlightenment. I have to agree that once you have access to the db, salt or not doesn't really matter security wise. But at the end, it really boils down to: Do you have a strong password? If yes, even md5 is "somewhat" safe. But to be fair, I don't know how big the rainbow tables are.. and could become.

For instance, I've got lots of password with over 20 characters mixed with upper/lower cases with a few symbols in it. (i.e. Seems hard but: phzb0xis@mynickname.on.hackernews.com is already pretty long and hard to crack but still easy for me to type/remember), btw that is not my password ;) I wonder if I encrypt that with MD5.. Could it be contained in a rainbow table somewhere?

Your search - 822d6c6e12b26dd30161967354aa4302 - did not match any documents.

A question on the practicality of expensive compute time for password hashes:

If somebody got read-level access to your password hashes, it follows (based purely on the assumption that any app with the rights to read the hash will probably have the right to change it when applicable) that one could simply overwrite the password hash with a new one that is already known, gain unauthorized access, and change the hash back to prevent the user from finding out. Unless you really need that password to crack multiple accounts that might be reusing it, it seems unnecessary. (And honestly I wouldn't care to implement these special password hashes just to protect extraneous accounts of my customers which I don't control)

edit I should clarify that while I agree that expensive compute time for password hashes helps prevent the ultimate compromise of a user's password, I find it a much more worrisome prospect that somebody got access to the database in the first place. To me, a person's password strength is almost irrelevant compared to the importance of preventing brute-force attacks on a login API or ensuring the integrity of the password database and db apps.

That being said, for those wishing to implement a bcrypt-type hash:

  perl -le'print crypt("something", "\$2a\$random")'

should give you blowfish-encrypted password hashes on systems with it patched into glibc. ("6" instead of "2a" for SHA-512)

Strong password hashes don't protect your users from the consequences of security flaws in your own application.

They protect the (majority of) users that re-use passwords on multiple services, and, more importantly, they protect you from the PR shitstorm of having dumps of cracked passwords posted to Pastebin after a compromise.

security is about defense in depth, and doing as much as is feasible to mitigate damage. Proper password hashing wont protect you from a break in on a primary system, but it could very easily prevent a break in on secondary ones.

Also, a note to anyone reading the above post, that is not how bcrypt works and is incredibly insecure.

What is not how bcrypt works? The example that I gave? That comes from the 'crypt' man page explaining how to use blowfish encryption patched into libcrypt?

Reply on news.ycombinator.com