Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Jan 2006 19:41:59 +0000 (UTC)
From:  Radim Horak <yesbody@...nam.cz>
To: john-users@...ts.openwall.com
Subject:  Re: salt manipulation

Arias Hung <arias@...> writes:

> 
> Hello All,
> 
> How would I go about customizing which salts in particular I would like like 
tried before all others?  The
> documentation seems to imply something along this line since c/s values are 
provided for one salt
> (implying being able to focus jtr on just using one salt?)  compared to 
numerous saltc/s benchmarks  so
> maybe i'm missing something obvious.  Is this possible?
> 
>    In my case I'm referring to just traditional DES.  
> 
> For instance say i successfully crack a password with hash string 8wA2fClJsg 
and I want to try to crack a
> different file trying all combinations with the 8w salt.  
> 
> Does anyone know if this is possible?
> 

Hi,
 I'll try to answer, maybe Solar Designer will provide more thorough explanation 
later. The answer is: It doesn't work that way. 
Cracking password with certain salt doesn't help with cracking other passwords 
with the same salt. You have to understand how salts work to exploit that 
feature.

 In saltless password, the hash is _identical_ for different users with the same 
password. When you are testing password candidates, you need to make only 1 hash 
per candidate and then you can compare it to hashes you are cracking. It is 
equivalent to situation with salted passwords if only 1 salt would be used.

 However, in Traditional DES, there are 4096 possible different salt values. The 
 salt is added to the password and then they are hashed together. This results 
in situation, where different users with the same password have _different_ 
hashes. 
ie. psw. "secret" with salt 8w (for user01) is hashed to "8wHeWHgebNWE6"
    psw. "secret" with salt 9w (for user02) is hashed to "9wqCrC32x/Xto"

 The salts are then stored as a part of the hash. As the salts are assigned 
randomly, the sum of salts actually used is random, but it's similar the number 
of users and its 4096 max (12-bit value).  If you want to test certain password 
candidate, you need to hash it with each used salt and compare the resulting 
hashes.

  For example: You have 500 users, they have total of 500 password hashes and 
there is 450 different salts used. This means that 50 users have the same salt 
as somone else. If you want to test 1 password candidate, you have to do 450 
hashing operations and each generated hash compare to every user's hash.
Practically this means that salting slowed down the cracking 450-times. 

  But with john you can take advantage of the multiple salts used for that 50 
users. Let's say, that exactly 100 users are unknowingly sharing those 50 salts, 
ie. each of this 50 salts is used for 2 user's passwords. If you reduce your 
cracking only to these passwords, that used these salts, you only need to do 50 
hashing operations. You can then test 1/5th of users 9-times faster (as oposed 
to 5-times faster, which is proportional to reduction in number of hashes). 
ie. john --salts=2 passwd-file

  Focusing john only on one salt is useful only if that particular salt is used 
in a high number of passwords (I estimate at least 10). It is better to use the 
--salts option to automatically choose the most offen used salts.

 Unfortunately I don't know if there is an option to limit john only to password 
with specific salt. I think there isn't since it is not particularly useful. You 
can however manually find all users, whose passwords use that specific salt and 
specify them to john via --users option.
ie. john --users=user01,user15,user37

 Finally, hashing operation vaguely equals to encryption and is the slowest part 
in cracking. The reason for c/s values in benchmarks being different for 
multiple salts is not easy to explain. John uses algorithms optimized for 
multiple "parallel" hashing operations with the use of MMX. It is therefore 
little faster to use multiple salts in single run then multiple runs with single 
salt. The c/s values reflect this effectivity in the benchmarking values.

-Radim

Powered by blists - more mailing lists

Your e-mail address:

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