phc-discussions - Re: [PHC] Terminology goals

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CA+aY-u5-OjjWp6QJ9eg3qvoOHTpQEV4apmjx8QbRSg_M1L4ipg@mail.gmail.com>
Date: Wed, 21 Aug 2013 03:41:19 +0100
From: Peter Maxwell <peter@...icient.co.uk>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Terminology goals

On 20 August 2013 22:39, Jeremy Spilman <jeremy@...link.co> wrote:

[snip]

> 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
prices.

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