[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221013122957.GA21388@openwall.com>
Date: Thu, 13 Oct 2022 14:29:57 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
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.
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.
