phc-discussions - Re: [PHC] 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: Wed, 3 Sep 2014 14:46:41 -0700
From: Andy Lutomirski <luto@...capital.net>
To: discussions <discussions@...sword-hashing.net>
Subject: Re: [PHC] Re: Re: Second factor (was A review per day - Schvrch)

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.

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.

--Andy