OTP codes created using a time-based solution (e.g. using a SafeID/Classic token) will obtain the current time using an internal clock that updates its time based upon oscillations of a quartz crystal. The crystal allows the device to keep relatively accurate time, but you can still expect the clock to drift by approximately one second every three days. Over the space of a year this drift can vary, but you expected time drift would be in the order of a couple of minutes.
If you are using the clock of a non-network connected PC or laptop, then the expected drift will be more likely to be 6 minutes per year or more. For networked computers this drift can be mitigated by ensuring that the computers clock is synchronised either with internet time, or with the time on the domain controller.
Time drift is not expected on mobile devices as they tend to have clocks synchronised with the mobile network carrier (and therefore should be expected to be within a few seconds of true time).
Time drift on the authentication server is also possible, but can be resolved by ensuring the servers clock is synchronised with an external reliable time server.
If the difference reported by the clocks on the client and on the server differ by more than the size of the time window (normally 30 or 60 seconds), then the OTP code generated by the client will not match the OTP code generated by the authentication server, and authentication may fail.
How do we check for time drift on hardware tokens ?
When the OTP code generated by a hardware token is failing to be accepted by the authentication server, it is possible to check the extent of any existing time drift using the following procedure;
Physical hardware TOTP tokens (such as the SafeID Classic token) are fully self-contained authentication devices with built in batteries that power both the LCD display, and the token's internal clock.
When the tokens are used they produce a 6 digit OTP code based upon the seed data that the token was programmed with, and the current time (as reported by the token's internal clock).
Token seed files are sent separate to the tokens themselves, and can be requested online (see How to request token seed or secret file for details on how to request this file).
Once you have both the physical token and the seed file you can test that the OTP codes generated by the device are correct using the following procedures;
Testing the generated OTP codes
In order to test the token we first need to extract the secret data for the token by searching the seed file for the record with a matching serial number;
The seed may have been requested in a number of formats, but for the purposes of this test we need the seed base32 encoded (digits "2" to "7 "and any letters of the alphabet).
If you received the seed data in Hex format (letters "A" to "F" and any digit) then you can convert the seed to base32 using the following online tool:
Once you have the base32 encoded secret, and checked the clock on your PC, navigate to the following online TOTP and replace the displayed secret key with the base32 encoded secret key for the token you are testing;
It is probable that your token uses 60 second windows (Time Interval in the above example), ensure that the Token Period in the online generator is updated to match the time period for your token.
The online generator will now be displaying 6 digit OTP codes that update with the same frequency your hardware token does. Turn on the token and check that the two codes match.
Determining the extent of any time drift
If the previous test produced codes that do not match then a few possible causes
The token is not time based (TOTP) but event based (HOTP)
The seed supplied is from a different token from your seed file (double check the serial number on the back of the token matches the extracted seed)
The supplied token period is wrong (try the test again using both 30 and 60 second time periods)
The token is functional, but there is some time drift
If time drift is involved we perform a different test to check the extent of time drift.
When a token is not producing OTP codes that match those generated using an online TOTP generator (using the seed/secret and token period for your pre-programmed token), then it is possible that the built-in clock on the pre-programmed token has drifted from the actual time.
Time drift on a pre-programmed token is to be expected, and token clocks will typically drift by approximately 1 minute every 6 months since purchase (the amount of drift can vary, but this is a good rule of thumb).
If your token has less than 10 minutes of drift, then it is still likely that the token can be registered for use with authentication servers (such as those used by Microsoft for Entra and Office 365) provided. you perform a manual activation of the token (see the "Activate Tokens" section of the following wiki guide);
Once the token has been manually activated, and provided the token is used more than once every few months, then any additional drift is likely to be accounted for (most servers follow the full RFC 6238 guidance that caters for addition drift on hardware tokens after registration).
How to identify how much drift has built up on a pre-programmed token
Whilst online TOTP generators can be used to confirm if time drift exists on the token, if drift is indicated, then we still need to identify how much the clock on the token has drifted.
Fortunately, we do have a tool that can be used for this task - the SafeID/Diamond programming tool;
Once the PC clock has been checked, and after downloading and running the tool you, will be presented with the following window;
We will use the button to display a table of expected OTP codes for your token, but first you will need to obtain the base32 encoded seed data for your token.
Find the serial number of the token you want to test (it should be printed on the back of the token), then open the seed file and find the corresponding Secret Key (example below);
The seed may have been requested in a number of formats, but for the purposes of this test we need the seed base32 encoded (digits "2" to "7"and any letters of the alphabet).
If you received the seed data in Hex format (letters "A" to "F" and any digit) then you can convert the seed to base32 using the following online tool:
Once you have the base32 encoded seed for your token click on the button on the programming tool, then at the prompt "Seed: (base32)" copy and paste the base32 encoded seed data for your token.
Next set the "Time Window" and "Display Time" to match the window size of your token (for tokens such as SafeID/Classic this will normally be 60 seconds), and leave the "Algorithm" option set to "SHA1";
Once the token seed data has been entered click on the button and a new window titled "One-Time Password" should open;
Using the horizontal scroll bar if necessary, view the list of OTP codes that are generated and compare them with the code shown on your hardware token, you will be able to determine the extent of time drift on the token.
Real World Example
If there is a small amount of time drift you should find that the code displayed on the token is also listed in the list of OTP codes shown on this window.
In this test we will identify the extent of drift on a SafeID Classic token with serial number "102601103200"
The following XML file was obtained for this token;
After checking the serial number at the back of our token matches the serial number in the source file, we find that the seed for this token was supplied in hex format with a value of "7952F56EC78D37D6225490ED102665C0131D058E".
Our tool requires the seed to be provided in Base32 format so first we must convert the secret from hex into base32 encoding (if seed data was already base32 encoded, then we could skip this step).
Using the online conversion tool we obtain a copy of the base32 encoded version of the seed;
We now supply our base32 seed ("PFJPK3WHRU35MISUSDWRAJTFYAJR2BMO") and time window setting (60 seconds) into our tool, then click on to obtain the expected OTP codes;
A new window now opens (titled "One-Time Password"), the current time window should already be selected (0), but to view the generated OTP codes we need to use the scrollbar (at the bottom of this window)
After scrolling we see that the currently expected OTP code is "529303", but when we view the OTP code of our token we see "029608"
After examining the OTP table we can see that the code displayed on our token is one position below the OTP code expected by the tool.
Given that the displayed codes represent what should be expected for each time window (60 seconds), then we have identified that our token has 1 minute of time drift.
What do we do if there is time drift ?
There are two main solutions to resolve issues caused by time drift;
Clocks that have drifted are adjusted to the correct time.
The drift is identified (typically by asking for 2 or more consecutive OTP codes) and once identified the drift is stored and accounted for when the next authentication takes place.
When authentication apps are used to produce the OTP code (such as SafeID authenticator and MobileID authenticator), then the clock is provided by the host computer, and when using an app on a PC, tablet or laptop, then the clock can normally be corrected by synchronising time with an internet based time server.
Introduction
On windows based PC's, laptops and tablets the time is normally obtained from a quartz crystal based clock that is maintained by a lithium ion battery on the motherboard of your computer.
In general you can expect time drift of 2 or more seconds per day (compared to about 1 second every 3 days from a typical hardware token), but can be greatly improved if the PC is automatically synchronised with an external source (either an internet time server or the clock on the local domain controller).
Correcting the time on a windows computer
There are many possible solutions to identifying and correcting the clock on your local computer, but one of the simplest is by using the service provided by time.is
After opening a browser window to the TIME.IS web page you will be presented with a clear indication of any drift between you computers clock and the remote time server;
As can be seen in the above example the test computer was less that 1 second out when compared with the remote time server.
If significant time drift is detected, you would be advised to configure your computer to automatically update the clock using and external time server.
You can correct the system clock on the PC using either the following methods;
Launch the control panel by (press , type "cmd" then click )
The command prompt window will now open;
Issue the command "Time", then at the prompt "Enter the new time:" supply the time currently show on the TIME.IS web page
Launch the control panel by (press , type "control panel" then click )
From the control panel click on the icon
To update the clock manually, select the "Date and Time" tab to display, then click on ;
Alternatively, you can click on the tab, then use the button to synchronise with an external time server using the button (example below);
Launch the systems settings window (by pressing ), then select "Time & language");
The heading will now change to "Time & language", click on the section "Date & time";
Ensure the "Set the time automatically" option is turned on;
Once this option has been enabled you will be able to synchronise the PC's clock with the external time server by clicking on the "Sync now" button;
After updating the system clock you can confirm the clock is now synchronised correctly by revisiting the TIME.IS web page and your computer clock should now be accurate to less than 1 second.
For hardware tokens (such as the SafeID range of TOTP tokens), the internal clock may only be corrected if the token is a programmable token, and can be corrected using the following procedure;
Introduction
As with pre-programmed hardware tokens, programmable tokens have an internal clock that is reliant on an internal quartz crystal to maintain time accuracy, but over time is still subject to a degree of time drift, but unlike pre-programmed hardware tokens it is possible to correct the internal clock on a programmable hardware token.
Preparation for correcting the clock on a programmable token
Before you are able to correct the clock on a programmable token you will need to make the following preparations;
Install and run the SafeID diamond programming app (available for Windows, Android and iOS versions),
If you are are using a windows based programming app you will need to ensure that the clock on your PC is set as accurately as possible.
Introduction
On windows based PC's, laptops and tablets the time is normally obtained from a quartz crystal based clock that is maintained by a lithium ion battery on the motherboard of your computer.
In general you can expect time drift of 2 or more seconds per day (compared to about 1 second every 3 days from a typical hardware token), but can be greatly improved if the PC is automatically synchronised with an external source (either an internet time server or the clock on the local domain controller).
Correcting the time on a windows computer
There are many possible solutions to identifying and correcting the clock on your local computer, but one of the simplest is by using the service provided by time.is
After opening a browser window to the TIME.IS web page you will be presented with a clear indication of any drift between you computers clock and the remote time server;
As can be seen in the above example the test computer was less that 1 second out when compared with the remote time server.
If significant time drift is detected, you would be advised to configure your computer to automatically update the clock using and external time server.
You can correct the system clock on the PC using either the following methods;
Launch the control panel by (press , type "cmd" then click )
The command prompt window will now open;
Issue the command "Time", then at the prompt "Enter the new time:" supply the time currently show on the TIME.IS web page
Launch the control panel by (press , type "control panel" then click )
From the control panel click on the icon
To update the clock manually, select the "Date and Time" tab to display, then click on ;
Alternatively, you can click on the tab, then use the button to synchronise with an external time server using the button (example below);
Launch the systems settings window (by pressing ), then select "Time & language");
The heading will now change to "Time & language", click on the section "Date & time";
Ensure the "Set the time automatically" option is turned on;
Once this option has been enabled you will be able to synchronise the PC's clock with the external time server by clicking on the "Sync now" button;
After updating the system clock you can confirm the clock is now synchronised correctly by revisiting the TIME.IS web page and your computer clock should now be accurate to less than 1 second.
You will need to obtain the the seed details that were originally used to program the token (a security provision requires that seed details are sent whenever the token clock is updated).
Synchronising the token's clock
Once the necessary preparations have been performed you should launch the SafeID Diamond Programming tool and select the option for token clock synchronisation.
If you are running the windows version of the app, then the option will be labelled "Sync Token Clock";
If you are running the Android or iOS versions of the app, then the option will be labelled "Synchronise Token Clock";
Once you have selected the synchronise token clock option you will need to manually enter the token details (seed/secret, time window settings etc.) prior to reburning your token.
Specific instructions for manual entry of the seed details and the steps necessary for burning the programmable tokens can be found in the following guide;
If you are not able to correct the clock on your device, then you need the server to account for your existing time drift, and this can often be achieve by performing a time synchronisation between the server and the token.
Time synchronisation for pre-programmed hardware tokens will occur either during the registration process of the token (for example when registering a token with azure), or using a separate process provided by the authentication server (where typically two consecutive OTP codes will be requested).
Recommendations
Given time drift occurs on hardware tokens regardless of use, we suggest registering you token with you authentication server within the first year of purchase. The majority of the hardware tokens we supply are programmed with 60 second time windows, and most authentication servers can deal with a few time windows of drift prior to registration. When registering older tokens with azure we suggest manual registration rather than bulk registration.
If your OTP codes are produced by an app running on windows, then ensure the clock on your computer is automatically synchronised with an external and reliable time server.