- You and I share a secret at my first login. Let's say our shared secret is "wibble".
- For any subsequent successful login with my username and password, for the second factor I send you the last six digits of the SHA1-hash of ("wibble" XOR current timestamp)
- You calculate the second factor yourself as well by doing the same operation (you have stored "wibble" for my username, and know the current timestamp), and verify those last six digits. If they are wrong, I am an attacker!
An accurate version: https://datatracker.ietf.org/doc/html/rfc6238
Like, what happens if I set my phone to a different time?
What if the server has lost connectivity to an NTP service and its clock is a few minutes off?
Some systems have some extra magic that allow the server to adjust for each device's clock skew; this was particularly important for hardware tokens that didn't have network connections. To imagine how that might work, suppose the server normally accepts responses that are valid at times t-2, t-1, t (the current time, per the server), t+1, and t+2. If a user consistently replies with the t-1 token, we know that her device is running slightly behind and we can instead authenticate against t-3, t-2, t-1, t, t+1.
The TOTP implementation for AWS logins is particularly prone to doing this for some reason, and you have to enter simultaneous TOTP codes to resync.
Imagine a hash function that generates a number from the number of minutes since epoch hashed additionally with some seed. You have it on the server, you have it on your, say, phone. When you enroll you share a seed for the generator. Since your time is synchronized, the server knows what value(s) to expect, and the phone knows which value to generate.
The real scheme is a bit more involved: https://en.m.wikipedia.org/wiki/Time-based_One-Time_Password...