A One Time Password or OTP is a security code designed to be used for a single login attempt, to minimize the risk of fraudulent login attempts and maintain high security. It’s a string of characters or numbers automatically generated and sent to the user’s phone via SMS, Voice, or Push message.
The OTP has become the standard method worldwide of enabling a login when special circumstances apply, such as validating a new account or confirming a transaction is legitimate. Also known as a one-time PIN, one-time authorization code (OTAC), or dynamic password, it’s most commonly a six-digit number sent to a customer’s phone via SMS text message, then entered by the customer into the site or app they’re attempting to log into.
Millions of OTPs are sent every day around the world—and a large proportion of those are sent via SMS. With good reason: people keep their cellphones close at hand 24 hours a day, and—as a valued personal possession—a phone is generally used by a single individual, making it an excellent channel to confirm someone is who they say they are.
The general idea of a One Time Password is to add a second layer of authentication in order to stay ahead of cybercrime and protect your organization against the catastrophic effects of fraud on your business.
The risk of fraud is drastically reduced if the user doesn’t only have to fill in his username and password (something he knows) but also needs something he “has” to complete the login. This ‘something’ can be the user’s phone. OTP’s come in all shapes and sizes, but always add an extra layer of authentication.
OTPs are used when a transaction needs additional security or an alternative method of proving a customer’s identity. When a recognized situation arises—a customer needing a password reminder, a bank confirming an out-of-pattern transaction, and many other cases (see below)—a request for an OTP is made, either by the customer him/herself or the institution they’re dealing with.
The OTP is generated automatically as a semi-random number or string of characters. There is no way to predict what the OTP will be ahead of time; also, OTPs are usually time-limited, usable only for a few minutes.
There are several ways to send an OTP. Some give the option of receiving OTPs by email, although this tends to be less secure. Other providers even enable OTPs as voicemails, stating the PIN aloud when the customer checks the mailbox. But by far the most common way to send OTPs is by mobile messaging, typically an SMS text to the customer’s cellphone.
Originally, most OTP’s were sent as SMS messages. Once the user has begun his login attempt, filling in his username and the correct password, an SMS OTP is sent to the mobile number connected to his account. The user then enters this code shown on this phone in the login screen, completing the authentication process.
An alternative to a One Time Password via SMS is Voice. With Voice, the spoken password is received as a phone call on the user's mobile. The password will not be stored on the user's phone and Voice allows you to reach users with limited sight. You can also implement Voice as a backup in case your SMS is not delivered.
The Two-factor Authentication process using One Time Passwords via Push is similar to SMS OTP. In the login procedure to your online environment, an automated generated code is sent as a push notification to your App on the user’s phone. Then the user has to copy that code to the login screen to verify his identity. This does mean you’ll need a dedicated app.
While they seem simple, a surprising depth of technology goes into sending an OTP to a customer’s cellphone. While OTPs sent by SMS aren’t encrypted in transit, they use other methods to ensure only the authorized person can use them.
Common models for login security, like Two Factor Authentication (TFA) and Strong Customer Authentication (SCA), take the approach that multiple factors, each insecure by themselves, can combine to enable much higher security. These practices aren’t unique to OTP—they’re standard methods in use across the entire security industry.
At its most basic, these models combine what someone has (such as a personal cellphone) with what someone knows (such as their own email address) and/or what someone is, including challenge questions like a parent’s place of birth. Taken together, the combination of a personal device, a semi-random access code (the OTP) and a short “window” to enter it satisfies many use cases for secure login.
The PIN that arrives on a customer’s phone isn’t from a list and is not stored for any length of time. It’s generated in the same way as the cryptographic keys that protect bank accounts: a “one-way hash function” involving the generation and multiplication of large prime numbers. This method has a useful quality: such codes are relatively easy to generate but virtually impossible to “backtrack”, or discover how the code was generated by looking at the result.
This means the OTP the customer sees is genuinely unpredictable: even if a bad actor had lists of millions of OTPs, there’s no “pattern” that would let him gain knowledge of what OTP will be generated for a given customer in future.
Adding to the security stance, the shelf life of an OTP is very short: rarely longer than half an hour, and sometimes just a few minutes. In other words, the situation they answer is very time-limited. It’s the customer sitting at his desk trying to log into his account, or the customer standing at the sales counter confirming her payment is legitimate.
This is another plus for using SMS over other channels. While SMS wasn’t originally designed as an instant messaging technology, in practice most global mobile networks will convey a text message from origin to recipient in just a few seconds.
Furthermore, OTPs can only be used on a single occasion. Once expired, they’re useless, and the same OTP cannot be used to log in more than once even within its usable time window: this is known as “non-replay”. Even if OTPs could be easily hacked, this time factor makes hacking of OTPs a near-valueless exercise.
It’s not necessary to be a mobile network to make use of OTPs. Providers like CM.com offer OTPs as a service, with a secure platform for receiving or initiating OTP requests, sending the OTP as a text or other channel, and verifying the OTP was entered correctly, so the transaction can go ahead.
The infrastructure for making use of one-time passwords integrates with your website or application using an API. This is how a site “knows” whether an entered OTP is correct or not, with safeguards like checking it’s within the time window. When you receive an OTP to log into your bank account or make a transaction, the organization isn’t using software it developed inhouse—it’s using an OTP service provider like CM.com.
Very few people need to be taught how to use an OTP; one-time codes are common practice for everything from activating a bank card to resetting a password. And, of course, in a world with nearly twice as many mobile devices as people, nearly everyone needing an OTP has access to a cellphone.
One Time Passwords sent via SMS aren’t foolproof—OTPs can sometimes be lost in transit—but the vast majority are delivered as expected, in minutes or less. And even in the rare event of a failed delivery, the customer can simply ask for another OTP.
What’s more, the uses of OTPs are manifold. While most common in the financial sector, they’re increasingly common on websites and applications of all types, wherever a user’s identity or access rights need to be verified. The general principle of OTPs is that they add an additional layer of security to an already secure process—the “multiple factors” of TFA and SCA.
Adding such multi-factor authentication to an individual’s account means that even if email address and password are compromised (i.e. a bad actor learns them) other crimes would need to be committed before any successful login attempt could be made—such as stealing the customer’s cellphone.
Millions of plastic cards are issued every year. Each card needs “activation”—confirming that the new card is in the possession of its rightful owner. This activation is commonly carried out with an OTP code, often sent as an SMS to the customer’s phone.
Fraud recognition software relies on patterns: people tend to act in similar ways again and again, such as spending a predictable amount on the same day each week in a grocery store.
If a transaction has unusual characteristics—such as being in a different country, for an unusual amount, or simply at a strange time of day—the transaction will be flagged as “out of pattern”. An OTP can often resolve such situations, by confirming the individual making that transaction is the authorized one.
When a transaction’s sticker price is above a certain level, an OTP can be used to confirm everything’s going as intended—in principle no different to entering your PIN when your contactless payment is above a set figure (such as £100 in the UK). Many users appreciate the extra assurance an OTP gives in such situations.
A very common use case for OTPs is, of course, lost passwords. On the web today, password reminders are increasingly rare—since email isn’t fully secure. Instead, users are usually asked to reset the password. The One Time Password, generated and sent at the user’s request, enables the user to set up a fresh password for whatever site or app they’re visiting.
With government departments often far from integrated—giving a citizen separate accounts for personal taxes, business taxes, healthcare records, motoring licenses, passport applications, and so on—OTPs can be a unifying factor, helping citizens access different government services without too much pain.
The average consumer today owns more than one device, and many of those devices are connected to mobile networks—which creates a problem for site and app operators, since many security processes check the credentials of the device (known or not) as well as the user.
Typical scenarios are streaming services where many devices share a login, and devices on public WiFi. An OTP confirms a new device is legitimate—or not.
Not all use cases for SMS OTPs revolve around the web and finance. “Onboarding”—introducing a new user to a service of any kind, from security badges for buildings to ticket holders at festivals—increasingly use OTPs to confirm someone’s identity.
Some datasets contain sensitive information—such as someone’s health records—but need to be accessible to a range of users, such as their doctors. OTPs satisfy several conditions here: not only can they grant access to the right people, but also record who accessed that data and how often.
Select a region to show relevant information. This may change the language.
Is this region a better fit for you?