Re: [OATH-Toolkit-help] TOTP - pam module doesn't store h/w key drift

[Ilkka Virta]

On 28.4.2013 20:58, Sergey wrote:
> > 1) The hw clock has a constant offset
> > 2) The hw clock actually drifts during use, so the offset changes

> I have a h/w key I use for ~2 years. In fact it has both issues -
> offset –130 steps and drift around -3/ steps a year.
>
> The first problem can be solved by either manually setting the shift
> in config or making a big window, so after the first successful login
> this shift will be stored in config. Then one can change window back
> to normal 3—5.
>
> The second problem is solved by the window — system always check
> +1/-1 step or more and then stores the calculated offset in config.

Yes, exactly. I'd go with manually entering the offset at the same with 
the key. It's not hard to find out the offset anyway, and if you have 
lots of keys, changing the configuration every time you add one would be 
silly.

If the drift is small enough, so that the clock on the hw token always 
stays within the window, then the offset could just be updated according 
to what the user gave, just as you said. But if the drift is larger, 
then the server would need to know the amount of drift beforehand to be 
able to compensate (without making the window bigger).

And actually, 3 steps or 90 seconds a year is only about 3 ppm, and I've 
heard numbers more than 10 ppm for crystal oscillators, so it could 
probably be worse. I guess this could be an argument for using HOTP 
instead of TOTP.

> The current code can be fixed to store the shift... I'm just not very
> familiar with C coding...

Hmm the usersfile has a couple of optional fields (last use timestamp, 
last used OTP, last counter value), so adding the offset as an 
additional field would require the users to fill in the optional fields 
to be able to set the offset.

Actually, it seems that the last login time is not even used anywhere, 
but it is checked for correct format. Also the fifth field 
(start_moving_factor) does not make any sense with TOTP. Instead of 
storing the last used OTP, shouldn't it be enough to save the last used 
counter/timestamp value (for HOTP/TOTP; they serve the same purpose) and 
use that?

I must be missing some bigger picture about those fields here (the 
documentation could be a bit more clear too), so I don't think I'll dare 
touch that with a patch.



> --------------
> <@)%%>{
>
> On 28.04.2013, at 20:53, Ilkka Virta <address@hidden> wrote:
>
> > On 18.4.2013 19:16, Sergey wrote:
> > > I have a h/w key which works okay but is ~ 1 hour back in past.
> >
> > Hmm. I thought about this (for other reasons) one day.
> > I can see two different issues here:
> > 1) The hw clock has a constant offset
> > 2) The hw clock actually drifts during use, so the offset changes
> >
> > I guess you only saw the first problem right?
> >
> > I wonder if the drift actually would be a problem, and how does commercial 
> > stuff (like RSA) deal with it, if it does.
> >
> > > I've crawled through the sources and I've made a test.
> > >
> > > The problem is — I have to set my window = at least 150, and then,
> > > after some successful authentications I can't change it to normal
> > > 3—4. PAM library just doesn't use all that time drift info. The field
> > > called ‘start_moving_factor’ just keeps increasing by 130 every time
> > > I log in. And, as I see in the code it's not used with TOTP =( I
> > > can't keep window=150, this make the whole thing useless.
> >
> > Is the current code even supposed to do anything to handle this?
> >
> > > Are you planning on fixing this?
> >
> > --
> > Ilkka Virta / itvirta at iki.fi


--
Ilkka Virta / itvirta at iki.fi