What Is an OTP and How One-Time Passwords Keep Accounts Secure

What Is a One-Time Password?

A one-time password is a code that is valid for a single login or transaction and then becomes useless. That is the entire point. Your regular password is a long-lived secret: you reuse the same value every time you sign in, so anyone who learns it can use it again and again. An OTP flips that around. Each code works once, and often only for a short window, so capturing one gives an attacker little to nothing.

Because they expire so quickly, OTPs are almost always used as a second factor rather than a replacement for your password. You prove something you know (your password) and then something you have (a device that can produce the current code). That pairing is what people mean by two-factor authentication, which we will return to at the end.

There are three families of OTP you will run into in practice: counter-based codes (HOTP), time-based codes (TOTP), and codes that are simply delivered to you over a channel like SMS or email. The first two are generated locally from a shared secret; the third is generated on a server and sent to you.

The Shared Secret: The Idea Behind HOTP and TOTP

The locally generated OTP standards rest on one elegant idea. When you first set up an authenticator, the server and your device agree on a random shared secret—a string of bytes that only the two of them know. This is what the QR code encodes when you scan it during setup. After that, no network traffic is needed to produce codes: both sides can independently run the same algorithm over the same secret and arrive at the same answer.

The algorithm is built on an HMAC, a keyed hash function. An HMAC takes two inputs—a secret key and a message—and produces a fixed-length, unpredictable output. Crucially, you cannot work backward from the output to recover the secret, and changing the message even slightly produces a completely different result. That makes it perfect for OTPs: the secret stays hidden, but both parties can compute a code that an outsider cannot guess.

How TOTP Turns a Secret and the Clock Into Six Digits

Let us walk through exactly what your authenticator app does every 30 seconds. It is worth seeing the steps because they explain both why the code changes and why a captured code is worthless moments later.

1. 1Take the current time. Read the number of seconds since the Unix epoch (00:00:00 UTC on 1 January 1970). Suppose it is 1,700,000,000 seconds.
2. 2Divide into time steps. Divide that by the step size (30 seconds) and drop the remainder. Here 1,700,000,000 / 30 = 56,666,666 (rounded down). This whole number is the counter value that feeds the HMAC.
3. 3Compute the HMAC. Run HMAC-SHA-1 (the default in RFC 6238, though SHA-256 and SHA-512 are also allowed) over the shared secret and that counter. The result is a 20-byte string that looks completely random.
4. 4Truncate it. Use the last 4 bits of the HMAC to pick a starting position, read 4 bytes from there, mask off the top bit, and you have a number. This step is called dynamic truncation and turns 20 bytes into one large integer.
5. 5Reduce to six digits. Take that integer modulo 1,000,000 and pad with leading zeros if needed. The result—say 492817—is the code you type.

The server, knowing the same secret and reading its own clock, runs the identical five steps and compares its answer to what you entered. If they match, you are in. Because the counter is derived from the time, the moment the 30-second step rolls over, the counter changes, the HMAC changes, and a brand-new code appears. The old one will no longer verify.

Real implementations add a little tolerance: a server typically accepts the previous and next time step as well, so a code is not rejected just because your phone clock is a few seconds off or you typed slowly. This is why a TOTP code often still works for a little while after the visible timer ticks over.

Why One-Time Passwords Resist Replay

A replay attack is when someone captures valid authentication data and sends it again to impersonate you. Static passwords are vulnerable to this by design—the same string always works. OTPs close that door in two complementary ways:

• •Single use. With HOTP, once the server verifies a code it advances its counter, so that exact value will never be accepted again. With delivered codes, the server marks the code as consumed after one successful use.
• •Short lifetime. With TOTP, the code is only valid for its time step (plus a small grace window), so even an unused code is worthless within roughly a minute.

Together these properties mean that intercepting the network traffic of a successful login does not let an attacker log in later. There is, however, an important caveat: OTPs resist replay, not real-time relay. If a scammer can persuade you to read out a code while it is still valid—and use it immediately—the math does not protect you. That gap is exactly where phishing comes in.

SMS vs. Email vs. Authenticator Apps

All three deliver a code, but their security is very different. The weakness is rarely the code itself—it is the channel it travels through and how easy that channel is to compromise.

A few practical takeaways. SMS is the most convenient and the most exposed: in a SIM-swap attack, a criminal convinces a mobile carrier to move your number to their SIM card, after which your codes arrive on their phone. The older SS7 signaling protocol that carriers use to route messages has also been abused to intercept texts. Email codes are typically as strong—or as weak—as the email account they land in; if that mailbox is compromised, the second factor offers little.

Authenticator apps avoid the delivery channel entirely because the code is computed locally, which removes the interception risk and works even with no signal. They are not magic, though: a convincing fake login page can still capture a TOTP code and relay it to the real site within the valid window. The strongest widely available option steps beyond OTPs altogether—hardware security keys and passkeys (built on the FIDO2/WebAuthn standards) are bound to the real website's domain, so a phishing page on a look-alike domain simply cannot use them.

The Real Risks: Phishing and SIM-Swap

Because the cryptography is sound, attackers go after the human and the carrier instead of the algorithm. Two patterns dominate:

The unifying lesson: an OTP only proves possession of the device or channel at the moment of entry. If you can be tricked into using a live code on the attacker's behalf, the protection evaporates. Phishing-resistant methods like passkeys exist precisely to remove that human failure point.

Where OTP Fits Into 2FA and MFA

Authentication factors are usually grouped into three categories: something you know (a password or PIN), something you have (a phone, a hardware key, or an app that can produce a code), and something you are (a fingerprint or face scan). Multi-factor authentication (MFA) simply means requiring evidence from more than one category. Two-factor authentication (2FA) is the most common form of MFA—exactly two factors.

An OTP almost always serves as the "something you have" factor. You first enter your password (something you know), then your authenticator produces a TOTP code that proves you hold the device with the shared secret. The combination is far stronger than either alone: an attacker who steals your password through a data breach still cannot log in without the current code, and a code captured in transit is useless without the password.

It is worth noting that not every "second factor" carries equal weight. A second password is still only "something you know" and adds little. A code from an authenticator app is genuinely a different category. A hardware key adds possession plus phishing resistance. When you choose how to secure an account, think about which category you are adding and how easily that channel could be hijacked—not just whether a second step exists.

Frequently Asked Questions