Ask HN: How do authenticator apps work?
Does anyone know how 2 factor authenticator services work? I'm curious how it's possible for the services reading them and the services creating them to predictably know the exact digit sequence at a given time without being knowable to 3rd parties. From an cursory undergraduate CS education it feels like a related but different problem to hash functions. Just curious!
4 comments
Each party (sender and receiver) share a secret, random key. This key is created and shared only once during the initial account setup.
Thereafter, this secret key is used by both sender and receiver to encrypt the current time and produce a hash code.
If the codes match and your login credentials are valid (2 factors), you are authenticated; otherwise, you are not.
Once you dig into it, it's not too hard to replicate. I wrote myself a simple desktop CLI program that duplicates the app on my phone. It retrieves the appropriate secret key (selected by key/name) from an encrypted data file and generates a code as needed and places it into the clipboard so I can easily paste into a login screen.
Thereafter, this secret key is used by both sender and receiver to encrypt the current time and produce a hash code.
If the codes match and your login credentials are valid (2 factors), you are authenticated; otherwise, you are not.
Once you dig into it, it's not too hard to replicate. I wrote myself a simple desktop CLI program that duplicates the app on my phone. It retrieves the appropriate secret key (selected by key/name) from an encrypted data file and generates a code as needed and places it into the clipboard so I can easily paste into a login screen.
> Thereafter, this secret key is used by both sender and receiver to encrypt the current time and produce a hash code.
Also noteworthy: the current time is divided into coarse time periods (typically UNIX time divided by 30s?), meaning that slight differences in clock time of all participants don't matter because they can reproduce the same hash code during the time period.
Also noteworthy: the current time is divided into coarse time periods (typically UNIX time divided by 30s?), meaning that slight differences in clock time of all participants don't matter because they can reproduce the same hash code during the time period.
Yes, all part of details left out of my general overview.
Time increment rollover is an issue even if clocks are synced perfectly. This is due to an uncontrollable human factor --- delay from the time the code is generated until it is input and submitted.
To account for this, most receivers will check the provided hash code against both the current and the previous time increment.
Time increment rollover is an issue even if clocks are synced perfectly. This is due to an uncontrollable human factor --- delay from the time the code is generated until it is input and submitted.
To account for this, most receivers will check the provided hash code against both the current and the previous time increment.
Very cool! This makes a lot of sense across the board. Thanks for explaining this!
You click, tap and hope like hell, for the magic to happen
Most authenticator apps use TOTP or HOTP algorithms to generate tokens against a shared secret. Look up these algorithms to see more.
they sync with time
Could you expand on this?
Maybe it is a hash from the unix time value with salt, stripped to tens of minutes before hashing.