Date: Wed, 03 Sep 2014 15:45:53 -0700
From: Alex Elsayed <eternaleye@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: Re: Re: Re: Second factor (was A review per day - Schvrch)

Andy Lutomirski wrote:

> 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.

My point is it doesn't actually trust your token any less.

Handing your token F(P) instead of P doesn't matter, because F(P) is still 
sufficient for a malicious token to never ask again if it stores it - and a 
malicious token disclosing P rather than F(P) only matters if your password 
hygiene is really terrible (reuse, etc).

Besides, the token _does_ rely on you relaying the second exchange for it - 
if it tries to do an exchange when you didn't _initiate_ an exchange, that's 
a 'KILL IT WITH FIRE' indicator; that leaves only that it surreptitiously 
stores what you give it and waits for someone to steal it from you.

>> 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.

True enough.

Powered by blists - more mailing lists