2

Searching the internet I only saw tables of encryption/hashing families and the logic. I've seen a video recently from Computerphile about breaking passwords using dictionary rules and previously broken data dumps of passwords. By the end of the video, it was mentioned that MD5 and SHA1 hash algorithms aren't as safe any longer and that if you're using SHA1, you should move to SHA256.

I want to double check which Hash functions are strong, which ones are still usable, and which ones are no longer safe (may it be due to vulnerability to attacks or a massive leak happened, etc etc) in a nice table.

There doesn't seem to be a nice handy table for this and you would have to go through each algorithm that interests you and read the wiki page about it and figure out if it's still vulnerable or not.

Is there such a list?

Maarten Bodewes
  • 4,562
  • 15
  • 29
Razgriz
  • 133
  • 2
  • 6
  • 1
    It depends what you're hashing. For making a checksum for files, SHA256 is good, because it has no known collision-vulnerabilities. But for securing passwords, Bcrypt should be your choice; because Bcrypt is slower - and that's good. – O'Niel Jul 30 '16 at 15:41
  • What platform are you using? – user2320464 Jul 30 '16 at 19:23
  • that video made me cringe several times from it's inaccurate and misleading "info" – dandavis Aug 01 '16 at 03:32
  • I am beginning to get an impression that they don't discuss topics as thorough as they would and that they'd often mislead newbies such as myself. – Razgriz Aug 01 '16 at 06:24

2 Answers2

7

TL;DR

  • If your data is a long message, or has at least 72 bits of entropy, use SHA-256.
  • If your data is a password use BCrypt, adjusting the work factor to take about 100ms.
  • If the input data has too little entropy, hashing (even with BCrypt) will not provide significant security.
    • weak passwords
    • all-digit PINs
    • banking account numbers

While it is hard to list all the hash routines, it is easy to list the most common routines, and even easier to recommend the one you should be using.

The SHA-2 family of hashes (SHA-256 through SHA-512) are considered strong General Purpose hash routines. SHA-256 works best for most purposes.

MD5 is quite weak, and SHA-1 is acceptable. While some folks may desire MD5 for being shorter (128 bits instead of 256), you are actually better off truncating a modern hash. Obviously it is better to use the full hash length of 256 bits.

Keep in mind, General Purpose hash routines such as MD/SHA are designed to be fast. For most computer programs, fast is considered good.

However, if the original input value has limited entropy (for example a 4 digit pin), then it will be very easy to brute-force (try all 10,000 possible input values and compare them to) the hash, thereby determining the otherwise secret data.

  • 4 digit PIN = 13 bits of entropy (cannot be made secure enough by hash)
  • 18 character truly random Hex string = 72 bits entropy
  • 12 character truly random Base64 string = 72 bits entropy
  • 8 character password from a lazy user = almost no entropy
  • 11 character password with some common substitution tricks Tr0ub4dor&3 = roughly 28 bits of entropy
  • credit card number = not enough entropy so don't store even its hash
  • email message or any large text file = lots of entropy

Every bit of entropy means it takes twice as long to brute-force that data.

How long it takes to brute-force depends on speed of attacker hardware, and how fast the hash is. So,

  • If your input data has 72 bits of entropy or better, just use SHA-256.

  • If your input data has less entropy, or unreliable entropy (user-provided passwords), then you should use a Slow Hash.

Slow Hash routines are adjustable, so that instead of completing the hash operation in a few microseconds, it takes several milliseconds (I recommend about 100ms) on your production hardware. (note that attacker hardware will probably be much faster)

Here are some good Slow Hash choices.
Each has a means to adjust the processing time. (strength of the hash)

  • Repeat your SHA-256 (or SHA-512) hash many many times.
    This is straight-forward to implement, and considered a reasonable technique. (despite the fact that SHA was designed to be fast)

  • BCrypt (commonly recommended slow hash)

  • SCrypt (newer (less proven), designed to be GPU-resistant due to RAM requirements)

  • PBKDF2 (older, good alternative to BCrypt)

Note: Optimization of your hash function is important. Use the natively compiled version of BCrypt, not one 'written in' a high level language (i.e. JBCrypt was written in Java), as the Natively Compiled version (written in C/C++, with proper linking to your high-level language) will be more efficient, therefore allowing you to compute a higher (stronger) work factor in the same amount of time.

It is common to add Salt to a hash. This is unique, but not secret, and is added to the password before the hash is generated. In this way, if an attacker steals your database and runs brute-force on all the hashes, he will have to run a separate brute for job for each Salt used, which will take him quite a bit longer than brute-forcing all the passwords in a single job.

700 Software
  • 13,807
  • 3
  • 52
  • 82
  • Wow, thanks so much for the extensive and insightful reply. I've heard of the hash and salt practice to further strengthen the encryption. I'm storing user passwords of at least 8 characters and hopefully they use more than alphanumeric characters to increase entropy. – Razgriz Jul 30 '16 at 15:41
  • I am glad you found this helpful. – 700 Software Jul 30 '16 at 17:41
  • 9 _octets_ is 72, but in base64 it's 12 _characters_. – dave_thompson_085 Jul 31 '16 at 05:40
  • Although password-hashing has the word "hash" in it, it's not a cryptographic hash function. It's usually shared under PBKDF's: Password Based Key Derivation Functions. A hash normally has a single input while PBKDF's also can be configured with the work factor / iteration and even the primitive to use (often a hash function), and accepts a salt as input together with the hash. Comparing PBKDF's and hashes directly should be avoided, they serve different purposes. If you must, compare a KBKDF (Key Based Key Derivation Function) with PBKDF's. – Maarten Bodewes Jul 31 '16 at 10:51
  • @MaartenBodewes, I think that a direct comparison helps people to understand their differences. Each was designed for a particular purpose. – 700 Software Aug 01 '16 at 12:14
5

That video completely skips over some of the more tricky parts of password-hashing. For instance, it doesn't even mention well establishes password hashing schemes such as scrypt, bcrypt, PBKDF2. Furthermore, it confuses normal hashing with password hashing and continuously talks about "storing passwords" - which is exactly what you do not do when you store a password hash. Please do not use it as reference material.

The strength of MD5 or SHA-1 is completely irrelevant in password hashing. If you see a PBKDF2 hash over a relatively good password, large salt and iteration count (work factor) that has been configured with SHA-1 or MD5 you'd still have absolutely no chance of finding the password. MD5 (practically) and SHA-1 (theoretically) have been broken with regards to finding collisions, but not with regards to preimage attacks.

Password hashes are actually quite different functions from cryptographic hashes even regarding configuration parameters and input. Password hashes fall under the category Password Based Key Derivation Functions (PBKDF) which have a configurable primitive (hash function) and work factor. Furthermore, they do have the salt as additional input parameter. Hash functions just have a single input and output. You should consider them different functions and not compare them directly.

If you want to compare them to a function that is designed for high entropy input (very complex passwords and keys) then Key Based Key Derivation Functions (KBKDF) such as HKDF could be considered. Those algorithms are often also based on hash functions, although block cipher based designs are also used.

In addition to the already known password hashes: scrypt, bcrypt and PBKDF2, there is also Argon2 which won the password hashing competition. PBKDF2 has some unfortunately weaknesses, but it best standardized as part of PKCS#5 / Password Based Encryption standard and NIST standardization.

For cryptographic hashes it is simply best to choose either any of the SHA-2 variants or SHA-3 variants, standardized by NIST.

There are a very large number of password hash functions and cryptographic hash functions. They are just not all known to the general public. These functions can be broken in several ways. So any table would be very large, and would not serve any good purpose.

Maarten Bodewes
  • 4,562
  • 15
  • 29