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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Apr 2015 07:00:46 -0700
From: Bill Cox <>
To: "" <>
Subject: Client-side hashing (was side-channel stuff)

On Fri, Apr 24, 2015 at 1:25 AM, Krisztián Pintér <>

> On Fri, Apr 24, 2015 at 1:38 AM, Bill Cox <> 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

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.


Content of type "text/html" skipped

Powered by blists - more mailing lists