Why can't a password hash be reverse engineered?

I've looked into this ages ago and have read lots on it, but I can't find the explanation of why it can't be done. An example will make it easier to understand my question and to keep things simple we will base it on a hashing algorithm that doesn't use a salt (LanMan).

Say my password is "Password". LanMan will hash this and store it in the database. Cracking programs can brute force these by hashing password guesses that you provide. It then compares the generated hash to the hash in the database. If there is a match, it works out the password.

Why, if the password cracker knows the algorithm to turn a plain text password into a hash, can't it just reverse the process to calculate the password from the hash?


  This question was IT Security Question of the Week.
  Read the Feb 24, 2012 blog entry for more details or submit your own Question of the Week.


Let me invent a simple "password hashing algorithm" to show you how it works.  Unlike the other examples in this thread, this one is actually viable, if you can live with a few bizarre password restrictions.  Your password is two large prime numbers, x and y.  For example:

x = 48112959837082048697
y = 54673257461630679457


You can easily write a computer program to calculate xy in O(N^2) time, where N is the number of digits in x and y.  (Basically that means that it takes four times as long if the numbers are twice as long.  There are faster algorithms, but that's irrelevant.)  Store xy in the password database.

x*y = 2630492240413883318777134293253671517529


A child in fifth grade, given enough scratch paper, could figure out that answer.  But how do you reverse it?  There are many algorithms people have devised for factoring large numbers, but even the best algorithms are slow compared to how quickly you can multiply x by y.  And none of those algorithms could be performed by a fifth grader, unless the numbers were very small (e.g., x=3, y=5).

That is the key property: the computation is much simpler going forwards than backwards.  For many problems, you must invent a completely new algorithm to reverse a computation.

This has nothing to do with injective or bijective functions.  When you are cracking a password, it often doesn't matter if you get the same password or if you get a different password with the same hash.  The hash function is designed so it is hard to reverse it and get any answer at all, even a different password with the same hash.  In crypto-speak: a hash function vulnerable to a preimage attack is utterly worthless.  (The password hashing algorithm above is injective if you have a rule that x < y.)

What do cryptography experts do? Sometimes, they try to figure out new algorithms to reverse a hash function (pre-image).  They do exactly what you say: analyze the algorithm and try to reverse it.  Some algorithms have been reversed before, others have not.

Exercise for the reader: Suppose the password database contains the following entry:

3521851118865011044136429217528930691441965435121409905222808922963363310303627


What is the password?  (This one is actually not too difficult for a computer.)

Footnote: Due to the small number of passwords that people choose in practice, a good password hash is not merely difficult to compute backwards but also time-consuming to compute forwards, to slow down dictionary attacks.  As another layer of protection, randomized salt prevents the use of precomputed attack tables (such as "rainbow tables").

Footnote 2: How do we know that it is hard to reverse a hash function?  Unfortunately, we don't.  We just don't know any easy ways to reverse hash functions.  Making a hash function that is provably difficult to reverse is the holy grail of hash function design, and it has not been achieved yet (perhaps it will never happen).
