phc-discussions - Re: [PHC] How important is salting really?

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]

Date: Fri, 12 Dec 2014 03:13:34 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] How important is salting really?

On 12 December 2014 at 02:09, Thomas Pornin <pornin@...et.org> wrote:
>
> On Fri, Dec 12, 2014 at 01:21:32AM +0000, Marsh Ray wrote:
> > So the old security properties given by salting were:
> >
> > A.      Prevents precomputation TMTO via rainbow tables
> >
> > B.      Prevents attackers from re-using work on one hash against another
> >
> > C.      Prevents the trivial determination that two accounts chose the
> same password
> >
> > Today
> >
> > (A)   may be still important
> >
> > (B)   Is important to the extent that the attacker is not targeting a
> specific user.
> >
> > (C)   Seems almost useless now.
>
> I am not sure reason "C" has ever been important, although I am ready
> to believe that some people thought it mattered.
>

(C) may come back into play again, albeit marginally.

If commonly chosen passwords have an incidence of, say, 0.5% in a database
(not unreasonable from what I can tell), there is a suitably large number
of hashes in the database, and the work involved in calculation of a single
hash is high then it might be of use.  For example, a database with 1m
password hashes implies around 5k duplicates of each of the very most
common passwords; if those aren't salted then an attacker can both reduce
their work commitment by the number of duplicates but also readily identify
them a priori as weak passwords.  It does however require the work-per-hash
to be rather onerous indeed.

There may be a more subtle argument to be made here involving frequency
distributions of passwords but I'm far too tired at the moment to advance
it.

>

Content of type "text/html" skipped