One Time Password (OTP)
Overview
This page contains recommendations for using One-Time Passwords (OTPs).
General
If you need to generate OTP on the server side and send it to a user via one of the communication channels (email, SMS, push, etc.), use a cryptographically strong random generator, see the Cryptography: Random Generators page.
If you need to generate OTP on the client side, use time-based one-time passwords (TOTPs), see the Time-Based One-Time Password Algorithm (TOTP) section.
Use an OTP once. Delete an OTP or transfer it to a final status that prohibits reusing.
Link an OTP to an individual user in a database.
If an application generates OTPs on the server side, limit the number of generation attempts in a certain period, see the Vulnerability Mitigation: Brute-force page.
Limit the number of OTP verification attempts for a certain period, see the Vulnerability Mitigation: Brute-force page.
Use OTPs of length 6+ symbols.
Set a short expiration time for an OTP (~ 5 hours).
Make sure the generation of new OTP invalidates previous ones.
Store OTPs in a separate database, access to which must be limited. Do not store OTPs next to other application data.
Do not send OTPs in an URL (in the path, query, or fragment).
Comply with requirements from the Sensitive Data Management page.
Comply with requirements from the Logging and Monitoring page.
Comply with requirements from the Error and Exception Handling page.
Store OTPs in encrypted form and decrypt only certain records when accessed.
Set a short expiration time for an OTP (~ 1 minute).
Include information about the confirmed action in the text templates of messages with OTPs. For example, if a user uses OTP to cancel a subscription, the message can be like this:
Time-Based One-Time Password Algorithm (TOTP)
Time-Based One-Time Password Algorithm (TOTP) is described in RFC6238.
TOTP is an algorithm that generates OTPs based on a shared secret and the current time. To generate OTPs, a user needs an authenticator application (also known as a prover). In other words, a user and a backend generate an OTP separately, but thanks to the shared secret and the current time, a backend can reproduce the same OTP in a certain period.
Generate a shared secret using a cryptographically strong random generator, see the Cryptography: Random Generators page.
Use a unique shared secret for each authenticator application (prover). For example, if TOTP is used to generate OTPs for a second-factor authentication, generate a unique shared secret for each TOTP registration.
Use shared secrets of length 16+ bytes.
Set a short expiration time for an OTP (~ 1 minute).
Clarification
Since new OTPs are generated in steps of n seconds (generally n is 30 seconds), multiple OTPs are valid at the same time. Each OTP in the allowable window is a valid OTP. If OTPs are valid for an hour, many OTPs are valid at the same time within this window. Therefore, it is much easier to guess a valid OTP, because there is more than one valid OTP in the possible set of OTPs.
For example, if OTPs are generated in steps of 30 seconds and a common validity range here is about 5 minutes in either direction from the time as set on a server, the allowable window is:
In such case, the number of valid codes at the same time is:
The OTP generation step and OTP expiration time must be equal (~ 1 minute). In other words, the generation of a new OTP must invalidate previous ones.
Last updated