I’m talking about security tokens used by banks, Paypal, etc. You press a button and it gives a string of numbers that you use when logging in. I guess there are 2 ways to generate those numbers: based on the previous number or based on the current time. I’m thinking they use the current time, since it gives the same number if you press twice fast enough, and they don’t warn you about pressing without logging in, which would lead to the numbers losing sync with the server.
The bank says the code will expire in 1 minute. If the token can be used for 2 years, that’s only 1 minute over 2 years, while most watches lose 30 seconds a month. What timekeeping do they use?
Some implementations are designed to compensate for clock drift on the authentication server rather requiring them to keep accurate time.
The server accepts codes that are a bit earlier or later than expected when authenticating and can use that information to make a reasonable estimate of what time a fob’s clock should read at a given time.
They probably use a Quartz clock, with some accuracy tricks applied. The tokens usually have a lifetime of 3 years, and they can be resynced to the server (which usually relies on a GPS unit for clock accuracy) if they do drift.
Watches are influenced by thermal proximity to a human body, which can make them less accurate.
One of the most accurate watches I ever had was a $9 cheapie from Radio Shack. Recall it gained two seconds a month, and this was 20 years ago. Accurate battery-powered quartz clocks are easy. Ironically, keeping servers on accurate time is the harder task - what a cheap watch can do for under ten bucks involves atomic clocks, network time servers and a never-ending process to ensure the servers are getting the correct time.
On its own, the internal clock in the token can be expected to stay on time pretty well for its designed life. There’s no worries about the thing slowing down as the battery starts to die as all tokens have a finite end of life date. Once they hit that date, they will either shut down completely or display “OFF.”
Aside from that, the authentication servers are surprisingly tolerant of drift. RSA’s ACE application knows what a given token’s code should be at any given moment, and it also knows the valid codes for a couple of minutes either way. There are other token systems out there, but ACE happens to be the one I used to work with.
If you log in and give the ACE server the code it’s expecting, all is well and you get in. If you give it a code that it calculates to be for two minutes ago (and that code has never been used before), it notes that your token is a bit slow so it can adjust its expectations the next time you log in, and you get in.
It’s been a while since I was hands-on with ACE servers and RSA tokens, but I recall that the allowable “drift window” can be widened or narrowed by the administrator. If a code is outside of that window, the user has to call the help desk to have the server re-synched to the token. We’d call it re-synching the token as that makes sense to users, but in reality, there’s nothing we can do to the token itself to adjust it.
With time-based tokens such as SecurID the server keeps track of the drift like John H said. If you don’t use your token for a long time it can drift outside the allowable window. In this case the user will be asked to wait for the code to change then enter it again. The clocks in the tokens are pretty good, I can go months without using mine without it going into next tokencode mode.