[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 13 Oct 2022 18:07:02 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: using john to decrypt DES hashes
On Thu, Oct 13, 2022 at 03:55:32PM +0200, Matthias Apitz wrote:
> Do I understand you correct: I yescrypt all DES strings in the database
> and when the user presents the PIN 4711 I first crypt the with DES and
> the old salt 'xX' and the result with yescrypt and the stored "$y$...."
> salt and when this match the user is authenticated, correct?
That's correct.
In your example, though, a 4-digit PIN is too weak even when you use
yescrypt. You'll probably want to also introduce a password policy,
such as by using our passwdqc.
You could also improve things by using yescrypt's optional hash
encryption key and keeping it only on dedicated authentication server(s)
(or even dedicated password hashing servers), being careful not to
"expose" it via backup dumps, etc.
> What would be the security problem with this compared with direct
> application of yescrypt?
No exactly a security problem, but some aspects to be aware of:
1. descrypt truncates at length 8 and drops the 8th bit of characters.
However, if you were to crack your descrypt hashes and re-hash the
resulting plaintext with yescrypt, you'd have inherited this limitation
anyway. In fact, you could have created a usability problem: if a user
thinks their password is longer than 8 or uses 8-bit characters and they
continue to type that in, they'd be failing authentication after you
re-hash the descrypt-cracked version of that password with yescrypt,
unless you mimic descrypt's truncation before authentication. With
yescrypt-of-descrypt, you avoid this discrepancy - authentication will
continue to succeed.
For newly set passwords, this is of course a big deal - you don't want
those legacy limitations. So you need to use pure yescrypt for those.
This probably also means you need to tag yescrypt-of-descrypt vs. pure
yescrypt hashes differently (or otherwise you'd have to compute two
yescrypt hashes per authentication attempt, which would force you to
halve yescrypt's running time, thereby lowering its attack resistance by
a factor of up to 4).
2. If some of your users are also with another service that uses
descrypt and happens to have used the same salt (e.g., just randomly for
one user, since there are only 4096 different descrypt salts), and
password hashes from both services leak, then the leak of descrypt
hashes from the other service could be tested against your
yescrypt-of-descrypt hashes, and for the identified matches the descrypt
hashes could be cracked as a separate step. This two-step process can
potentially be quicker than attacking yescrypt-of-descrypt directly.
However, it is unlikely that such other service also uses the same fixed
salt, whereas for random salts only a small fraction of users would be
affected.
3. descrypt hashes are only 64-bit, which means collisions aren't too
unrealistic - and indeed some have been found.
However, this does not matter in practice since the input space is at
most 56-bit anyway, and you wouldn't avoid that "problem" by cracking
and re-hashing - you'd end up cracking the colliding passwords as just
one password anyway. Moreover, if you were to hit this problem (which
I'm sure you won't as the chances are negligible), then with re-hashing
you'd have authentication failures for the user who thinks their
password is different from what it could have collided with.
In your circumstances, I think you only need to consider aspect 1 (in
that you need to skip the descrypt step for newly set/changed passwords)
and disregard aspects 2 and 3.
Alexander
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.
