Provision and protect the shared secret
06The prover and verifier need matching secret material before they can compute the same codes. Time is public; the secret is what makes the computation specific to the prover. RFC 6238 defines the algorithm, not a QR enrollment format.
An unauthorized process must not gain access to secret material. The secure-area key-store requirement and restricted access protect more than the displayed decimal code.
Source for this drawing: RFC 6238 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Provisioning
- Setting up matching secret material and system parameters before generation and verification.
- Shared secret
- Key material held by both endpoints, unlike the public clock or the transmitted short code.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
There MUST be a unique secret for each prover. Keys SHOULD be randomly generated or derived using key-derivation algorithms and SHOULD be protected against unauthorized access and use.
- There MUST be a unique secret for each prover. Keys SHOULD be randomly generated or derived using key-derivation algorithms and SHOULD be protected against unauthorized access and use.
- Provision X and T0 in advance. The provisioning flow is outside this RFC; it points to RFC 6030 for provisioning containers. Do not present an otpauth URI or QR code as a format specified by RFC 6238.
- The prover and verifier MUST share the same secret or know a transformation that yields a shared secret. The verifier recomputes the OTP; it does not recover the secret from the short code.
- All communications SHOULD take place over a secure channel. The key store MUST be in a secure area; the RFC recommends encrypted, tightly limited key access and brief exposure when validating.
- MAY use tamper-resistant storage is optional, not an excuse to skip protection. A valid code does not make an untrusted destination safe. Use only public fixtures in demonstrations; never paste a real enrollment key into a guide.
The secret icons represent private, provisioned material, not a key sent with each login. No enrollment service, user account or real key is created. The failed-access stop bar illustrates an access-control boundary, not automatic protection provided by HMAC. Protecting keys, limiting guesses, bounding windows and rejecting replay are complementary controls.
Read the RFC section ↗