Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 13 Oct 2022 14:29:57 +0200
From: Solar Designer <>
Subject: Re: using john to decrypt DES hashes

Hello Matthias,

On Thu, Oct 13, 2022 at 11:18:59AM +0200, Matthias Apitz wrote:
> Me and my company are managing large databases wherein the PIN of users
> are hashed with UNIX crypt(3) in the old DES form and a fixed salt "xX".
> With large I mean some thousands. For data security reasons we want to
> move to a better algorithm, "yescrypt", and when the user provides the
> PIN in clear, it is checked against the old DES hash, and when correct
> the field in the database is updated to "yescrypt" by our software. So
> far so good. I also want to update the (remaining) old hashes to "yescrypt"
> before some hacker is using them, if he got access to the DES strings.

This makes sense, but you can instead use the existing DES-based hashes
as input to yescrypt.  That way, you can upgrade all of your hashes to
yescrypt-of-descrypt at once, without needing to wait for users to log
in nor cracking any hashes.

yescrypt-of-descrypt has subtly different security properties from
direct application of yescrypt, but it's certainly a major upgrade
compared to descrypt alone.

> My questions are:
> 1)
> As the salt is fixed and known as "xX" can this provided somehow to john
> to speed up the things?

Definitely, and this is automatically taken advantage of.

> 2)
> I saw the files below ~/.john and understand what they contain. But,
> even if I remove everything there and restart 'john pins.des', it knows
> somehow the already cracked PINs , some 3700 and starts working on the
> remaining 276, very slowly. One PIN in ~5 minutes. How this is managed,
> i.e. where the 3700 are stored?

They're stored in a file named john.pot.  Where that file is located
depends on how you built and run john.  You mention ~/.john, which
suggests you might be using (or also have installed) a system-wide
build.  If so, that build's john.pot would normally be in ~/.john as
well.  However, if you currently use a non-system-wide build, then its
john.pot file would be in the same directory with the john binary.

I recommend that you don't make your own system-wide builds - that's a
feature for use by distros, not on end systems.

As to it cracking the remaining hashes slowly, that's to be expected -
and you won't speed it up by forcing it to re-crack the previously
cracked hashes.  Sure it'll re-crack them quicker, but then it'll slow
down on those same remaining hashes just the same.


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.