Tech Solvency / Passwords / "Dehashing", "Reversing", and "Decrypting"

Everyone really needs to stop using "dehashing", "reversing", or "decrypting" with password hashes.

The word you're looking for is cracking.


You can't "reverse" password hashes. You can't "unhash" or "dehash" passwords. You can't "reverse" or "invert" MD5, SHA256, bcrypt, SHA1, or similar hashes, salted or unsalted. You (usually) can't "decode" passwords, "decrypt" password hashes or "reverse" or "unscramble" password hashes at all. There's no such thing as "hash decryption". There's no such thing as a "dehashing tool" or a "dehashing program" or a "password reversing program" or a "hash decryptor" or a "password unhasher" (except in very specialized, non-hash-based password storage*).

These terms run completely counter to the fundamental concept of hashing as a one-way function.

Using these terms isn't just inaccurate. It can make people carry this misconception forward for years - making deep errors in their thinking and work.

This is like showing up on a baking forum and saying:

"I bought this cake. How can I turn it back into eggs and flour and milk?"

Or as Julien Piatek brilliantly illustrated it in Hash functions for newbies:

Diagram showing that you can turn fruit into a smoothie, but you can't turn a smoothie back into the original fruit. ~ Image by Julien Piatek.
Image credit: Julien Piatek, Hash functions for newbies

You can't "deblend" your smoothie. You can't directly turn the smoothie back into the fruit. But what you can do is to keep trying possible combinations of fruit until you get the same taste, color, consistency, etc. Then you know what the recipe was.

In other words, you can black-box reverse-engineer a password hash, but you can't disassemble it.


Listen. The words you're looking for are either crack / cracked / cracking (when first discovered), or hash lookup (when fetched from a cache of cracked passwords).

Cracking is what's happening the first time a plaintext for a given hash is discovered (or if you're a cryptographer, you're finding a preimage). All you're doing is hashing candidate passwords to see if you got one that matches your hash. Over and over again. If you could "reverse" a hash, the underlying function would be a bad hash function, by definition.

And yes - once a hash is cracked, the results can be indexed or cached for fast retrieval. This provides the illusion that there's some kind of fast math going on. But that's not "reversing" the hashes. That's just a lookup. (I'm not a fan of 'reverse hash lookup' - while precise and technically true, it only confuses the noobs, because of that pesky word "reverse". When someone says "I'm trying to reverse this hash", they are definitely *not* saying "I'm trying to look up this hash".)

Seriously. You can't get there from here. It's a one-way street. There's no going back.

* What about [format]?

Some password storage formats - like Cisco type 7, Juniper $9$, WebSphere, Jenkins, etc. - have well-known or locally-stored keys that are used to encrypt (or merely obfuscate) stored passwords. You might be able to argue that these are "decryptable" because the encryption method is documented or the keys have been cracked or reverse-engineered. But I'd still stop short of saying that they're "reversible" - if only to avoid confusing others.

Only formats like base64 are truly reversible - and even though base64 was never intended for password storage, people use it for that all the time. Which is bad ... precisely because it is truly reversible: with a simple algorithm, any base64-encoded data, no matter how complex, can be instantly turned back into its original form - without having to do any non-trivial computation whatsoever.

These two commands take roughly the same amount of time to execute, without any analysis or guesswork:

$ echo cGFzc3dvcmQxMjMK | base64 -d

$ echo RzVqVW5YLXlKWDQK | base64 -d


Real hashes are different. They make harder passwords harder to crack - because when hashed, weaker passwords take less time to crack than stronger ones. In other words, as long as the hash format isn't truncating, even a weak hash will protect a strong password.

What about bruteforce / brute force?

Many people use 'bruteforce' when they actually mean 'crack'. For password crackers, 'bruteforce' means something very specific - trying all possible combinations of a set of characters (like 00000, 00001, 00002 etc or aaaaa, aaaab, aaaac etc.). The thing is, we do many other things that are much more efficient first - "straight" wordlist/dictionary attacks, wordlist + "rules" (instructions that transform one word into another word), combinator (two or more lists of words, concatenated), etc. We only resort to bruteforce attacks after these other methods are reasonably exhausted. And this is especially true for salted hashes, because we want to reduce the number of unique salts across the target list as quickly as possible, so that our attacks on the remaining hashes are faster.

So don't ask "how do I bruteforce this hash?". Ask "how do I crack this hash?"

So repeat after me ...

Bart Simpson at chalkboard, writing: Password hashes are not 'dehashed', 'decrypted', or 'reversed'.

And now, "thanks" to the anonymous colleague who "contributed" this, every time someone says one of these words, I can flip my ... rainbow table:

Every time someone uses one of these words, I flip my ... rainbow table.

Now I know how cryptographers feel about "crypto = cryptocurrency".


Cross-connect links to this page:


"When you're talking about decrypting, you don't literally mean hashes." - Solar Designer on john-users

"A hash is like a meat grinder. You can turn a cow into ground beef, but you cannot turn ground beef into a cow." - Neil McGuigan

Thanks to @bmenrigh and @hops_ch for impetus and insight.

Want to talk about more password stuff (or something else)? Ping me!