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: <20140120111935.GB24625@openwall.com>
Date: Mon, 20 Jan 2014 15:19:35 +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 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.

> Instead of efforts being focused on complicated implementations of
> client-side password hashing, the more sensible approach is probably
> mandating a minimum password complexity for which the PHC algorithm can be
> considered secure and accompanying that with advice on how to mitigate DoS
> and brute-force attacks against the application.

I think these areas of focus are orthogonal - well, except for us having
limited resources and potentially focusing on some of these areas too
much, neglecting the others.

As to "a minimum password complexity for which the PHC algorithm can be
considered secure", I think it depends on threat models, assumed
per-{password, account} costs for certain kinds of attackers, and what
is meant by "secure".  For practical purposes, the decision-making will
usually be different: what's a reasonable tradeoff between security and
usability.  In many cases, this will translate to using password policy
settings that are below what we'd otherwise define as minimum "secure"
ones, yet we'd want better password hashing in those cases as well (such
as to better protect a subset of accounts against a subset of threats).

I think this is mostly beyond scope of PHC (although these things may
reasonably be worked on by the same people).  The only portion under
scope is "per-{password, account} costs for certain kinds of attackers"
for different defender's cost settings, similar to info included in the
scrypt paper, but expanded to cover not only ASICs, but also relevant
pre-existing hardware (that some attackers are likely to use).

Alexander