A clock turns a secret into a short code
An authenticator code is usually a time-based one-time password, or TOTP. During setup, the app receives a secret key—often by scanning a QR code—and the service saves a matching secret. The key is the lasting ingredient; the six-digit number is only a temporary result.
The app combines that secret with the current time, divided into fixed intervals, commonly about 30 seconds. It runs the combination through a cryptographic function and reduces the result to a short decimal number. The service performs the same calculation independently. Because both sides have the same key and time interval, they arrive at the same digits without exchanging a fresh code.
Why a tiny timing mismatch can still work
Phones and servers do not keep perfectly identical clocks. To allow for small differences, a service may accept codes from the interval just before or after its current one. That makes login practical, but it also means a displayed code may remain acceptable briefly after the next code appears.
The code is not a replacement for the secret key. Someone who steals the key can generate future codes, while someone who sees one code generally has only a short-lived opportunity to use it. Services can further limit that opportunity by rejecting codes that have already been used or by restricting repeated attempts.
What “no signal” does—and doesn’t—mean
Once setup is complete, generating a code needs no internet or mobile connection: the app reads its clock and computes the answer locally. The server still checks the submitted digits when you sign in. The striking part is that two devices can agree on a changing password without contacting each other until the moment you actually use it.
