phc-discussions - A silly (?) consideration for script-friendly hashes

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-next>] [day] [month] [year] [list]

Message-ID: <CALCETrVz0dhKSnDTbgXOm1Xs=2sLFZeci+64Ps5fBtz-_vrGEw@mail.gmail.com>
Date: Fri, 24 Jan 2014 14:13:42 -0800
From: Andy Lutomirski <luto@...capital.net>
To: discussions <discussions@...sword-hashing.net>
Subject: A silly (?) consideration for script-friendly hashes

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