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 Jan 2014 17:42:32 -0500
From: Bill Cox <>
Subject: Re: [PHC] A silly (?) consideration for script-friendly hashes

On Fri, Jan 24, 2014 at 5:13 PM, Andy Lutomirski <> wrote:
> If people are planning on having client-side offload, or, more
> generally, if whatever hash wins ends up with a highly optimized
> implementation in web browsers, there may be a problem: anyone who can
> get people to leave their browsers pointed at pictures of kittens that
> compute hashes in the background effectively has a big network of
> password hashers.
> This can be mitigated: in addition to salt, a hash function could take
> a domain as input.  Then web browser interfaces could enforce a
> same-origin policy on the domain parameter.
> (This adds minimal implementation complexity: just hash the domain in
> with the salt before using it to hash a password.)
> --Andy

I think this is supported in Catena and Escrypt already.  Catena calls
it "data", and Escript calls it "local parameters", but what it adds
up to is the caller can add any application specific data they like,
including the URL the browser is pointing to.  My favorite ideas for
using such fields are TrueCrypt key file hashes, and secondary
password specific secrets decrypted on the server with a master key.

So, all your solution requires is that all the browsers implement
native implementations of the password hashers, with an extra domain
input.  I think that's a great idea, though it will be a while before
that happens.


Powered by blists - more mailing lists