Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Apr 2012 01:13:50 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: 'New' functionality added to JTR (finding salted passwords,
 without salts)

On 04/20/2012 12:34 AM, jfoug wrote:
> Well, the 2 formats I have been working on are:   PHPS/dynamic_6, which is
> md5(md5($p).$s) with 3 byte salt, and osCommerce (dynamic_4), md5($s.$p)
> with a 2 byte salt.  Both of these formats have salt values from a space
> char, up to 0x7e (the '~' tilde char).  From some initial testing, I found a
> lot of the PHPS (I have about 800k of them), and also there are a lot of
> OSCommerce (I am just starting to collect them).

That's interesting. But under normal circumstances, you probably
wouldn't throw away the salt. (Or are there systems which compute the
hash with a rendom salt, but don't store the salt?
This would mean that during login up to 95**2 or 95**3 combinations need
to be tried.

After cracking several passwords, did you detect any patterns, i.e.,
non-random salts?
Either a non-uniform distribution of salts, or a salt which (due to a
broken implementation) based on the password?

For DES, I know that some implementations used the password as the salt,
so that "password" would result in "pa" becoming the salt.
Other broken implementations would use "or" as a salt for passwords of
length 8, "56" for password "1234567", "12" for password "123".
If the user picked a password of a length > 8, then you'd have
"78" for password "123456789" or "89" for "1234567890", "90" for
"1234567890x", but of yourse the password would be cut to the length 8.

I've even seen "123456" as a salt in an md5 hash for password "123456".
Probably the same people who used the password as a salt in their DES
implementation later learned that md5 is more secure than DES.


If there are implementations which are broken in a similar way, you
could try to avoid checking all possible combinations sequentially.
Instead, you could try to check for those salts for broken
implementations first.


Frank

Powered by blists - more mailing lists

Your e-mail address:

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