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-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Apr 2015 17:01:37 +0200
From: Sascha Schmidt <>
Subject: Re: [PHC] Client-side hashing (was side-channel stuff)

Server relief, keyed hashing and client-independent updates are all
important features. The problem is that one can only have two of the
three at the same time. It maybe possible to get them to work
together, but this will result in a lot of different code branches
depending on the number of updates and so on.
Taking client-independent updates out of the equations seems reckless
in most scenarios. You would basically put an expiration date on the
password hashes.
In the end it probably depends on the scenario or if you see a reason
for keyed hashing at all.
For the Web case we are probably looking at Javascript for the client
side and I'm not sure if this wouldn't introduce sidechannels on the

Sascha Schmidt
Student of  Computer Science and Media M.Sc.
matriculation number: 80037

2015-04-24 16:00 GMT+02:00 Bill Cox <>:
> On Fri, Apr 24, 2015 at 1:25 AM, Krisztián Pintér <>
> wrote:
>> 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
> 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

Powered by blists - more mailing lists