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 <[email protected]> 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
