phc-discussions - Re: [PHC] Native server relief support for password hashing in browsers

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

Message-id: <2016DD0D-7528-4163-A1E9-3C3B69727760@mac.com>
Date: Sat, 18 Jan 2014 13:12:41 -0800
From: Larry Bugbee <bugbee@....com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Native server relief support for password hashing in browsers

PHC makes sense for pswds at rest on the server.  But...

May I assume that if the pswd is hashed client side, two conditions need to be true: 1) javascript or other hashing support is available, and 2) the hash is passed in a secure tunnel?  If no tunnel, what's the difference between sending the hash and cleartext to anyone monitoring traffic?  

For transit, it seems to all come down to a tunnel.  And if a tunnel, how authenticated?  How can we be sure/guarantee the client can auth the server?  ...or is there something I'm missing?