lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Aug 2013 03:41:19 +0100
From: Peter Maxwell <>
Subject: Re: [PHC] Terminology goals

On 20 August 2013 22:39, Jeremy Spilman <> wrote:


> Once an attacker has all the data required to run an offline attack,
> successful password cracking will always be a function of password
> complexity and hashing complexity. In a highly simplified view of 'weak'
> and 'strong' passwords, and 'weak' and 'strong' hashing functions, you
> would need both strong passwords with strong hashing to defend against a
> short-term offline attack.
> To put it another way, no amount of hashing complexity can protect a weak
> password from an offline attack. And most passwords are weak.

I'd second what Jeremy said.

If all users' passwords were sufficiently strong then md5 - in the absence
of better pre-image attacks - would arguably be sufficient but we all know
that is obviously not the case.  Unless someone gets terribly clever and
designs an algorithm that prevents an attacker with a copy of the password
db from testing candidate passwords, all we're doing is reducing the
probability that an attacker can find valid candidate passwords in a given
time-frame but they will still be able to test things like "password123"
and its ilk.

Instead of renaming things, I'd suggest - again - that we take a more
quantitative approach and adopt an agreed metric from which we can
approximately measure the resistance-to-brute-force property of the PHC
candidates.  We have good corpus data for user password choice and we
should be able to calculate rough computational requirements for each
algorithm: that's enough to construct a resilience metric, e.g. what % of
passwords are likely to be cracked by an adversary with £x to spend at 2013

A quantitative approach that provides a nice scalar number is likely to be
more useful to the average developer than new terminology that tells you
nothing new except the password storage scheme isn't a normal cryptographic
hash function.  For the end user who is being informed of a compromise,
we'll hopefully know whether PHC is being used... hopefully.

The other thing that came to mind from Marsh's original post concerned the
other data that services often store alongside the password, e.g. personal
data and the "forget password" question & answer.  I know this is out of
scope but it probably deserves discussion at some point as it's all very
well for us to solve the password hash problem but if the "forget password"
answers are stored in plaintext we've not done much (and many email
accounts are compromised by that very route).

Content of type "text/html" skipped

Powered by blists - more mailing lists