phc-discussions - Re: [PHC] Native server relief support for password hashing in browsers

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: <20140120144324.GA25456@openwall.com>
Date: Mon, 20 Jan 2014 18:43:24 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Native server relief support for password hashing in browsers

On Mon, Jan 20, 2014 at 03:02:09PM +0100, Christian Forler wrote:
> On 19.01.2014 23:39, Solar Designer wrote:
> > http://openwall.info/wiki/people/solar/algorithms/challenge-response-authentication#Stored-on-the-server
> 
> Yes, it is indeed the same idea. I think we have to cite your work. :-)

I've just checked: even though RFC drafts eventually leading to RFC 5802
appeared in 1997 (which I was unaware of until 2012), their first
mention of slow hashing on the client appeared in the draft from 2007:

http://tools.ietf.org/html/draft-newman-auth-scram-04

It's the Hi() function, which wasn't defined in the -03 draft (1998).

My first mention of slow hashing on the client is in a sci.crypt posting
from 1999:

https://groups.google.com/d/topic/sci.crypt/eh4GHsWKKbA

"performance:
	only the inner hash should preferably be slow (iterated)
	the server's performance is not affected by the inner hash"

I don't know if slow hashing off-load to the client was ever mentioned
before or not.

BTW, re-reading that tiny sci.crypt thread may be relevant to PHC.

Alexander