Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Salt means FOR EACH RECORD in the database, you have to compute those 1,000,000 passwords. That means you're talking about decades of computation time.

SHA256 of the million most common passwords (with a 128 bit salt) takes 2 seconds /total/ on my laptop. That's only 42 days required to crack a database of one million hashes.

  var stopwatch = Stopwatch.StartNew();
  var salt = "0123456789012345";

  int crackCount = 0;

  foreach (var password in File.ReadLines(@"c:\temp\10_million_password_list_top_1000000.txt"))
  {
    System.Security.Cryptography.SHA256.Create().ComputeHash(Encoding.UTF8.GetBytes(password + salt));
    ++crackCount;
  }

  stopwatch.Elapsed.Dump();
  crackCount.Dump();
=>

  00:00:02.0981333
  999999
Salt is indeed important, but the only real way to protect is to iterate - PBKDF2/scrypt/bcrypt.


Are you ignoring the part where I said "when you involve stretching?"

The claim was that salting is irrelevant compared to stretching. It is not. It is still unbelievably important even when doing stretching.


I think in the real world there are two scenarios, someone is using one of PBKDF2/Bcrypt/Scrypt - in which case all of this is moot, set an appropriate work factor/#of iterations, and you are secure with even a moderate sanity check against the password. Interesting note - said sanity check, ironically, could be a simple as a lookup - the top 4 billion passwords can be stored in a packed 24 gigabyte lookup table on disk which can be searched in < 100 milliseconds).

The other scenario is when you doing a single pass of a hash, in which case the salt is irrelevant for the security of that password.

Everyone here understands that you need to salt when your dictionary takes a long time to build (Say, more than 1 millisecond/password, which equals 2.5 billion passwords/month) - not everyone appreciates that salting a fast password (more than 2.5 billion passwords/second) - adds no security to that particular password.

The scenario where there is moderate "stretching" (by which I presume you mean running multiple iterations of a hash), with no randomized salt, is a bit of a straw man - who would bother to go the effort of "stretching" and not stick a randomized salt in while they are at it?


Sorry yes I obviously missed that bit.




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

Search: