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  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?




Powered by blists - more mailing lists