Message-ID: <CA+aY-u7HVOseUaZVZr04=Xs0gE6PN=NUk6ZF+9Vi3qheciktFQ@mail.gmail.com>
Date: Mon, 20 Jan 2014 02:13:20 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Native server relief support for password hashing in browsers

On 19 January 2014 21:21, Poul-Henning Kamp <phk@....freebsd.dk> wrote:

> In message <3E7F59A0-A69C-45EF-9D39-68622DA14C7D@....com>, Larry Bugbee
> writes:
>
> >Will the submissions be designed so client-side assistance will be
> >practical?
>
> Is client-side assistance without a secure tunnel ever practical ?
>

Answering a different question first: in one sense, it's at least as good
as a cleartext password over an insecure channel.  In an insecure channel,
both a password and pwd_hash( password) are valid security tokens to access
the service in question - so it is security equivalent for the target
service.  The main difference is that an attacker may attempt to use the
cleartext password against other services whereas pwd_hash( password ) is
almost guaranteed not to work on other services.  So there is a small
advantage.  This is of course ignoring all the other possible attack
vectors on an insecure channel that we now know the NSA/GCHQ can bring to
bear.

If the practicality question is asking whether it provides protection
against an insecure channel then, no, it doesn't.  However, no
authentication mechanism is going to be secure if the channel isn't secure
as the attacker can always just hijack an authenticated session.




>
> I spent a lot of time researching this some years back, and concluded
> that it wasn't worth it.
>
> It may be my lack of imagination, but every scheme I came up with,
> required strong privacy for the connection, or the NSA[1] would be able
> to deduce the password given a small-ish number of session taps.
>

I came to the same conclusion for a different reason: 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.




>
> Any algorithm along the general scheme:
>
>         a = password
>         for i in N:
>                 a = crypto_graphic_hash(a)
>         [...]
>
> Would allow some fraction of N to be offloaded to the client, but this
> is a lot less useful than you'd think.


> If the number of rounds we ask the client to perform is constant,
> a trivial replay is possible.
>
>
​​Presuming the attacker has the hash generated by the client.  If they can
do that, they can also obtain the password in services without client-side
offload.​​  (unless I've misunderstood the thrust of your comment)




> It should not be overlooked that the client and server do in fact
> have a shared secret, even though the server does not keep it around
> in readble form.
>

​So do we design/use a more elaborate and robust authentication protocol,
or just assume the password is sent to the server over a secure channel?




>
> If you need to enter passwords over a non-private channel, you
> want to use *real* one-time-passwords (S/KEY or OPIE) you don't
> want some "ersatz" which gives you security "most of the time",
> but which fails fatally without any indication, if some bonehead
> somewhere f**ks up the implementation.
>
>
I suspect the advocated advantage of client-side password hashing is to
reduce the load on the server - for example, to prevent DoS attacks against
the password hash - not that it can fix the problem of sending a secret
over an insecure channel.

​The problems come when a provider must figure out how to do secure
password hashing on a heterogeneous set of clients.  Personally, I suspect
that will open up a whole world of hurt and client-side security
vulnerabilities when numpties start writing their own implementation of the
password hashing scheme in their favourite scripting language.

As you'd said in other posts, if the server needs to support devices that
cannot do client-side password hashing then the attacker can still DoS the
server simply by choosing the fall-back option.

There is also a discussion to be had on just how far we can actually go
when users pick passwords that can be brute forced at the application
level, e.g. https://github.com/blog/1698-weak-passwords-brute-forced (they
use bcrypt apparently but it wouldn't have mattered if they used scrypt or
anything else for that matter)

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.

Content of type "text/html" skipped

Powered by blists - more mailing lists