OTP and push authentication

One-time passwords and push notifications are the most widely deployed second factors. They are a big improvement over passwords alone, and both can be phished in real time. This page explains how HOTP and TOTP codes are computed, where the seeds live and why that matters, how push approval works and fails (push bombing), what number matching fixes and what it does not, and the rules SP 800-63B-4 sets for OTP and out-of-band authenticators.

HOTP: counter-based codes (RFC 4226)

RFC 4226 (December 2005, Informational) defines HOTP:

HOTP(K, C) = Truncate(HMAC-SHA-1(K, C))

• K is the shared secret (the "seed"). The RFC requires it to be at least 128 bits (MUST) and recommends 160 bits.
• C is an 8-byte counter. The token and the server each keep one and increment it per code.
• Truncate is "dynamic truncation". Take the low 4 bits of the last HMAC byte as an offset, read 4 bytes from that offset, clear the top bit (leaving 31 bits), then reduce modulo 10^Digit. Implementations MUST produce at least 6 digits.

Worked example

Using the RFC's test secret, the ASCII string 12345678901234567890, with counter 0:

1. HMAC-SHA-1 output: cc93cf18508d94934c64b65d8ba7667fb7cde4b0
2. Last byte is b0. Its low 4 bits are 0, so the offset is 0.
3. Bytes 0 to 3: cc93cf18. Clearing the top bit gives 4c93cf18, which is 1284755224 in decimal.
4. 1284755224 mod 10⁶ = 755224, matching RFC 4226 Appendix D.

Because the counter only moves when a code is generated, the token and server can drift apart (for example, if a user presses the button without logging in). RFC 4226 handles this with a look-ahead window on the server. It recommends throttling and says lockout or delay schemes MUST apply across login sessions, so parallel guessing does not bypass them.

TOTP: time-based codes (RFC 6238)

RFC 6238 (May 2011, Informational) replaces the counter with time:

T    = floor((current Unix time - T0) / X)
TOTP = HOTP(K, T)

• X is the time step. The default is 30 seconds, and the RFC recommends 30 seconds as the balance between security and usability.
• T0 defaults to 0 (the Unix epoch).
• Implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 instead of HMAC-SHA-1.
• To allow for network delay, the RFC recommends accepting codes from at most one previous time step.
• The verifier MUST NOT accept the same code a second time after a successful validation.

Example from RFC 6238 Appendix B: at Unix time 59 with X = 30, T = 1, and the 8-digit SHA-1 TOTP is 94287082. That is the same value HOTP gives for counter 1, because TOTP is HOTP with T as the counter.

Where the seeds live, and why it matters

OTP is symmetric cryptography: the verifier holds the same seed as the authenticator. That has consequences:

• A seed database is a master key. Anyone who copies the verifier's seeds can generate valid codes for every user. SP 800-63B-4 says the verifier's symmetric keys SHALL be "strongly protected against unauthorized disclosure" by access controls limited to the components that need them.
• Software seeds can be copied. An authenticator app's seed lives on a general-purpose phone. SP 800-63B-4 explicitly allows exporting the seed to a sync fabric that meets Appendix B.2 when changing devices (MAY). That is convenient, and it also means the seed exists in more places.
• Provisioning exposes the seed. The QR code shown at enrollment contains the seed. A screenshot, a support ticket attachment or a shoulder-surfer has the whole authenticator. (Common practice: show the QR code once, only after strong authentication, and never store or email it.)
• Codes are short. Six digits is a million possibilities, so rate limiting is part of the security, not an optional extra.

Public-key authenticators avoid the seed-database, provisioning and short-code problems, because the private key is generated on the authenticator and the verifier stores only a public key. (Synced passkeys are still copied between devices, under the Appendix B.2 rules.) That is one reason SP 800-63B-4 requires public-key cryptography at AAL3.

SP 800-63B-4 rules for OTP authenticators

SP 800-63B-4 also says plainly: "OTP authentication is not phishing-resistant", and FIPS 140 validation of OTP authenticators and verifiers is not required.

Push notifications and push bombing

A push authenticator is, in NIST's terms, an out-of-band authenticator: an app on a device that the verifier reaches over a separate, secondary channel. CISA's number-matching fact sheet describes the basic flow. The user enters a username and password, the identity platform signals the app, and the user opens and accepts the prompt.

Push bombing (also called MFA fatigue) exploits that last step. An attacker who already has the password triggers prompt after prompt until the user approves "by accident or out of annoyance", in CISA's words, or assumes one of them is legitimate.

SP 800-63B-4 responds directly. It describes a method in which the verifier asks the user to compare secrets shown on the primary and secondary channels and approve on the secondary one. Of that method it says it "is no longer considered acceptable", citing "authentication fatigue" attacks. The guideline instead requires that the secret actually be transferred between the devices. It also says "presenting the claimant with a list of secrets to compare is not sufficient", because a user can guess from a short list.

Number matching

CISA describes number matching as "a setting that forces the user to enter numbers from the identity platform into their app to approve the authentication request". That is the "primary to secondary channel" transfer pattern SP 800-63B-4 accepts (its Figure 2).

CISA lists two ways number matching mitigates fatigue: users cannot approve without seeing the login screen, and generating many prompts is pointless because each needs its own number. CISA calls it "one of the best interim" mitigations for organizations that cannot yet deploy phishing-resistant MFA. In CISA's ranking, push with number matching sits in the same tier as OTP apps: resistant to push bombing, still vulnerable to phishing. See MFA strength.

CISA also recommends training users to report unexpected prompts and investigating denied pushes. A denied prompt usually means the password has already been compromised, because the push only fires after the first factor succeeds.

SP 800-63B-4 rules for out-of-band authenticators

"Out-of-band authentication is not phishing-resistant" (SP 800-63B-4 section 3.1.3).

What to do

• Plan to move administrators and high-value users to phishing-resistant authenticators. OTP and push are interim measures for them. See phishing-resistant MFA.
• Turn off approve-only push. Require number entry (a transferred secret), not selection from a list.
• Rate-limit push prompts per account, and alert on bursts and on denied prompts.
• Rate-limit OTP verification across sessions, and reject reuse of a code that has already succeeded.
• Accept TOTP codes from at most one previous time step.
• Encrypt OTP seeds at rest, restrict which components can read them, and treat a seed-store breach as a full re-enrollment event.
• Protect enrollment and recovery as strongly as sign-in. Re-registering a phone is binding a new authenticator. See account recovery.

Sources

1. RFC 4226: HOTP: An HMAC-Based One-Time Password Algorithm, IETF. IETF Trust Legal Provisions (brief quotations with attribution).
2. RFC 6238: TOTP: Time-Based One-Time Password Algorithm, IETF. IETF Trust Legal Provisions (brief quotations with attribution).
3. NIST SP 800-63B-4: Authentication and Authenticator Management, NIST. Public domain (U.S. government work).
4. CISA fact sheet: Implementing Number Matching in MFA Applications (October 2022), CISA. Public domain (U.S. government work).
5. CISA fact sheet: Implementing Phishing-Resistant MFA (October 2022), CISA. Public domain (U.S. government work).