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, 20 Jan 2014 15:02:09 +0100
From: Christian Forler <>
Subject: Re: [PHC] Native server relief support for password hashing in browsers

On 19.01.2014 23:39, Solar Designer wrote:
> On Mon, Jan 20, 2014 at 02:28:20AM +0400, Solar Designer wrote:
>> That said, this may well be beyond scope of PHC (unless something
>> unexpectedly clever yet simple emerges), and Catena's builtin "server
>> relief" is only the tip of the iceberg.  It is very nice that Catena
>> standardizes just one hash type for both server-only and client+server
>> uses (without that functionality built in, it'd end up being 2+ hash
>> type variations), but it doesn't address the more complicated issues.
> BTW, if I understood Catena's server relief design correctly, it looks
> compatible with RFC 5802 (SCRAM), which I happened to have described in
> my own words here (before I learned of the RFC):

Yes, it is indeed the same idea. I think we have to cite your work. :-)

Your protocol is a little bit more sophisticated since it offers
protection against passive adversaries.

> For this algorithm to work, the server only needs H(Hs(password, salt)).
> This is very nice if so, meaning that exact same standardized hash type
> may be used for storage on the server both for SCRAM and for plaintext
> logins (possibly over a secure tunnel).

Yes. This is nice. :-)

Best regards,

Download attachment "signature.asc" of type "application/pgp-signature" (535 bytes)

Powered by blists - more mailing lists