phc-discussions - Re: Re: Re: Re: Re: Re: Re: Second factor (was A review per day

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: <lusq8d$hpt$1@ger.gmane.org>
Date: Thu, 11 Sep 2014 11:39:08 -0700
From: Alex Elsayed <eternaleye@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: Re: Re: Re: Re: Re: Re: Second factor (was A review per day - Schvrch)

Andy Lutomirski wrote:

> On Thu, Sep 11, 2014 at 11:26 AM, Alex Elsayed
> <eternaleye@...il.com> wrote:
>> Alex Elsayed wrote:
>>
>>> Mm, with the parallel PAKE we've latched P as a necessary part of the
>>> protocol, so _here_ your original idea of passing H(P) to the token,
>>> which it uses to encrypt its (internal) value, would not weaken the
>>> scheme in the case of a malicious token.
>>>
>>> Given token T holding secret X, user U holding password P, and server S:
>>>
>>> U -> T: H(P)
>>> T -> U: Y = E(k=X, H(P))
>>> T -> S: R_t = PAKE(X)
>>> U -> S: R_u = PAKE(Y)
>>> T -> U: R_t
>>> U: K = R_t ^ R_u
>>
>> After I posted the correction to this yesterday, I realized that there's
>> an even more optimal approach combining this with my original scheme. It
>> satisfies all of the properties you brought up, _and_ the property I'd
>> like that the server doesn't even need to know that a token is in use at
>> all (permitting a user to add a token to any account they want to) -
>> without requiring any local storage on the user's machine.
>>
>> Let E( K, M ) be an encryption function with key K and message M
>> Let H( M ) be a hash of a message M
>> Let sizeof( H( A ) ) == sizeof( K in E( K, B ) ) for all A and B
>>
>> Given:
>>     Token T holding secret X
>>     User U holding password P and pin N
>>     Server S
>>
>> 1.) U and T establish a channel C by executing a PAKE over N
>> 2.) U sends H(P) to T over C
> 
> This step loses the property that a malicious token doesn't weaken
> security over no token at all -- a malicious token can do an offline
> dictionary attack on the password.

I'd argue that while it isn't _ideal_ (ideally, a malicious token couldn't 
do that, I agree) it doesn't weaken security over no token at all - because 
without a token (and thus X) the _server_ can perform a dictionary attack on 
the verifier - so really, you wind up exactly where you would be without the 
token as long as H is at least as secure as the verifier generation 
algorithm.

Since you should physically possess the token, and thus have more options 
when it comes to determining whether it's malicious or replacing it, I 
actually see that as a net improvement in the real world.

Especially since, overall, most tokens have less available compute power 
than servers :P

> I'll try to write up a formal statement of my personal desiderata for
> token-assisted PAKE next week :)
> 
> --Andy