phc-discussions - Re: [PHC] 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]

Date: Thu, 11 Sep 2014 12:12:56 -0700
From: Andy Lutomirski <luto@...capital.net>
To: discussions <discussions@...sword-hashing.net>
Subject: Re: [PHC] Re: Re: Re: Re: Re: Re: Re: Second factor (was A review per
 day - Schvrch)

On Thu, Sep 11, 2014 at 11:39 AM, Alex Elsayed <eternaleye@...il.com> wrote:
> 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.
>

Yeah, fair enough.  I guess that, if you're not willing to store a
blob on your computer, then that's the best that you can do.

On the other hand, for some token designs, you might have no choice --
tokens with no storage will require you store a blob somewhere.

--Andy