phc-discussions - Re: 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 11:27:15 -0800
From: Alex Elsayed <eternaleye@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: Native server relief support for password hashing in browsers

Christian Forler wrote:

> On 19.01.2014 08:54, Solar Designer wrote:
>> On Sat, Jan 18, 2014 at 01:14:32PM -0800, Tony Arcieri wrote:
>>> On Sat, Jan 18, 2014 at 1:12 PM, Larry Bugbee
>>> <bugbee@....com> wrote:
>>>
>>>> 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
>>>
>>> Yes
>> 
>> I'd say "secure tunnel" is orthogonal to "client-side hashing", as well
>> as to "better password hashing" in general.  Any of these are somewhat
>> nice to have even without the others, although of course a combination
>> of them is usually preferable.
> You are right, but in the following I want to paraphrase your statement
> in a very explicit way to prevent misconception.
> 
> Secure server-relief requires a secure channel, otherwise an adversary
> can just eavesdrop the transmitted hash to impersonate Alice.
> 
> Example:
> Suppose F() is time and memory costly KDF (e.g, scrypt), and
> H() cryptographic hash function (e.g. Blake2).
> 
> 1. Alice (e.g. javascript running in a browser) computes
> x = F(password || salt).
> 
> 2. Alice sends x to the server over an insecure channel
> 
> 3. Eve eavesdrops x.
> 
> 4. Bob (server) loads Alice password hash h_alice,
> and then tests if h_alice = H(x). If so Bob grants access, otherwise
> denies access.
> 
> 5. Eve can impersonate Alice by sending x to Bob.
> 
> 
> A countermeasure against passive adversaries are challenges (i.e.,
> random bit string).
> 
> Example:
> 1. Alice sent a access request to Bob.
> 2. Bob sends a challenge z (i.e., random bit string) to Alice
> 3. Alice response with y = H( H(F(password || salt)) || z)
> 4, Bob test if h_alice  =  H( h_alice || z).
> 
> But such a protocol is vulnerable to active attacks (e.g.,
> Men-in-the-Middle attacks).
> 
> 
> Conclusive, perform server relief over an secure channel (e.g., TLS)  if
> possible, otherwise your login process is as insecure as telnet.

There might be another possibility regarding server-relief protocols in the 
absence of secure channels - 'Augmented' or verifier-based PAKE. SRP in 
particular is an interesting option to consider there.

To quote the wikipedia article[1]:

"Usage of key derivation functions like PBKDF2 instead of simple hash 
functions for password hashing is highly recommended, taking into account 
that they only have to be computed on the client."

Simply by replacing H(s,p) with PHC(s,p), you instantly have a server-relief 
protocol simply due to the properties of SRP - and in the absence of SRP 
support (via JS in the browser or what have you) SRP can simply be run in a 
purely-local manner on the server.

In addition, it preserves the full security of SRP, obviating the need for a 
secure channel in order to use server-relief.

[1] https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol