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: Mon, 27 Jan 2014 18:06:59 +0000
From: Peter Maxwell <>
Subject: Re: [PHC] Opinions sought on whether a specific side-channel leakage
 is ok.

On 27 January 2014 17:03, Bill Cox <> 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

Powered by blists - more mailing lists