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: Thu, 12 Mar 2015 21:41:23 -0700
From: "Jeremy Spilman" <>
Subject: Re: [SPAM] [PHC] Password hashing by itself is not enough

On Thu, 12 Mar 2015 21:19:00 -0700, Bill Cox <> wrote:

> If the recent file that was posted with 10 million  
> user/password combinations is representative of user behavior, then a 5  
> >million entry dictionary will contain over half of all user's  
> passwords.  The first half of this file has over half of the passwords  
> repeated in the >second half.

Hashing defense is latency cost multiplied by password complexity. You  
need both the latency to be high on adversary hardware, and the password  
complexity to be high, before you can defend against a targeted offline  

> A solid upgrade to Scrypt will not be enough to secure the weaker half  
> of these passwords.  Should the PHC recommend that master secrets of  
> >some sort be added to the key material, so that if the password  
> database is stolen, but not the master secret, no harm is done?  There  
> is no >parameter for additional secret key material in the PHS  
> function.  Would it make sense to add one?  Secret key rotation is  
> another issue.  Instead >of hashing in the secret key as additional key  
> material, the secret key could be used to encrypt the resulting password  
> hash before storing it.  The >official hash result would be the  
> encrypted value, but the master secret could be updated.

Having a key is probably a net benefit over not having it, but some people  
will argue it's not worth the minor risk of losing the key, or somehow  
implementing the HMAC incorrectly.

Another way I proposed is blind hashing / security by obesity. A very  
large common data pool can provide offline attack resistance for a large  
number of users at a very low cost per user. It's a very efficient way to  
defend the hashes. Google 'blind hashing', and I would love your feedback.
Content of type "text/html" skipped

Powered by blists - more mailing lists