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.