Message-ID: <CALCETrWcgwKJNfo3Pq=Y4Lfk1AXCksDH-T=ZAFwiCv4rjDRvSw@mail.gmail.com>
Date: Wed, 3 Sep 2014 15:39:09 -0700
From: Andy Lutomirski <luto@...capital.net>
To: discussions <discussions@...sword-hashing.net>
Subject: Re: [PHC] Re: Re: Re: Second factor (was A review per day - Schvrch)

On Wed, Sep 3, 2014 at 3:29 PM, Alex Elsayed <eternaleye@...il.com> wrote:
> Andy Lutomirski wrote:
>
>> On Wed, Sep 3, 2014 at 2:32 PM, Alex Elsayed
>> <eternaleye@...il.com> wrote:
>>> Andy Lutomirski wrote:
>>>
>>>> On Wed, Sep 3, 2014 at 12:31 PM, Alex Elsayed
>>> However, here's another try:
>>>
>>> The user 'U' holds a PIN 'N' and a password 'P'
>>> the token 'T' holds a secret value 'X'
>>>
>>> 1.) T and U execute a PAKE over N, yielding channel C_t
>>> 2.) U sends P over C_t
>>> 3.) T combines X and P, yielding Y
>>> 4.) A and T execute a PAKE over Y, yielding channel C_a (U relays
>>> messages) 5.) T sends its derived key for C_a over C_t
>>> 6.) U and A are now authenticated (or not, but 'not' leaks no
>>> information)
>>>
>>> I suspect the method used to combine X and P is pretty much irrelevant,
>>> since Y never leaves the token, meaning that the token can get away with
>>> being nothing more than a PAKE implementation and a tiny amount of
>>> storage.
>>>
>>> To recap your requirements:
>>>> a) Use of the token is protected by a passphrase.
>>>
>>> Yep - without the PIN, the initial secured channel cannot be established.
>>>
>>>> b) The token can't tell whether a given passphrase is correct or not.
>>>
>>> Yep - it simply composes the user secret and its own secret.
>>>
>>>> c) If the token is honest, then no one can test a candidate passphrase
>>>> without querying the token once per passphrase tested.
>>>
>>> Yep - because the token executes the PAKE protocol with the auth server,
>>> it can't be cut out of the loop.
>>>
>>>> d) If the token is stolen but the computer it's in remains
>>>> uncompromised, then the token is completely useless to an attacker.
>>>
>>> Yep - because of the properties of a secure PAKE, nothing that could be
>>> used to recover X ever leaves the token, and P was never present.
>>>
>>
>> Nice.  I think I agree, as long as P actually something derived from
>> the passphrase and something stored on the user's computer as opposed
>> to being an actual passphrase.
>
> I disagree - processing the passphrase before handing it to the token gives
> no additional security, AFAICT, because whatever you give to it is
> sufficient to authenticate as you. If someone snoops the processed whatever,
> the security failure is exactly the same as snooping your passphrase when no
> processing is done.

This is a downside of your scheme over my scheme.  In my scheme, even
a malicious token never learns enough information to masquerade as the
user.  Even in your scheme, the user could use the passphrase for more
than one thing safely as long as it's appropriately processed on the
computer.

>
> As a simplified case, imagine a server that stores H(P), and you send P in
> plaintext. Clearly, Eve can just snarf P off the wire, and authenticate as
> you.
>
> But the server storing H(H(P)) and you sending H(P) doesn't prevent that in
> any way; it just means Eve now snarfs H(P) and authenticates as you.
>
> Besides, why store _anything_ on the user's computer? The user types in N,
> and then P, and neither has any related data stored anywhere on the
> computer; the less you process P the less time it spends resident in memory
> as well. Treat it like a hot potato and hand it straight to the token.
>

Because I want to trust my token as little as possible.

> This also avoids "my hard drive died" failures.

Backups work, too.  But yes, point taken.

>
>> Maybe I should try to implement something like this for OpenSSH :)  If
>> only the world could agree on a simple, fast patent-free augmented
>> PAKE with a good security proof.  I think that some of the
>> EKE/Elligator stuff works nicely as a balanced PAKE.  I guess the IPR
>> situation for AugPAKE as specified in RFC6628 might be workable.
>
> SRP is clean AIUI - there was some FUD, but the relevant EKE patents a.)
> were explicitly avoided according to the SRP folks, b.) were never litigated
> and c.) expired in 2011/2013
>
> Or at least that's what I recall.
>
> Plus, OpenSSL already supports it.
>

SRP only works with modp groups, right?  If so, that's a bit unfortunate.

--Andy

Powered by blists - more mailing lists