phc-discussions - Re: [PHC] Opinions sought on whether a specific side-channel leakage is ok.

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-u6wZnySk_yZ1UVQ_PS-hckAmjbaVC+s4D2=yzJEejKiLQ@mail.gmail.com>
Date: Mon, 27 Jan 2014 18:06:59 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Opinions sought on whether a specific side-channel leakage
 is ok.

On 27 January 2014 17:03, Bill Cox <waywardgeek@...il.com> wrote:

> I've considered this scheme.  The problem I run into is that very weak
> passwords are still guessable, unless I force the user to wait an
> obnoxious amount of time.  For example, a password with only 12 bits
> of entropy could be guessed using the same machine as the user in just
> over an hour, if I limit the runtime to 1 second.  Also, users who do
> care about their password strength are typically the users who would
> want a full second of password hashing to protect it.  So, I came to
> the conclusion that 1-ish seconds is around the right number.
>
>
Very weak passwords are going to be guessable in all schemes so far
proposed anyway, unless you impose absolutely absurd computational
requirements for *every* password.  In this scheme, the defender gains by
not having to use as much computing power for strong passwords.

There is also an inherent "stupidity cost", viz. a user who chooses a weak
password is going to have to wait much longer :-)  (and I'd argue an
submission should specify a lower threshold for which it can be considered
secure anyway)

For me personally, 1 second is far, far to high for a production server.
 In a past life, I've been a sysadmin for busy servers/firewalls and I
would never have implemented something that takes a full second of
computing time per login.  So, we need to bias the game in the defender's
favour by some other method(s).

> As for the side-channel exposure, it bothers me some.  It could allow
> him to attack only the lowest complexity hashes.  If he threw out 9
> out of 10 based on complexity, he'd save himself 10X on compute
> effort.
>
>
Yes, he could attack only the lowest complexity hashes but he'll be paying
a much larger cost per attempt (remember the weaker passwords involve a
much higher work metric).  If the algorithm is designed properly, the
attacker shouldn't benefit at all from picking the weaker passwords.

Content of type "text/html" skipped