By self-verifiable I mean the half of the code is a random number, the other half is computed based on the secret seed and the random number.
I guess another way without frequent sync is to generate a new code every sec, and the server check if it's one of the 25 codes in the last 25 seconds. But this might be unnecessary and inefficient.
By self-verifiable I mean the half of the code is a random number, the other half is computed based on the secret seed and the random number.
Yeah, TOTP doesn't do that.
I guess another way without frequent sync is to generate a new code every sec, and the server check if it's one of the 25 codes in the last 25 seconds. But this might be unnecessary and inefficient.
Here's how it actually works:
The auth code is generated entirely by:
1. The algorithm documented in RFC 4226 and 6238,
2. static preconfigured parameters of that implementation (e.g., SHA-1, 30s, 6 digits),
3. the secret seed for that token, and
4. the current time.
For a given token, (4) is the only thing that changes to generate new codes.
I know what it is based on, except the implementation details.
My question was what's the mechanism to verify the code refreshed every time the screen is turn on (which is a little different from other authenticators).
So if you turned the screen off and on every 1 second, you'd get a different code every single time?
I don't think there's a reasonable way to do that within the TOTP specification. There's (eventually) got to be some rate-limiting or it will reduce the security.
By self-verifiable I mean the half of the code is a random number, the other half is computed based on the secret seed and the random number.
I guess another way without frequent sync is to generate a new code every sec, and the server check if it's one of the 25 codes in the last 25 seconds. But this might be unnecessary and inefficient.