3 ms·

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 authent

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
  - zhuzhuor 14y ago
    Thanks

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
- zhuzhuor 14y ago
  Thanks