4 ms·

For work things I often have to enter a code from one or another app that expires every few seconds. I've always wondered how exactly that works. Where might I

For work things I often have to enter a code from one or another app that expires every few seconds. I've always wondered how exactly that works. Where might I go to find out about that? Is it as straight forward as googling "how two factor authentication works" or is there some other terminology?

cs2733 5y ago
They're called Timed One-Time Passwords or TOTP and they're one form of 2FA
nine_k 5y ago
You mean TOTP? 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#Algorithm https://en.m.wikipedia.org/wiki/Time-based_One-Time_Password...
quadrifoliate 5y ago
A simplified and inaccurate version: - 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 https://datatracker.ietf.org/doc/html/rfc6238
- quelltext 5y ago
  I always wondered, doesn't that require the clocks to be synchronized? 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?
  - mattkrause 5y ago
    In practice, it's not the exact timestamp, down to the millisecond--there's a window of 30 seconds or so for each code. On top of that, some services will also accept one of the last (or next) few valid codes too. So it needs to be roughly synchronized, but not impractically so. 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.
    - quadrifoliate 5y ago
      In addition to this, it's worth mentioning that the two sides can go out of sync, and if so, there are ways to fix that. 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.

cs2733 5y ago

They're called Timed One-Time Passwords or TOTP and they're one form of 2FA

nine_k 5y ago

You mean TOTP? 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#Algorithm https://en.m.wikipedia.org/wiki/Time-based_One-Time_Password...

quadrifoliate 5y ago

A simplified and inaccurate version: - 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 https://datatracker.ietf.org/doc/html/rfc6238

quelltext 5y ago
I always wondered, doesn't that require the clocks to be synchronized? 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?
- mattkrause 5y ago
  In practice, it's not the exact timestamp, down to the millisecond--there's a window of 30 seconds or so for each code. On top of that, some services will also accept one of the last (or next) few valid codes too. So it needs to be roughly synchronized, but not impractically so. 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.
  - quadrifoliate 5y ago
    In addition to this, it's worth mentioning that the two sides can go out of sync, and if so, there are ways to fix that. 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.