5 ms·

I'm a little puzzled by the way authy works. It seems to me the authy app refreshes a new code whenever I turn the screen off and on. I don't know how it syncs

I'm a little puzzled by the way authy works. It seems to me the authy app refreshes a new code whenever I turn the screen off and on. I don't know how it syncs with the authentication server. The app must not only based on time ticks, like other 2-factor apps. One way I thought is to notify the authentication server in background network requests. But I guess this isn't the case, because it won't work if you don't have network signal (you can try it in the airplane mode). The other way I thought is the code must be self-verifiable. That means half of the code is a random number, and the other half is the real code computed based on the rand numb and some credentials. If it is really in this case the security strength is only half of the length of the code, i.e. 3.5 digits. That's not very safe to me, especially the website of authy itself only needs one code to log in (without any `first-factor` password). Any thoughts?

jgrahamc 14y ago
http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm http://en.wikipedia.org/wiki/Time-based_One-time_Password_Al...
- zhuzhuor 14y ago
  I don't think it is solely based on time. Did you read my comment carefully?
  - marshray 14y ago
    I have implemented HOTP/TOTP. HOTP is based on the secret seed and a counter value (e.g., button presses). TOTP substitutes time for the counter 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.
    - zhuzhuor 14y ago
      Please read my comment to @danielpal. 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.
      - marshray 14y ago
        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.
        zhuzhuor 14y ago
        You didn't get my point... 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).
        marshray 14y ago
        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.
danielpal 14y ago
It is based solely on time. The reason we refresh the time as you screen off and on is so that you always have 20 seconds ( I hate it when I open google authenticator and I have to wait for it to refresh). We do some complex things to make sure time is always synced in the background. If you are in airplane mode obviously we can't contact the server. But if you do have connection, contact our server in the background and sync it. We also store the delta of how much was your time desynchronize so that next time you are in airplane mode we can do a good guess of how much your time might be off by, and then we use that. We don't expose this to the user, it should just "WORK"
- zhuzhuor 14y ago
  Thanks for your explanations. I didn't get your details but I did more experiments. You may tell me if I am wrong. 1. If my phone has Internet connections, whenever the screen is turn on, the code is refreshed. If the code is solely based on time, the app may sync its time tick with the server every time when it's turn on. If the app sends its time to the server, the synced time value should also be encrypted and authenticated. The only pre-shared credential is the 6-digit pin sent by sms, which might be a little short. If the app gets the time from the server, it might have a slight time delay before the code is computed and shown due to the network latency. 2. If my phone doesn't have Internet connections, the code is only refreshed in ~5s. So I guess every 5s the app will generate a new code for the next 0~25s. When the server wants to verify the received code it will check whether it matches with the codes generated in 0s, 5s, 10s, 15s and 20s. So at least 5 different codes should work in the same time. This may be a nice way.
  - danielpal 14y ago
    1. There is a window of tokens valid at any given time, its called: look-ahead synchronization window size (http://www.ietf.org/rfc/rfc4226.txt http://www.ietf.org/rfc/rfc4226.txt) 2. The synced time value should also be encrypted and authenticated. No exactly what you are thinking. Time is transfered using https, so it's encrypted by that protocol, not our own. 3. Yes there is a slight delay, but see look-ahead synchronization window. 4. 2. If my phone doesn't have Internet connections, the code is only refreshed in ~5s. No. The code is refreshed same way as if it had internet connection. It's just we used previous information on how your device clock works to make educated guesses on synchronization. 5. When the server wants to verify the received code it will check whether it matches with the codes generated in 0s, 5s, 10s, 15s and 20s. Yeah something very similar to this. Read the RFC, we follow it very closely: http://www.ietf.org/rfc/rfc4226.txt http://www.ietf.org/rfc/rfc4226.txt

jgrahamc 14y ago

http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm http://en.wikipedia.org/wiki/Time-based_One-time_Password_Al...

zhuzhuor 14y ago
I don't think it is solely based on time. Did you read my comment carefully?
- marshray 14y ago
  I have implemented HOTP/TOTP. HOTP is based on the secret seed and a counter value (e.g., button presses). TOTP substitutes time for the counter 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.
  - zhuzhuor 14y ago
    Please read my comment to @danielpal. 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.
    - marshray 14y ago
      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.
      - zhuzhuor 14y ago
        You didn't get my point... 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).
        marshray 14y ago
        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.

danielpal 14y ago

It is based solely on time. The reason we refresh the time as you screen off and on is so that you always have 20 seconds ( I hate it when I open google authenticator and I have to wait for it to refresh). We do some complex things to make sure time is always synced in the background. If you are in airplane mode obviously we can't contact the server. But if you do have connection, contact our server in the background and sync it. We also store the delta of how much was your time desynchronize so that next time you are in airplane mode we can do a good guess of how much your time might be off by, and then we use that. We don't expose this to the user, it should just "WORK"

zhuzhuor 14y ago
Thanks for your explanations. I didn't get your details but I did more experiments. You may tell me if I am wrong. 1. If my phone has Internet connections, whenever the screen is turn on, the code is refreshed. If the code is solely based on time, the app may sync its time tick with the server every time when it's turn on. If the app sends its time to the server, the synced time value should also be encrypted and authenticated. The only pre-shared credential is the 6-digit pin sent by sms, which might be a little short. If the app gets the time from the server, it might have a slight time delay before the code is computed and shown due to the network latency. 2. If my phone doesn't have Internet connections, the code is only refreshed in ~5s. So I guess every 5s the app will generate a new code for the next 0~25s. When the server wants to verify the received code it will check whether it matches with the codes generated in 0s, 5s, 10s, 15s and 20s. So at least 5 different codes should work in the same time. This may be a nice way.
- danielpal 14y ago
  1. There is a window of tokens valid at any given time, its called: look-ahead synchronization window size (http://www.ietf.org/rfc/rfc4226.txt http://www.ietf.org/rfc/rfc4226.txt) 2. The synced time value should also be encrypted and authenticated. No exactly what you are thinking. Time is transfered using https, so it's encrypted by that protocol, not our own. 3. Yes there is a slight delay, but see look-ahead synchronization window. 4. 2. If my phone doesn't have Internet connections, the code is only refreshed in ~5s. No. The code is refreshed same way as if it had internet connection. It's just we used previous information on how your device clock works to make educated guesses on synchronization. 5. When the server wants to verify the received code it will check whether it matches with the codes generated in 0s, 5s, 10s, 15s and 20s. Yeah something very similar to this. Read the RFC, we follow it very closely: http://www.ietf.org/rfc/rfc4226.txt http://www.ietf.org/rfc/rfc4226.txt