A Developer’s Guide to One-Time Passwords (OTPs)
One time passwords (OTPs), such as those created by authenticator apps and Yubikeys, are a common way to add additional security to application authentication.
Notion is taking the knowledge-management market by storm, but it’s also known to have a notoriously annoying login process. You could be using Notion for years and still be asked to depart Notion, open your email, and find a one-time password, or OTP.
Users often feel annoyed and alienated — the friction creates a sour user experience.
That said, it’s easy to see why Notion prioritizes OTPs: compared to static, single-use passwords, OTPs are more secure and easier to set up.
Still, there’s a balance to strike, and security-conscious developers would be smart to study OTPs and implement them carefully. In this guide, we’ll dive into how OTPs work and explain the advantages and disadvantages of using them so that you know what you’re getting into when it’s time to implement OTPs for your app.
What is a one-time password?An OTP is a password that is valid for only one login session, i.e., it’s valid only one time. You generate it once, you use it once, and you trash it.
OTPS are better than static password generation
Using a single, static password is common. The average business user has 191 passwords, and juggling them is not only a pain but also a security hazard. That means users might forget passwords and write them down (making them stealable) or reuse passwords across services (making all their accounts vulnerable to one data breach).
As much as security-minded folks might remind users to use unique passwords, the reality is that they’ll likely continue sharing and reusing passwords.
But using a single, static password makes you very vulnerable to hacking. If someone breaks into your computer or network to take your password, or uses a phishing technique to pilfer your password from you directly, you’re hosed. And, even more likely, if someone breaks into a service that you use and accesses the database with your password in it, you’re vulnerable and may not even know it. Just check out haveibeenpwned to see how many of your own passwords are out in the wild, available to hackers today.
OTPs offer one solution to this problem.
OTPs complement MFA
Many OTP implementations combine the security of a temporary password with the security of multifactor authentication (MFA). MFA is when an authentication service requires users to submit at least two forms of authentication. The simplest version of this is password plus magic link; a more complex version might involve password, security question, security key, biometrics, and more.
OTPs can either be an addition to your current authentication process, or OTPs themselves can require further authentication factors. Some OTPs, for instance, will require that users have access to a knowledge factor and a possession factor, such as a PIN and a security key, respectively.
How do OTPs work?
OTPs come in three different forms, and each form works differently: time-synchronized OTPs, lockstep synchronized OTPs, or transmission-based OTPs. OTPs are delivered by device or app.
(Source)
Though developers typically use a device, like a YubiKey, or software, like Authy, you can also program your own OTP implementation. If you’re interested in experimenting with coding your own OTPs, there’s a pretty good tutorial on freeCodeCamp that will get you started, and a tutorial via Technical Suneja for implementing a PHP login with OTP authentication over email.
Time-synchronized OTPs generate based on current time
A time-synchronized OTP is one that generates new, temporary passwords based on the current time. Time-synchronized OTPs typically deliver passwords via hardware device or via a two-factor authenticator app (Authy, Google Authenticator, Microsoft Authenticator).
Your OTP device has a clock that syncs with the clock on the authentication server. Both then generate an OTP based on the current time. From there, the password is hashed to generate a unique, numerical code that functions as the OTP. OTP vendors usually use a Unix timestamp to coordinate a universal time and avoid any problems with time zones.
The most popular standard for time-synchronized OTPs is time-based OTPs or TOTPs.
Lockstep-synchronized generate based on prior OTP
A lockstep synchronized OTP is one that generates new, temporary passwords based on a previous OTP.
Your OTP device uses a seed code and a hash chain to generate OTPs first from the seed code and then from every subsequently used OTP. These are commonly known as HOTP, or HMAC-based One-time Password. HMAC is a standard that anyone can use.
These passwords are hard, if not impossible, to reverse-engineer, making them inaccessible to hackers. They have to be random, or else a hacker could observe the OTP tool generating passwords over time, find a pattern, and predict the next one.
One example of a lockstep synchronized OTP is one that uses an algorithm and a one-way function. This function starts with a seed value and applies a hash function repeatedly to generate values that only the server and login system will know. Without knowing the seed value, hackers can’t reverse engineer the function and predict the next OTP. The S/Key OTP system, for instance, uses this hashing function.
Transmission-based OTP generate on activation
A transmission-based OTP is one that generates a new, temporary password and sends it to the end user via SMS, email, or push notification.
This is the most common, most well-known form of OTP implementation. You’ve probably encountered this hundreds of times as a user, and it’s one of the easiest forms of OTP to implement as a developer.
Instead of two separate devices creating and verifying their separate passwords, transmission-based OTPs are randomly generated passwords made by the authentication server and sent, usually via SMS, to the end user.
OTP-generation depends on triggers and tokens
OTPs are generated for different reasons and by different triggers.
OTP Triggers
Depending on the OTP implementation, users might encounter OTPs every time they log in or only occasionally.
In the former case, an app will use OTPs as part of their MFA scheme and require users to authenticate via OTP every time they log in (think Notion, which we cited above). In the latter case, an app will use OTPs as a way for users to log in if they forget their normal passwords. Users can typically log back in via OTP and then reset their normal passwords.
There are two different triggers for OTPs—time-based and event-based:
- Time-based triggers generate OTPs that are valid for only a certain length of time, often as little as 30 or 60 seconds.
- Event-based OTP triggers generate OTPs after an event, typically the press of a button, and remain valid until a user uses them.
Both types of triggers can happen every time you authenticate or only when you’ve forgotten your normal password.
Hard vs. Soft Tokens
Different OTP tools send OTPs through either hard or soft tokens.
Hard tokens are physical devices that provide OTPs. These include:
- Connected tokens, such as smart cards and USB-drive devices (think YubiKey)
- Disconnected tokens, such as key fobs
- Contactless tokens, such as Bluetooth devices
(Source)
Soft tokens are software that exists on a device. This is usually a dedicated mobile app, such as Authy or Google Authenticator, that sends “out of band messaging” via SMS messages, email, or push notifications.
Both hard and soft tokens rely on different authentication standards, some of which are proprietary and some of which are open. Some of the open standards include:
TOTP is an interesting case. RSA Security invented and sold TOTP-based solutions, but the patent eventually expired. OAUTH has since standardized TOTP, and many more authentication vendors than RSA now use it.
Benefits of one-time passwords
The benefits of OTPs are clear, which is part of why so many apps and services have implemented them.
They cut down on bad security behavior
As we covered already, end users and business users alike are frustratingly likely to reuse password, use weak passwords, and share credentials. With OTPs, you can either eliminate this behavior or complement it with a more secure, temporary password.
They prevent replay attacks
Replay attacks are a kind of network attack, wherein a hacker hijacks valid data transmission and repeats or delays it. During a successful replay attack, a hacker could intercept and then use an end-user’s password. With OTPs, however, it (usually) doesn’t matter if they’re stolen. They’re valid only temporarily, meaning that even if a hacker steals them, they won’t be able to use the OTP past the point of expiration.
They free up IT admins
IT admins, or developers put in charge of administration, sink a lot of time into password management. They’ll need to design decomposition rules, reinforce password security best practices, and come up with policies and timelines for deprecating passwords. It can be burdensome. With OTPs, all that headache is eliminated and effectively automated.
Downsides to OTPs
OTPs are not without their weaknesses––and, ironically, security is among them.
Lingering insecurities
Adept hackers can intercept or reroute OTPs. If an end-user hasn’t used the OTP yet, that can leave them vulnerable.
SMS OTPs in particular have come under fire. A paper for the International Conference on Detection of Intrusions and Malware & Vulnerability Assessment, for instance, argues that SMS-based OTPs are particularly insecure. According to the paper, SMS-based OTPs were originally introduced to protect against phishing attacks, but today, the architecture of modern cellular networks and mobile handsets means that SMS OTP systems “cannot be considered secure anymore.”
Some OTPs use encryption, often via an A5/x standard, but some hacking groups have discovered this standard can be fairly easily decrypted. That means that hackers could intercept an encrypted OTP, decrypt it, and access an end-user’s accounts.
Some developers have also found flaws in the SS7 routing protocol, meaning hackers can redirect OTP text messages. In 2017, for instance, German company O2 reported that hackers used its two-factor verification system to reroute OTPs. In this case, the protocol that connected German banks to the back ends of certain telecom networks was exploitable.
Security flaws such as these, especially those involving SMS, have led NIST (the National Institute of Standards and Technology) to deprecate the suggestion to use SMS-based OTPs.
Annoying user experience
As we covered in the introduction regarding Notion, many end users consider OTPs to be an annoying experience. Users who use password managers, in particular, may be frustrated that even though they already use secure passwords, they’re forced to use OTPs too. Developers have to balance increased friction and decreased security to create an experience that is both smooth and safe.
OTP friction can be compounded by poor OTP implementations that cause the delivery of OTPs to take a long time. You don’t want your users repeatedly hitting the refresh button on their email inboxes, waiting for an OTP email to arrive before they can log in. One way to reduce friction while benefiting from OTP security is to use a modern, dedicated security key.
Walk the line between security and convenience
Security always involves a compromise between annoyance and safety. Typically, more security involves more annoyance, and less annoyance involves less security. You want your end users to be safe, of course, but you also want them to be able to access your app with minimal frustration.
OTPs, when implemented well, help you walk that line. OTPs are more secure than static passwords (especially if you don’t send them through SMS), and it’s easy for end users to use them.