Hacker News new | past | comments | ask | show | jobs | submit login

Having a different salt for each account means that identical passwords don't hash to the same value. This prevents low-effort attacks like this one: http://7habitsofhighlyeffectivehackers.blogspot.in/2013/11/c...

Relevant XKCD: http://xkcd.com/1286/




Any password that is likely to be duplicated will fall within 20 seconds to a brute force attack, as it is likely to be one of the first 7 trillion (yes, trillion) password that can be hashed in that amount of time. That's 70 terabytes worth of rainbow tables. Run it for 3 minutes and you've got 700 terabytes of rainbow tables. I don't think 700 terabyte rainbow tables exist.

Salts were critical from 1990s to around 2010, at which point they became mostly irrelevant for cracking accounts because of the increasingly parallel processing power that has exceeded the storage capacity of rainbow tables.

scrypt/bcrypt do the right thing, regardless, and generate unique password hash for the same plaintext, so if you use them you are covered both ways.


> scrypt/bcrypt do the right thing, regardless, and generate unique password hash for the same plaintext

I found this statement confusing so I looked a PHP's documentation. http://php.net/manual/en/function.password-hash.php

Bcrypt does use a salt to create unique hashes for the same plaintext, it's just that the function is written so that a random salt is created and stored for you, you don't have to provide a salt along with the plaintext.

Other implementations may not work quite this way.


Yes, GPU brute-force is more effective than rainbow tables. I heard you the first time. I wasn't even talking about rainbow tables.

> scrypt/bcrypt do the right thing, regardless, and generate unique password hash for the same plaintext

Didn't know that. Thanks for pointing it out.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: