[<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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
