2

Today I discovered something incredibly stupid - my friend hashes user passwords with sha512 algorithm without a salt. I immediately raised this issue to him but he said he wants to see anyone crack a single password in his database. I told him that without a hash his database is vulnerable to rainbow attack but he said no one had this large rainbow table for sha512 as each has is 64 hex characters long.

How do I convince him that he still needs to add salt? Does anyone know what the hash cracking rate of sha512 is? I could argue then that it would take this much or that much time to crack all 8 char passwords, etc.

bodacydo
  • 849
  • 9
  • 16

3 Answers3

13

How about you take his challenge? Go make a quick rainbow table of common passwords and run it over his database. You're bound to hit something (especially if he doesn't have a password policy). However, this may not work if he has a small database.

MrZander
  • 230
  • 1
  • 4
  • Why stop at 500? There are pre-existing rainbow tables with millions of passwords for all the common hash algorithms all over the net, there are online tools like crackstation.net or md5decrypt.net/Sha512 that prevent you needing to download any massive tables or spend any time generating them yourself. – thomasrutter Dec 15 '17 at 00:28
9

Even if he was using a salt, it would still be a terrible plan. SHA-512 is a fast hash, so you don't need rainbow tables in order to find passwords, simply testing inputs along with the salt can be done at the rate of hundreds of millions to billions of candidate passwords tested per second.

What your friend should do, is read the answers to How to securely hash passwords? And then choose a proper password hashing mechanism like BCrypt or PBKDF2.

Community
  • 1
Xander
  • 35,616
  • 27
  • 114
  • 141
3

He may be technically correct, but it is still bad design.

His approach will mean that duplicate passwords will generate the same hash, which can reduce an attacker's cost (if he finds out a plain text password from one user and is also able to get the password hashes, he can see which accounts use the same password).

His approach is also dependent on the current state of the art of generating hashes. By adding a salt, he 'future-proofs' (I hate that term) his design.

schroeder
  • 125,553
  • 55
  • 289
  • 326
  • 1
    This is the best answer, because it demonstrates an actual design weakness that the friend should understand. Actually cracking a password from a common password table would be more of an "ok, you got lucky and he really picked an obvious password, you didn't really crack the hash, you just guessed good" response. – Tom Mar 06 '17 at 14:11
  • 1
    _"He may be technically correct, ..."_ - He is not correct. The number of entries in a rainbow table is determined by how many password strings you put in, not by the size of the hash output. The rainbow table doesn't need to store the full hash output, just enough to be able to do a quick lookup (~40 bits probably suffices), so the hash output size also doesn't affect rainbow table entry size. So when he states rainbow tables are infeasible due to sha512's size, he's _wrong_. – marcelm Dec 15 '17 at 09:33
  • @marcelm You will note that the entire thrust of my answer is to avoid the technical details of a rainbow table because that's not even close to the point and explaining those details will not "convince him" that he needs a salt. – schroeder Dec 15 '17 at 09:38