If you don’t think a password hash is just as good as getting a plaintext password (99% of the time), then you should read this.
Several of my clients in the past have downplayed my findings related to the discovery of password hashes, even after I cracked them. This article, like many of my articles, is taken from the communication I’ve had with them on the topic.
Hopefully, this level of detail is beneficial to you and emphasizes why typical password hashes are not much more secure than plaintext passwords.
A cryptographic hash function is a hash function which takes an input (or 'message') and returns a fixed-size alphanumeric string. The string is called the 'hash value', 'message digest', 'digital fingerprint', 'digest' or 'checksum').
The ideal hash function has three main properties:
It is extremely easy to calculate a hash for any given data.
It is extremely computationally difficult to calculate an alphanumeric text that has a given hash.
It is extremely unlikely that two slightly different messages will have the same hash.
Although hashes are considered “computationally difficult” to reverse, that does not mean that the plaintext password is not recoverable, and in some cases, easily recoverable.
Example: The MD5 hash of “p@55w0rd!” is fdc538e4d04ec155c49166bea33597f4. Seems secure, right? Google the hash to see how easy it is to recover many of the passwords “protected” with md5.
Even if the password hash is not easily looked up in a rainbow table*, one can easily crack them at a rate of over one million MD5 password hashes per second on a typical laptop. If using a beefy GPU based crack server or spinning up multiple AWS compute nodes, one may be able to crack hundreds of millions per second.
* A rainbow table is where one simply has to lookup the hash against a list that someone else has already pre-computed every possible password.
The salt (if used) is an extra piece of data that is included which causes every password to be hashed slightly differently, to put it simply. A salt makes it much slower to crack a list of password hashes and greatly reduces the odds of a rainbow table being available. It should not be seen as a solution for weak cryptography, but does provide a measure of additional security.
Many online service providers do not disclose which hashing function they use, nor how it’s implemented (also important). Even “installed” software on your computer may not disclose this.
Here are some examples of known implementations (at least at one time):
As can be seen above, unsalted SHA-1 and MD5 are still common, unfortunately. These are some of the weakest cryptographic hashing algorithms. Salted bcrypt and PBKDF2 password hashes are much more secure and take thousands to millions of times longer to crack than SHA-1 or MD5. Here’s some third party research that gives you an idea of just how much more secure they are.
Just remember, all password hashes are crackable. Nothing is 100% secure. I’ve never obtained a list of hashes on a pentest, or seen a password dump from a breach, where I wasn’t able to crack at least a portion of the passwords.
Bcrypt and long password requirements is supported in every modern programming language I’ve seen. There is absolutely no reason a developer cannot implement a strong hashing algorithm for generating and storing password hashes.
From a user perspective, the best thing to minimize the success of these attacks (cracking the password) is a really long passphrase with at least some complexity. A simple passphrase, such as “This-Is-My-Super-Secret-Password,” is a nonillion (30 zeros) times stronger against the above attacks than a shorter one that uses random keys on the keyboard such as “^W&jB$S@d(“.
By using the most secure (salted) hashing algorithms in conjunction with minimal password standards (length and complexity), it will take way more than a lifetime to crack the password hash. If developers and users followed these best practices, you could just about publish the hashes publicly and be safe. But don’t :-). Protect them as aggressively as you would plaintext passwords and you’ll be golden.
Additional reading, with good comparison charts, can be found here: