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-u7boem+N3cN47x6aMxe2K8Ct=JtE_6YigTfq+F3fSFuHw@mail.gmail.com>
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

Powered by blists - more mailing lists