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: <9232.1390171702@critter.freebsd.dk>
Date: Sun, 19 Jan 2014 22:48:22 +0000
From: "Poul-Henning Kamp" <phk@....freebsd.dk>
To: discussions@...sword-hashing.net, Solar Designer <solar@...nwall.com>
Subject: Re: [PHC] Native server relief support for password hashing in browsers

In message <20140119222820.GA23153@...nwall.com>, Solar Designer writes:

>Think of it this way: having a hash go over a potentially snooped upon
>wire is no worse than having a plaintext go over the same wire, but it
>may be better in two ways: by not immediately/always revealing the
>plaintext (possibly reused elsewhere and allowing for access to more
>than the target account) and by reducing server load (or increasing the
>total amount of hashing performed on client+server combined, thereby
>making password hashes at rest more resistant against offline attacks).

I'll buy the first argument, but not the second.

However, given the current threat situation, the first argument is
on the books with a near-nill value in my ledger:  Most surveillance
these days is persistent.

The second argument I don't buy at all, because I don't think we
want to mandate client participation, and if we don't, there has
to be a way for a client to say "no can do", and guess what: The
bad boys will always do that.

>Also, there are many Eves.  Failing to protect from some of them doesn't
>mean we shouldn't protect from any.

I agree with that, but in my mind mandating client participation
cuts a LOT of usability from the algorithm, so it is not a step
I'm willing to take for slight gains.

>That said, this may well be beyond scope of PHC (unless something
>unexpectedly clever yet simple emerges) [...]

Well, the clever thing that's always available, so to communicate
the the salt to the user over a secure channel and tell them to
write it down for later use.

That opens the floodgates to using the same password for one-time-auth
over unsecure channels (server issued nonce hashed with output of
PHC_winner(password))  but that is more of a protocol thing than a
PHC submission feature.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@...eBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.