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]

Date: Mon, 20 Jan 2014 20:45:25 +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:05:38PM +0000, Peter Maxwell wrote:
> On 20 January 2014 11:19, Solar Designer <solar@...nwall.com> wrote:
> > On Mon, Jan 20, 2014 at 02:13:20AM +0000, Peter Maxwell wrote:
> > > [...] if we're going to go
> > > to the bother of replacing the authentication mechanism on various
> > > services, surely we can do better than client-side password hashing.
> >
> > I agree, which is a reason why I think a PHC candidate's builtin "server
> > relief" support (if present) should be usable for some more advanced
> > than "pass-the-hash" authentication mechanisms.  Ideally, it should fit
> > some pre-existing ones.
> 
> So if we're moving towards a PBKDF that is suitable for, say, SRP then the
> "server relief" part of the PBKDF is pretty much redundant, is it not?

If it'd have to exactly match a PBKDF defined as part of e.g. SRP, then
indeed it won't be a new PBKDF and thus not relevant to PHC.  What I
meant is that we could have a new PBKDF that would otherwise fit an
existing authentication mechanism, either because that mechanism was
defined for arbitrary PBKDFs to be substituted into it, or with this
being the only deviation from its existing definition.

> Have we had a discussion on the PHC candidates in reference to password
> auth'd key exchange mechanisms as yet?

I think not yet, but I think they should just fit in.

Alexander