TOTP Password resynchronization

[rob_swann]

In case of TOTP based 2-step authentication we have a configuration called
“TOTP Time Step Interval” and “TOTP Time Steps”

As we know, above 2 attributes work closely and defines the number of time step intervals that the system and the device can be off before password resynchronization.

So if I am off by more than the permitted time limit, then password resynchronization is required.

I do not know, which password we are talking about and how to resynchronize it ?

Are we talking about re-registering the device ?
I do not think so because that is governed by “Maximum Allowed Clock Drift”

Your help is appreciated.

Thanks.

[Neil Madden]

Yes, it means you need to re-register the device.

For a bit of background, when you submit a TOTP code the server attempts to match the code you have submitted with the code for the current timestep, according to the server’s time. The “TOTP Time Step Interval” controls how large this time step size is, in seconds. If this does not match, then it tries the codes for up to “TOTP Time Steps” before/after the current time. E.g., if “TOTP Time Steps” is set to 2, then it will try codes for the 2 preceding and 2 following time steps. For example, if you submit a code at time-step T, then the server will check the time-steps for T, T-1, T+1, T-2 and T+2 in that order. If none of these match (or if a code matches that is earlier than the last login time) then authentication fails.

After the TOTP check has been carried out, the server will (optionally) look and see if the device clock is out of sync with the server clock and try to adjust it (resychronization). For example, if the TOTP check succeeded but with a code that is 1 time step ahead of the current server time, then the server will record that the device is one timestep ahead of the server. The next time you submit a TOTP code, the server will automatically adjust its own time-step to add 1 to it *before* carrying out the above checks. So in this, case if you submit a new TOTP code at time step T (from the server’s point of view), then it will adjust this to T+1, and then check the codes for T+1, T, T+2, T-1, and T+3. Let’s say that you now match at T+3, so your device has gone either further out of sync. As the new (adjusted) time is still within the 2 timestep window then the server will now record your device as being +3 timesteps ahead of the server, and so on.

So, at the point at which you submit a TOTP code, it cannot be more than “TOTP Time Steps” out of sync with the (adjusted) server time. However, over time it can drift further out of sync and the server will readjust, so long as it doesn’t drift more than “TOTP Time Steps” in a single go. To put a limit on how far out of sync the device can get, you can set the “Maximum Allowed Clock Drift” setting, which controls the *cumulative* maximum drift allowed.

Therefore, you will be required to re-register your device if it either (a) goes out of sync by more than “TOTP Time Steps” by the time you next submit a TOTP code, or if (b) it goes out of sync by more than “Maximum Allowed Clock Drift” time steps in total.

[rob_swann]

Very nice explanation Neil !!! Really appreciate it.

I want to share one more thought with you.
Is it possible to register 2 devices for the SAME user in the SAME datastore.
Now, let me clarify one thing,
REGISTERING 2 DEVICES DOES NOT MEAN THAT YOU PHYSICALLY NEED 2 DEVICES.
SINGLE MOBILE DEVICE, SINGLE FORGEROCK-Authenticator App. but with two profiles, generating 2 separate tokens for 2 separate web applications.

Because,

I have 2 Web-app. protected by OpenAM, may or may not be in the same realm.
Both Apps use different authentication chain.
App1 uses chain1 having ldap module (ldap1) and totp1
App2 uses chain2 having ldap module (ldap1) and totp2

So practically, when user accesses App1 for first time he will take a picture of QR code sent by OpenAM and register the device.

After some time, when user accesses App2 for first time he will take a picture of QR code (having another shared secret ) sent by OpenAM and register the device again.

Per my understanding device profile is usually specific to a user – NOT specific to an application or realm or an authentication chain.

So not sure if above set up is possible ?

Thanks for your help.

[Author]

Posts