OTP stands for one-time password (sometimes one-time passcode). It is a short code, usually four to eight digits, that is valid for a single login or a single transaction and then expires. Because each code works only once and only for a short window, a code that leaks after it is used is worthless to an attacker. That throwaway quality is the whole reason OTPs exist.
You have almost certainly typed one: the six digits a bank texts you before a transfer, the code an authenticator app shows when you sign in, the number a website emails you to confirm it is really you. All of those are OTPs, differing mainly in how the code is generated and how it reaches you.
How does an OTP work?
The service and the user need a way to agree on what the valid code is right now, without sending the password itself around in a guessable way. There are two standard methods, and the difference is what makes the code change.
- HOTP (HMAC-based one-time password). The code is derived from a shared secret and a counter. Each time a code is used, the counter advances, so the next code is different. The code stays valid until it is used, which means it does not expire on a clock.
- TOTP (time-based one-time password). The code is derived from a shared secret and the current time, rounded to a window (commonly 30 seconds). The code changes on its own as time passes, whether or not anyone used it. This is what authenticator apps generate.
TOTP is the more common of the two today because the automatic expiry limits how long a stolen code is useful. HOTP still appears in hardware tokens and in flows where a time-synced clock is awkward to guarantee.
How is an OTP delivered?
The generation method and the delivery channel are separate choices. A code can be computed on the user's own device, or generated on the server and sent to them.
- SMS. The server generates a code and texts it to the user's phone number. Universal reach, no app required. It is also the most interceptable channel, via SIM-swap or network attacks.
- Email. The code arrives in the user's inbox. Convenient and app-free, but only as secure as the email account itself.
- Voice call. An automated call reads the code aloud, which helps users who cannot receive SMS or who need an accessible option.
- Authenticator app. The code is computed locally with TOTP. Nothing is sent over the network, so there is nothing in transit to intercept.
Each channel trades reach against how hard it is to attack. SMS and email reach almost everyone; app-based codes are harder to steal but require the user to have set up an app in advance.
Where are OTPs used?
The most familiar use is as the second factor in two-factor authentication, where the OTP proves possession of a phone or device on top of a password. But OTPs show up well beyond login.
- Login verification: confirming a sign-in, especially from a new device or location.
- Transaction confirmation: approving a payment, a transfer, or a change to payout details.
- Account recovery: confirming control of a phone number or email before resetting a password.
- Step-up checks: asking for a fresh code before a sensitive action, even mid-session.
If you are weighing whether an OTP makes a login genuinely "two-factor," it depends on the rest of the flow. The distinction is covered in two-factor authentication vs. two-step verification.
Security considerations and best practices
OTPs are simple, which is exactly why the details matter. A few habits keep them effective.
- Short expiry. Time-box codes tightly. A few minutes for SMS and email, the standard 30-second window for TOTP. The shorter the window, the smaller the chance of a code being reused.
- Rate limiting. Cap both how many codes a user can request and how many guesses they can make. A six-digit code has a million possibilities, which an unthrottled attacker can brute-force; a few attempts per code closes that door.
- Single use, enforced server-side. Invalidate a code the moment it is accepted, and on too many failures. Do not rely on the client to stop reuse.
- Never log the code. Keep OTPs out of application logs, analytics, and error reports. A code sitting in a log file is a code an insider or a log breach can read.
- Bind the code to context. Tie a code to the specific user and action it was issued for, so a code meant for one purpose cannot be replayed for another.
A short aside on phishing: a user can be tricked into reading an SMS or app code to an attacker on a fake site, so OTPs are not phishing-proof the way hardware keys are. They still block the far more common attack, which is someone logging in with only a stolen password.
Sending and verifying OTPs
You can run an OTP flow yourself: generate a code, store it with an expiry, send it, and check the user's input against it within the window. If you want the delivery and verification handled for you (including the rate limiting and expiry), Bird's Verifications product sends and validates codes over SMS, voice, and email. If you only need the transport and want to own the verification logic, the SMS product covers code delivery to phones.
FAQ
What is the difference between HOTP and TOTP?
HOTP derives the code from a counter that advances on each use, so the code changes only when used. TOTP derives it from the current time, so it changes on a fixed schedule (usually every 30 seconds) on its own. TOTP is more common because the automatic expiry limits a stolen code's usefulness.
Are SMS OTPs secure?
They are secure enough for most accounts and block the bulk of password-only attacks, but SMS can be intercepted through SIM-swap fraud or network attacks. For high-value accounts, prefer an authenticator app or a hardware key.
How long should an OTP stay valid?
Long enough for the user to read and type it, and no longer. A few minutes for SMS or email, and the standard 30-second window for TOTP. Shorter windows reduce the chance a leaked code is still usable.
Can the same OTP be used twice?
It should not be. A correctly implemented system invalidates a code the moment it is accepted, and also after too many failed attempts. Enforce single use on the server, never on the client.
One-time passwords are a small idea that carries a lot of weight in account security. To see how they fit into a full login defense, read what two-factor authentication is, or look at how Bird generates, delivers, and checks codes in the Verifications product.