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: Mon, 20 Jan 2014 19:01:30 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Native server relief support for password hashing in browsers

On Sun, Jan 19, 2014 at 10:48:22PM +0000, Poul-Henning Kamp wrote:
> Well, the clever thing that's always available, so to communicate
> the the salt to the user over a secure channel and tell them to
> write it down for later use.

If by "over a secure channel" you primarily mean "after the user had
authenticated by some other means on their first login or registration"
(it could even be plaintext password login), then this prevents
precomputation of hashes for other users (since the corresponding salts
won't be obtainable) and probing for valid usernames via salts (since,
without a server compromise, it won't be possible to obtain and analyze
the salts without having access to those users' accounts first).  I like
this idea.

Another related (old) idea is to base the client-side salt solely on the
username combined with service name.  This doesn't prevent precomputation,
but it does prevent username probing.

Alexander