Re:Protectimus TOTP tokens with time synchronization are goi...
by icebraining on Tuesday April 30, 2019 @11:25AM
(#19788774)
> Not sure I follow... the sync happens because when the user sends an attempted TOTP code to the server, the server calculates a few codes just before/after the current time, and if they match, the server updates its cache of the token's clock drift. Nothing is stored on the client. Why would this not be an option? (It requires the same access as required to send it a code in the first place, no more.)
"The server" here is owned by the site where you're logging into, not by Protectimus, so you can't make it do those things. They found a way to fix the clock issue from the end they can affect.
Plus you need some input anyway, since the TOTP protocol requires a shared secret, and for some reason it became a standard that the server is the one providing it on setup.
Re:Protectimus TOTP tokens with time synchronization are goi...
by geofft on Tuesday April 30, 2019 @05:49PM
(#19792345)
Are there servers that don't sufficiently deal with clock drift on their own? (And TOTP devices that drift their clock by more than a few minutes a year?)
Re:Protectimus TOTP tokens with time synchronization are goi...
by icebraining on Tuesday April 30, 2019 @07:52PM
(#19793194)
Searching for "TOTP drift" seems to indicate it's a problem. I'm personally not very knowledgeable, but I've used a few TOTP libraries, and I don't remember any actually recording the detected drift like the RFC recommends. At most they allow for some drift from the current time, but that's usually up to 1-1.5mins, so if the token drifts more than that, it won't work.
> But users often don't have access to the authentication server, so Protectimus figured out a way of correcting the token's clock instead. The time will be resynchronized when a secret key is flashed to the to the token.
Not sure I follow... the sync happens because when the user sends an attempted TOTP code to the server, the server calculates a few codes just before/after the current time, and if they match, the server updates its cache of the token's clock drift. Nothing is stored on the client. Why would this not be an option? (It requires the same access as required to send it a code in the first place, no more.)
It seems like a serious negative to have a hardware token with significant complexity on board; at that point you're better off using a smartphone which gets software updates, because you have a platform that's rich enough to have vulnerabilities and an attack surface. (And you can do things like put a password on the smartphone.) Hardware tokens with no inputs, like RSA keyfobs, make more sense.