Re: [OATH-Toolkit-help] Patch to include totp validation to the pam module

[Simon Josefsson]

(Re-adding address@hidden to cc list.)

Rien Broekstra <address@hidden> writes:

> On 4/25/2011 11:26 PM, Simon Josefsson wrote:
>
> [snip]
>
>> The main reason that I didn't push this to master, and an aspect that I
>> think IS important, is that I haven't figured out how TOTPs are used in
>> the real-world: do you want the last OTP to successfully authenticate
>> more than once even if it is within the current window?  Also, the code
>> right now has a negative search window, which may result in permitting
>> OTPs that are older than the last OTP seen, if it happens to be within
>> the search window.  That seems bad.  The code should probably use
>> start_moving_factor in some way.  Or something.  It has been a long day
>> and it is too late for me to think about this further now...
>
> I think every code from a totp token should be invalidated once it has
> been used successfully to authenticate. Otherwise it would be
> relatively easy for an attacker to sniff the password and reuse it
> within the time window.

The code already handles that (you would get REPLAYED_OTP).  I just
added a self test to make sure we test for that, it seems important.

But what about OTPs not seen but are older than the last one seen?
Consider this TOTP stream:

123456 at time X
234567 X + 30s
345678 X + 60s
456789 X + 90s
567890 X + 120s

Let's say pam_oath receives the 345678 OTP at around time X+30s (because
the machine's clock is behind, or the token is moving too fast) and uses
the OTP for authentication successfuly.  Now the 345678 OTP cannot be
used again directly (you would get a REPLAYED_OTP).  But if pam_oath
receives the 234567 OTP it would permit the logon, I believe, since it
is not the last OTP and the 234567 OTP is within the acceptable search
window.  Now 234567 is the last OTP on record, and 345678 would be
accepted again.

I guess the code should record the moving factor used for the last otp
and not accept anything older than (or equal to) that value.  The
oath_totp_validate API may not be designed for that kind of use, but it
may be possible to get the behaviour we want anyway -- I'll have to
experiment a little.

Thanks for feedback!

/Simon