Timeline for How do Authenticators work?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 21 at 9:44 | audit | First answers | |||
| Jun 21 at 9:44 | |||||
| Jun 16 at 14:43 | audit | First answers | |||
| Jun 16 at 14:43 | |||||
| Jun 13 at 15:06 | comment | added | grawity_u1686 | @Daviid: Yes and no; the 30s time step is pretty much standard and nobody varies it (the protocol would allow it, but literally nobody does, and few apps even support non-default windows), but the server usually has an additional window to accept previous/next OTPs – which it does by offsetting the timestamp and not by changing its precision. For example, the client generates its OTP from "time mod 30" as the 'counter', while the server generates two extra OTPs with additional "(time mod 30)-1" and "(time mod 30)+1" as the 'counter'. | |
| Jun 13 at 12:16 | comment | added | Daviid | Isn't the 30/60 seconds windows to use a code defined by whoever set's up the authentication backend? | |
| Jun 12 at 3:55 | comment | added | grawity_u1686 | @SteveFord, "the number of 30 second time duration since unix epoch time" literally describes a timestamp. | |
| Jun 11 at 20:36 | comment | added | ilkkachu | @SteveFord, well, yeah, and no. When compared to HOTP (as above), where counter counts events, like button presses, saying that TOTP uses a timestamp instead seems appropriate enough. However, you're right that TOTP is defined as an extension to TOTP, just with a realtime-based "counter". Though at least the RFC at least seems to try to use terms like "moving factor" instead of "counter". | |
| Jun 11 at 19:56 | comment | added | Steve Ford | TOTP usually uses a counter instead of a timestamp. The counter is normally the number of 30 second time duration since unix epoch time. Hence the generated code changes every 30 seconds | |
| Jun 11 at 19:11 | comment | added | JenserCube | My point was not to help OP, but to help others who might find this answer and not have such a detailed level of knowledge. | |
| Jun 10 at 21:58 | comment | added | grawity_u1686 | @JenserCube: No, I have the feeling OP already knows when the QR code is used, given that the site asked them to scan it when enrolling and not to print it out for later. | |
| Jun 10 at 19:16 | comment | added | JenserCube | I like the answer, but perhaps write a bit about when the QR code is used in the flow (is it when I "enroll" my authenticator or when I want to use it later) and when any codes are generated / must be used. | |
| Jun 10 at 18:26 | history | edited | grawity_u1686 | CC BY-SA 4.0 |
deleted 45 characters in body
|
| Jun 10 at 18:15 | history | edited | grawity_u1686 | CC BY-SA 4.0 |
added 383 characters in body
|
| Jun 10 at 9:23 | vote | accept | Manngo | ||
| Jun 10 at 9:09 | history | edited | grawity_u1686 | CC BY-SA 4.0 |
added 65 characters in body
|
| Jun 10 at 9:04 | history | answered | grawity_u1686 | CC BY-SA 4.0 |