| 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
| ||
|
Date: Fri, 24 Apr 2015 07:00:46 -0700
From: Bill Cox <waywardgeek@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Client-side hashing (was side-channel stuff)
On Fri, Apr 24, 2015 at 1:25 AM, Krisztián Pintér <pinterkr@...il.com>
wrote:
> On Fri, Apr 24, 2015 at 1:38 AM, Bill Cox <waywardgeek@...il.com> wrote:
> > If you compute H(salt || domain || password) when
> > talking to a remote URL, and send an ASCII hash digest instead of a
> > password, you gain a lot of protection, regardless of what hashing
> algorithm
> > the remote server uses.
>
> it is a very good client side password management option, but you need
> a costly H to be secure. developing such a H is our task here :)
>
True enough. I remain a fan of client-side memory-hard password hashing,
and server relief as Catena calls it. Server-side, you are lucky to get
more than a few milliseconds or enough memory to bust out of cache. I'll
take 200ms of client-side hashing any day, even if the client is a
smart-watch.
Here's a simple upgrade to password hashing that I wish every company would
support: If a password is in a specific long format that appears to be the
output of a hash function (20 hex digits?) then skip the password hashing
except for the last hash (as done with Catena's server relief), because the
client already did it for you. That way, you can support legacy clients
that send the password without hashing, while reducing server load and
improving security for everyone else.
Bill
Content of type "text/html" skipped
Powered by blists - more mailing lists