phc-discussions - Re: [SPAM] [PHC] Password hashing by itself is not enough

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: <op.xve5y9payldrnw@laptop-air>
Date: Thu, 12 Mar 2015 21:41:23 -0700
From: "Jeremy Spilman" <jeremy@...link.co>
To: discussions@...sword-hashing.net
Subject: Re: [SPAM] [PHC] Password hashing by itself is not enough

On Thu, 12 Mar 2015 21:19:00 -0700, Bill Cox <waywardgeek@...il.com> wrote:

> If the recent 10-million-combos.zip 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  
attack.

>
> 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