phc-discussions - Re: [PHC] simplifying yescrypt

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]

Date: Tue, 21 Oct 2014 18:05:21 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] simplifying yescrypt

On Tue, Oct 21, 2014 at 12:13:06AM -0400, Bill Cox wrote:
> Hypothetically, I can imaging going to work for some huge
> corporation... like Google for instance, maybe even in their
> authentication group.  In that case, if I were going to internally
> promote Yescrypt based password authentication servers, it might be
> the case that many of my peers know even less about password hashing
> than me.
> 
> I think my first challenge would be to convince people of the value of
> ROM in the first place.  That's easy - it eliminates botnet attacks.
> After that, explaining why we need *two* forms of ROM, and how that
> makes password hashes more secure is actually beyond my skill level
> right now.

I think the two ROMs setup would be primarily for authentication service
providers - companies for which this is part of their core business.
It's not very hard to explain: it's to require that attack nodes have
reasonably fast access to even more data (TBs rather than GBs) while
also requiring very fast access to the smaller ROM's data (GBs).

With only few (but large scale) potential deployments, I guess this can
in fact be out of the PHC submission.  Just an extra that may be added.

> Somehow I feel we need to be able to delegate a proper password hash
> with the security of Makwa, while using a 1TiB ROM to defeat botnets,
> and only store a user's public key in the user database.  I was told
> about the idea of only storing user public keys rather than password
> hashes recently, and I think the idea has merit.  However, that means
> there is a private key sitting on an average user's cell phone, and
> that key needs proper pin/password protection with a good password
> hashing algorithm.  I certainly hope we can use a PHC winner for that :-)

Of course that's one of the use cases for PHC candidates.

Alexander