What Are OTP Codes? How One-Time Passwords Work

What does OTP stand for?

OTP stands for one-time password, also written one-time passcode or one-time PIN. It is a secret that a verifier accepts exactly once, usually within a short time window, to confirm that the person signing in controls a specific device, account, or channel. A static password can be replayed forever once it leaks; an OTP stops working after one successful use or after it expires, whichever comes first. Most OTPs people see are 6-digit numbers, which gives 1,000,000 possible values (10^6), and some systems use 8 digits or alphanumeric strings. OTPs appear in four common places: authenticator apps such as Google Authenticator, Microsoft Authenticator, and 1Password that compute codes locally; hardware tokens such as RSA SecurID and YubiKey OTP mode; codes sent over SMS or voice; and codes sent by email. Outside security, 'OTP' in text slang means 'one true pairing', which is a different meaning entirely and the reason some search results for 'what are otp' point to fan communities.

How do OTP codes work?

An OTP system has two parts: something that produces a code and a verifier that checks it. There are two families. Delivered codes are generated by the server with a cryptographically secure random generator, stored as a hashed record with an expiry, and sent to the user over SMS, voice, push, or email; the user types the code back and the server compares it against the stored record. Computed codes are generated independently on the user's device from a shared secret and a moving factor, so nothing travels over a network at sign-in; the server runs the same calculation and compares results. Computed codes follow two open standards from the IETF: HOTP in RFC 4226 and TOTP in RFC 6238. In both families the verifier, not the delivery channel, enforces the security properties: single use, expiry, attempt limits, and binding the code to one purpose (sign-in, password reset, payment approval). A code that arrives by email is only as safe as the server-side record that decides whether to accept it.

HOTP กับ TOTP ต่างกันอย่างไร

HOTP (HMAC-based One-Time Password, RFC 4226, published December 2005) computes Truncate(HMAC-SHA-1(K, C)), where K is a shared secret and C is an 8-byte counter that increases every time a code is generated. RFC 4226 requires at least 6 digits, requires a secret of at least 128 bits, and recommends 160 bits. Because the token's counter can run ahead of the server's when someone presses the button without logging in, the server checks a small look-ahead window of future counter values, and RFC 4226 section 7.3 recommends throttling or lockout to offset the extra guesses that window allows. TOTP (Time-based One-Time Password, RFC 6238, May 2011) replaces the counter with the number of time steps since the Unix epoch. The recommended step is 30 seconds. A verifier may accept a step or two either side to absorb clock drift (two backward steps equals 60 seconds of tolerance), but RFC 6238 says it MUST NOT accept the same OTP a second time after a successful validation. Use TOTP for authenticator apps; HOTP survives mainly in older hardware tokens.

# Python, using pyotp 2.9 (pip install pyotp)
import pyotp

secret = pyotp.random_base32()          # 160-bit secret, base32-encoded
totp = pyotp.TOTP(secret, interval=30)   # RFC 6238 defaults: SHA-1, 6 digits, 30 s
code = totp.now()

# valid_window=1 accepts the previous and next 30 s step (clock drift)
assert totp.verify(code, valid_window=1)
# Your application must still record that this code was used, so the
# same value is rejected if it is submitted again inside the window.

รหัส OTP ทางอีเมลปลอดภัยหรือไม่

Email OTP codes are secure enough for confirming an email address and for low-risk sign-in, but NIST no longer treats email as an authenticator. NIST Special Publication 800-63B-4, finalized in August 2025, states that email SHALL NOT be used for out-of-band authentication, and gives three reasons: a mailbox is often protected by only a password, messages can be intercepted in transit or at intermediate mail servers, and DNS spoofing can reroute mail. The same document carves out an exception: confirmation codes that validate an email address, and recovery codes, are not authentication processes and are not affected by the prohibition. In practice that splits email OTP use cases in two. Verifying a new signup's address, magic-link style passwordless login for a consumer app, and account recovery are common and reasonable. Approving a payout change, a wire transfer, or an admin action at a regulated assurance level should use a passkey, an authenticator app, or a hardware key instead. SMS and voice codes are also 'restricted' under 800-63B-4, which means they are allowed with additional risk handling and a migration plan.

What rules should an OTP verifier follow?

A verifier for delivered codes should follow the numeric requirements NIST SP 800-63B-4 sets for out-of-band secrets, even when the channel is email and the use is address confirmation. Generate the secret with an approved random bit generator, at least six decimal digits long. Treat the authentication as invalid unless it completes within 10 minutes, and accept each secret only once. If the secret is shorter than 64 bits, which every 6 or 8 digit code is, rate-limit consecutive failed attempts on the account, and do not reset the failed-attempt count when the user asks for a new code; resetting it is the classic way an attacker turns 'resend code' into unlimited guessing. Store a hash of the code rather than the code itself, tie it to a purpose and a session, and invalidate earlier codes when a new one is issued so only one is live. Return the same response whether or not the address has an account, so the endpoint cannot be used to enumerate users. Finally, log issuance, failures, and consumption without logging the code value.

How should an application deliver a sign-in code to the inbox?

Sending an OTP email reliably means getting it to the inbox within seconds, exactly once, from an authenticated domain. Send from a domain that publishes SPF and DKIM records and a DMARC policy, because Gmail and Yahoo have required SPF or DKIM for all senders and DMARC for bulk senders since February 2024, and an unauthenticated code email is likely to land in spam or be rejected. Keep the message transactional: a short subject such as 'Your sign-in code: 482913', the code in the first line of text, the expiry stated in minutes, a plain-text part alongside HTML, and no marketing content or tracking-heavy links. Put the code in the subject only if you accept that it will appear in lock-screen previews. Make the send idempotent: with SendHQ, POST /emails accepts an Idempotency-Key of up to 200 characters; repeating the identical request replays the stored response instead of sending a second email, and changing the payload under the same key returns HTTP 409. Use the code record's ID as the key so a network retry never produces two different codes in the user's inbox.

curl -X POST https://sendhq.cc/api/v1/emails \
  -H "Authorization: Bearer $SENDHQ_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: otp-7f3c2a91" \
  -d '{
    "from": "Acme <security@mail.acme.dev>",
    "to": ["user@example.com"],
    "subject": "Your Acme sign-in code",
    "text": "Your code is 482913. It expires in 10 minutes. If you did not request it, ignore this email.",
    "html": "<p>Your code is <strong>482913</strong>.</p><p>It expires in 10 minutes.</p>"
  }'

Why do OTP codes arrive late or not at all?

OTP codes that arrive late usually fail at one of four points, and each leaves evidence you can check. First, provider acceptance: an API response such as HTTP 201 means the provider accepted the message, not that the recipient's server did. In SendHQ the message moves through queued, sent (accepted by the provider), and then delivered, bounced, complained, or failed; only delivered means the receiving server took it. Second, receiver deferral: Gmail and Microsoft can temporarily defer mail from new or low-reputation domains with 4xx SMTP responses, and the sending server retries, which can push a code past its expiry. Third, filtering: a code that reaches the spam folder is technically delivered; authentication failures (SPF, DKIM, DMARC) and link-heavy templates are the usual causes. Fourth, suppression: an address that previously hard-bounced or complained is suppressed and will not be attempted again. Show the user the expiry, let them request a new code after 30 to 60 seconds, and look up the email event for that message before assuming the user mistyped.

Which OTP method should you choose?

The right OTP method depends on what you are protecting and who your users are. For confirming that a signup owns an email address, an emailed 6-digit code or link is the standard choice and is explicitly outside NIST's email prohibition. For routine sign-in to a consumer product, email codes or magic links trade some security for no app install; pair them with rate limits and device recognition. For workforce accounts, admin panels, and financial actions, use TOTP from an authenticator app at minimum and offer passkeys (FIDO2/WebAuthn), which resist phishing because the credential is bound to the site's domain; any typed code, including TOTP, can be phished by a real-time proxy page. SMS codes reach the widest audience but are exposed to SIM-swap attacks and carry per-message carrier costs, and NIST lists them as restricted. Many products end up with a ladder: email confirmation at signup, passkey or TOTP for sign-in, and email or recovery codes as the fallback.

คำถามที่ทีมมักถาม

แหล่งข้อมูลหลัก

• RFC 4226: HOTP: An HMAC-Based One-Time Password Algorithm — IETF / RFC Editor
• RFC 6238: TOTP: Time-Based One-Time Password Algorithm — IETF / RFC Editor
• NIST SP 800-63B-4: Authentication and Authenticator Management — NIST
• Sending email — SendHQ