Date: Thu, 11 Sep 2014 12:27:26 -0700
From: Alex Elsayed <eternaleye@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: Re: Re: Re: Re: Re: Re: Re: Second factor (was A review per day - Schvrch)

Andy Lutomirski wrote:

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

True enough - my thinking has been along the lines of smartcards (or GNUK), 
where the _cheap_ ones are storage only, and the rest are storage + 
processing.

Then again, a token with no storage at all can't really have much in the way 
of a secret X - and if you _do_ store a (rather small - key-sized) blob W on 
your computer, you can just replace H(P) with H( E( W, P ) ), since H is 
only ever executed by U, thus preventing the token from brute-forcing (since 
W is strong randomness &c)

I just personally think the usability loss of storing a blob outweighs the 
security loss of not doing so, especially since it needs to be replicated to 
every machine that you want to log in from - making it (in a sense) a poor 
hybrid between a software 'token' and a saved password.

If you really worry about your token being malicious so much that you are 
concerned it might execute a computation-intensive dictionary attack, buy a 
BasicCard or a STM32 microprocessor, and write the code yourself (either on 
the BasicCard, for a smartcard-compatible form factor, or in GNUK, to make a 
USB token)

Powered by blists - more mailing lists