[Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI

[Henry B. Hotz]

On Sep 15, 2013, at 11:17 AM, Dmitri Pal <dpal at redhat.com> wrote:

> On 09/13/2013 06:06 PM, Henry B. Hotz wrote:
>> On Sep 13, 2013, at 11:38 AM, Dmitri Pal <dpal at redhat.com> wrote:
>> 
>>>> , ipatokenotpalgorithm
>>> Uses default TOTP we do not support more for now. In future it will be a
>>> global policy I assume.
>> This is just me, like the sig says.
>> 
>> I would advocate for HOTP, with a bunch of special processing for token counter regression.
>> 
>> If the token seed and current counter are stolen by a bad guy, and actually used, then at some point the bad guy or the real user are going to attempt an authentication using a value that's "old".  This presents an opportunity to detect that the theft took place.
>> 
>> I regard this as a real, useful security feature which is not possible with time-based tokens, provided the verification infrastructure is set up to do the detection, and to take some action when the detection occurs.  If the theft is done by a smart-enough adversary, there may be nothing to prevent them from resynchronizing the legitimate copy of the soft-token when they use it, but it still seems like a worthwhile capability.  It would detect the most obvious token-theft scenarios.
>> 
>> Obviously, this is out-of-scope for any of your current efforts, but I wanted to throw it in the mix for possible future work.
> 
> Count creates an overhead in the replicated environment. Effectively you
> need to replicate count on every authentication, this is a big cost.
> While it is more secure for the case you suggest it does not seem to be
> a good enough justification for the replication overhead. If stolen the
> chance that it will be used some tine later is really slim. It most
> likely will be used right away so the old code detection will be
> irrelevant. But we anticipate that there will be cases when HOTP will be
> needed, so we do not preclude implementing it in future but on the other
> hand do not see it as an immediate goal either.

If the bad guy uses the stolen seed immediately, yes it works.  However it advances the service's counter so the legitimate user will trip the monitor whenever he/she next uses the token.  

In other words the monitor will tell you of a problem, but it won't tell you if the user that demonstrated the problem was the good guy or the bad guy.  It also won't help if the good guy never uses the token at all after the theft.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu