How OTP codes are generated
When a user is logging in to a protected application using the authentication method "One-Time Password" (or OTP), the user will be required to produce a numeric password (typically 6 or 8 digits long) in response to a prompt (the example below is an example of an OTP prompt produced by Office 365 during authentication);
In order to supply the required OTP code the user will need to generate the code using one of the follow solutions;
- The code is provided after using an authentication app (such as the MobileID app, SafeID Authenticator, SafePass Authenticator, Microsoft Authenticator or Google Authenticator)
- The code is displayed using an event based (HOTP) hardware token (e.g. the SafeID/eco token)
- The code is displayed using an time based (TOTP) hardware token (e.g. the SafeID/classic token)
- The code is provided after tapping a button on a FIDO key (such as SafeKey/Classic) that has been configured to produce OTP codes.
The available solutions all require a unique component (seed data/secret), and combine this data with a value that is generated either using an internal clock (for time based TOTP solutions), or an internal counter (for event based HOTP solutions). Since the seed/secret is also stored in the authentication server, then both sides will need to have a copy of the seed and time/counter parameters in order to be able to calculate the required OTP codes (when the user provides the OTP code the authentication server is able to confirm if the code was generated by someone in possession of the device that generated the code (hence this is an authentication solution of the type "something you have").
When time based authentication is used (TOTP), then the current time provided by the clock is used by the algorithm to generate the required OTP code (specifically it will calculate how many 30/60 second time windows have passed between a specific date in history and the reported time).
How OTP codes are used
When accessing an application that include OTP authentication as a authentication method option, you will be prompted to enter you code (typically by an on-screen prompt as per the following example;
In order to supply the requested code you will need to either be in possession of one of the hardware devices that produces the required code.
You will normally need to power on the token before the current OTP code is displayed, simply copy the code displayed on the hardware token and access will normally be granted (examples below);
...
| width | 100% |
|---|
| Column | ||
|---|---|---|
| ||
|
...
| width | 20% |
|---|
...
| width | 20% |
|---|
To obtain the required code from an authentication app you would first start the app on your mobile phone/pc app, and in cases where you have more than one token on the app you would first select the required token, and possibly request the OTP code to be generated (see examples below);
...
| width | 100% |
|---|
| Column | ||
|---|---|---|
| ||
|
| Column | ||
|---|---|---|
| ||
|
| Column | ||
|---|---|---|
| ||
|
When using an app or a hardware token if the code produced is time based then the generated OTP code can be affected by time drift.
What is Time Drift ?
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 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;
Expand title How to test SafeID tokens for time drift Panel borderColor grey bgColor #F8F8F8 borderStyle dashed Include Page How to test SafeID tokens for time drift How to test SafeID tokens for time drift
What do we do if there is time drift ?
There are two main solutions to resolve issues caused by time drift;
...
Expand title Checking and resolving time drift on a windows computer Panel borderColor grey bgColor #F8F8F8 borderStyle dashed Include Page Checking and resolving time drift on a windows computer Checking and resolving time drift on a windows computer
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;
...
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.