Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 30 May 2006 17:23:49 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: How does it actually dictionary attack salted hashes?

Randy B has already provided a response (thanks!), but I'll illustrate
it using the specific example from John Paine's posting:

On Mon, May 29, 2006 at 04:58:06PM -0400, John Paine wrote:
> If Unix password hashes normally contain a 12 bit salt, how can JTR, or any
> other cracking program who excepts /etc/shadow lines, be effective at
> allowing a user to supply a dictionary list? Lets say for example the salt
> was 'foobar' and the password was 'password'.  How do these cracking program
> allow a dictionary list to be run on a hash such as  foobarpasswordfoobar?

Obviously, the traditional crypt(3) with 12-bit salts does not use salts
like "foobar" and it does not simply concatenate salts with plaintext
passwords like in "foobarpasswordfoobar", but I'll use this example
anyway - just speaking of some abstract password hashing method.

Let's assume that our wordlist contains these lines:

12345
abc123
password
... and so on

(these are the first 3 lines from the common passwords list included
with John the Ripper 1.7).  Also, let's assume that we're cracking one
password hash, having a salt of "foobar", and the password from which
this hash was produced is "password".  The salt "foobar" is known to us
since salts are typically stored along with the actual hashes.

JtR can pick the first line from the wordlist - "12345" - and compute
its hash, using the known hashing method and the known salt "foobar".
Then it can compare the computed hash against the one it is cracking.
It will most likely see that they're different and conclude that the
password is not "12345".  So it picks the second line - "abc123" - and
repeats the same check, resulting in the same conclusion.  When it gets
to the third line, the computed hash will finally match the one being
cracked - so JtR will know that "password" is a valid password for the
given hash.

In practice, JtR may work a bit differently, computing multiple hashes
simultaneously and not doing the comparisons directly, but the above
description should be good enough to answer your question.

> I can see how brute forcing would work ...

As Randy has correctly pointed out, "brute-forcing" is not in any way
different as far as your question is concerned.  Perhaps you thought
that it would need to somehow crack the salts along with the passwords?
Well, this is not the case - the salts are readily known.

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments

Was I helpful?  Please give your feedback here: http://rate.affero.net/solar

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ