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

[Simo Sorce]

On Fri, 2013-09-13 at 15:06 -0700, 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.

Henry,
Thanks a lot for bringing this up.

I have to say that I never liked HOTP due to the burden it takes to
correctly manage them compared to TOTP and the hardest work around
synchronization. The worst part of it being the need to write AND
synchronize across the infrastructure at every authentication attempt
(replication). Something that could easily bring the whole
infrastructure to its knees at busy hours.

However HOTP has obvious advantages when it comes to identifying attack
attempts, so I'll start thinking hard how to deal with it wrt
performance.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York