Time-Based Temporary Passcodes - I would have thought they'd be device dependent

britechguy

Well-Known Member
Reaction score
4,468
Location
Staunton, VA
This morning I needed to walk one of the employees at the business where I set them up with M365 business through getting an authenticator app set up, since Microsoft is now demanding multifactor authentication.

I now favor 2FAS over Microsoft Authenticator, so I had her use that, as I do. But while walking her through the process on her phone I did the same thing on my own, and with her email address that's part of the MS tenant, and it allowed me to do that. We were both generating the same TOTP at the same time, and I would have thought there would be some dependence on the device doing the generating, but it appears not.

In thinking about it, since they are time-based, and temporary, I guess if you set up the same account in 2 different devices virtually simultaneously it makes sense that whatever is used to initially configure the code would be the same. I was using the same QR code, as we were screen sharing at the time, so that could play into it, too. My "copy" is now gone from my 2FAS instance.
 
Yep this works for all TOTP authentication. The QR code simply translates to a 20-30 character string which is your secret key.

Codes are generated by taking two parameters, the secret key + a datetime value, and using them to generate a hash value which is your TOTP code
The server generates the same hash value and verifies it matches, thus proving you are in possession of the secret key.

Which leads to another fact many people are surprised by. Generating TOPT codes doesn't require any internet connectivity at all, ever.
This is how hardware keychain devices such as below are able to work. Good budget option for staff who prefer not to use their personal phone for MFA. However FIDO2 keys such as Yubikey are a much better option now.

1724883252217.png
 
Generating TOPT codes doesn't require any internet connectivity at all, ever.

My only argument with that, and it's critical hair-splitting in my opinion, is that you need it to start the process to get that secret key from its source.

After that, though, I know you are 100% correct and it's the algorithm itself that generates the key (and, of course, it's matching "mate" on "the source side").
 
Codes are generated by taking two parameters, the secret key + a datetime value, and using them to generate a hash value which is your TOTP code
The server generates the same hash value and verifies it matches, thus proving you are in possession of the secret key.

Which leads to another fact many people are surprised by. Generating TOPT codes doesn't require any internet connectivity at all, ever.
This is how hardware keychain devices such as below are able to work.

I've never quite understood that - Doesn't this mean those keychain dongles (for example) need to know what time it is to generate the key? Where do they get the time information? And...wouldn't inevitable variations in their clock lead to mismatches? How do they handle, for example, movement among time zones? Wikipedia says the algorithm is:

TOTP value(K) = HOTP value(K, CT),

calculating counter value

CT=⌊T−T0TX⌋,
{\displaystyle C_{T}=\left\lfloor {\frac {T-T_{0}}{T_{X}}}\right\rfloor ,}


where

  • CT is the count of the number of durations TX between T0 and T,
  • T is the current time in seconds since a particular epoch,
  • T0 is the epoch as specified in seconds since the Unix epoch (e.g. if using Unix time, then T0 is 0),
  • TX is the length of one time duration (e.g. 30 seconds).

I guess I just don't understand how an $0.89 device can keep time accurately enough for this to work long term.
 
There are actually three principle types of hardware tokens, time based (TOTP), event based (HOTP) and programmable. The event based tokens use a counter that is incremented at both client and server side upon authentication (the client count can end up ahead of the server side but this is later updated), so no clock is necessary for HOTP. For TOTP both sides have a clock, and time drift can occur on the token over time, but drift can be accounted for in a similar way to how drift can occur on a HOTP token. Programmable tokens are generally the same as TOTP tokens, but instead of having fixed seed data the seed (and protocol settings) can be programmed (which also means the clock can be corrected).

I should add it is also possible to generate TOTP code using some Fido keys, but this is really a feature that makes the keys usable on authentication servers they would not normally be able to be used with and not really the principle way these devices were meant to be used (Fido has some strong anti-phishing capabilities but does have drawbacks regarding connectivity and authentication server adoption).

In response to the original question TOTP is device independent and can generate OTP codes completely offline if necessary provided (a) the internal clock is functional and (b) the device has the correct seed data (the seed data will be the secret, time window sizes and details such as the required number of digits).
 
Last edited:
Back
Top