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]

Date: Sun, 19 Jan 2014 12:40:05 -0800
From: Larry Bugbee <bugbee@....com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Native server relief support for password hashing in browsers

Another thought...

Correct me if I'm wrong, but server-side PHC begins with a cleartext pswd and stores some manipulation of it for later comparison.  Client side assistance also begins with cleartxt pswd and sends a manipulation to the server who may or may not add additional manipulations before storage and later comparisons.  Okay, fine.

This suggests that whatever is done on the client side needs to be replicated exactly on the server should the user go to another machine/bowser without support and sends a cleartext pswd.  Okay, that works.

The flip side is what concerns me.  If we come up with a server side PHC requiring lots of memory, memory filled with random patterns and the like, then client-side assistance will not be possible unless some major portion of the server's algorithm *can* be replicated on the client.  ...meaning, if client-side assistance is to be expected at some future date, the algorithm needs to be divisible such that the size of the intermediate work sent to the server is manageable.  ...and it is clear to the server just how much work was performed to get this intermediate result.

Will the submissions be designed so client-side assistance will be practical?