0 / 5
Time-based mode (TOTP, Time-based OTP)
A fixed password, once leaked, can be reused by anyone. An OTP makes a new code at every login and uses it only once. The user's OTP device and the server each mix the same secret key with a value that changes every time, run the same calculation separately, and accept the login if the two results match. The modes differ in what that changing value is.
The changing value is the current time, cut into 30-second windows. The device and the server each know the time themselves, so this value is never exchanged. That is why it is a synchronous mode.
Example: a bank's OTP app shows a 6-digit code that changes every 30 seconds.
1 / 5
User: make the OTP
The time now, 09:00:12, falls in the 30-second window that starts at 09:00:00. The device feeds that window and secret key K into the hash function together, shortens the result to 6 digits and gets 482 913.
2 / 5
User → server: type the code
The user types 482 913 from the device into the login screen and sends it to the server. Neither key K nor the time is sent.
3 / 5
Server: run the same calculation
The server finds the current window (from 09:00:00) on its own clock and feeds it, with the same key K shared at registration, into the hash function. The result is 482 913.
4 / 5
Server: compare the two codes
The received code matches the code the server computed, so the login is accepted. The server records this code as used, so the same code cannot log in again.
5 / 5
30 seconds later: the code changes
At 09:00:30 the window changes, and the device and the server each compute the new code 705 261. So even an unused code soon stops working once 30 seconds pass. The server still accepts roughly one previous window, in case the window changed while the user was typing.
1 / 6
User: press the button
When the user presses the button, the device counter goes from 6 to 7. The device feeds counter 7 and secret key K into the hash function together and gets 159 044.
2 / 6
User → server: type the code
The user types 159 044 into the login screen and sends it. Neither the counter nor key K is sent.
3 / 6
Server: run the same calculation
The server keeps its own count for this user. Computing with the next counter, 7, and the same key K gives 159 044.
4 / 6
Server: compare the two codes
The two codes match, so the login is accepted. The server moves its counter only when a login succeeds. The next counter it expects is now 8.
5 / 6
User: when codes go unused
The user pressed the button twice without using those codes (counters 8 and 9). The device counter rises with every press, so this press makes it 10 and the device sends 640 372. The server is still expecting 8.
6 / 6
Server: compute ahead to catch up
The code computed with server counter 8 does not match. Instead of rejecting at once, the server tries the next counters, 9 and 10, up to a set limit. Counter 10 gives the same code, so the login is accepted and the server counter is brought in line with the device (next is 11). If no code within the limit matches, the login is rejected.
1 / 5
Server → user: show the challenge
When the user starts to log in, the server makes a new random number, 5831, and shows it on the login screen. This number is the challenge.
2 / 5
User: type the challenge and make a response
The user types 5831 from the screen into the OTP device. The device feeds the challenge and secret key K into the hash function together and makes the response 273 650.
3 / 5
User → server: type the response
The user types the response 273 650 into the login screen and sends it. Key K is not sent.
4 / 5
Server: run the same calculation
The server computes with the challenge it just made, 5831, and the same key K, and gets 273 650.
5 / 5
Server: compare the two codes
The two codes match, so the login is accepted. At the next login the server makes a new challenge, so this response cannot be used again.