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  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: Wed, 03 Sep 2014 15:29:56 -0700
From: Alex Elsayed <eternaleye@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: Re: Re: Second factor (was A review per day - Schvrch)

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.

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.

This also avoids "my hard drive died" failures.

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

Powered by blists - more mailing lists