On Thu, 2014-09-25 at 15:15 +0200, thierry bordaz wrote:
> On 09/19/2014 07:53 PM, Nathaniel McCallum wrote:
> 
> > This prevents synchronization when an authentication collision occurs.
> > 
> > https://fedorahosted.org/freeipa/ticket/4493
> > 
> > NOTE: this patch is related to the above ticket, but does not solve it.
> > For the solution, please see patch 0064. This behavior fix is from patch
> > 0062 (rescinded) and is worth keeping.
> > 
> > 
> > _______________________________________________
> > Freeipa-devel mailing list
> > Freeipa-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-devel
> Hello Nathaniel,
> .
>         My understanding is that during a pre_bind, the plugins
>         validates token codes (for example "HOTP") checking that step
>         ranges [-25..+25].
>         As soon as the token is valid, the new HOTPcounter is written
>         in the entry.
>         But in case of negative steps,I believe the otp-decrement
>         plugin will reject this update. 

HOTP never goes backwards. See line 188 in libotp.c. Even if this check
weren't present, we would *want* the decrement plugin to reject the
update.

>         If TOTPwatermark is updated and there is a second token code,
>         then clockOffset is also updated.
>         This update is done during a pre_bind, so if there are
>         parallel binds on the server, there is a possibility that
>         TOTPwatermark is updated from a bind and 'clockOffset' updated
>         from an other bind. 
>         An option is to do a single internal modify to update both.

We don't care about atomicity in this case. If two TOTP synchronizations
occur at almost the same time, the value of clockOffset will be written
twice with the same value. Since the values are the same, we don't care
which value gets written first.

Nathaniel

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

Reply via email to