I read your comment carefully and it didn't make any sense to me.
The other way I thought is the code must be self-verifiable.
No, code verification requires knowledge of the secret seed value.
I read your comment carefully and it didn't make any sense to me.
The other way I thought is the code must be self-verifiable.
No, code verification requires knowledge of the secret seed value.
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.
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).
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.