On 09/13/2013 06:06 PM, Henry B. Hotz wrote:
> On Sep 13, 2013, at 11:38 AM, Dmitri Pal <d...@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.

>
> ------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to