Google Authenticator (I'm not sure about the app, but I know that the PAM module does) supports HTOP, which is the same HMAC-SHA1-based construction but relies on a counter instead of the current time. The counter is incremented on successful password entry (with the PAM module) and on request for the code via button on the mobile authenticator or token.
Which is annoying because now you cannot have an authenticator on multiple devices. With TOTP as long as you know the secret and time you can spin up Google Authenticator on anything and it will work, with HOTP you have the counter synchronization problem. This also makes backups a much MUCH bigger challenge.
That being said, HOTP is theoretically more secure than TOTP because even if the secret is exposed (e.g. old backup) they'd still need to crack the counter. It also does avoid clock problems.
I almost think the ideal solution would be to set up TOTP primarily and HOTP as a backup. Two different accounts, and you take the HOTP secret (likely QR code), print it, hide it, and destroy the digital copy.
From earlier, the google_authenticator pam code/project didn't fill me with confidence, but on the project page it does state it supports "emergency scratch codes" as well as HOTP -- from looking at the code again, I think they are considered the same thing, and it appears if you enter a scratch code, that'll let you log in (and if the code you enter is an invalid scratch code, the system will check to see if it was a valid time-based code):
I've successfully played with the python oath code to get 2fa working with "Star Wars: the Old Republic" (the game has a pretty broken interface for setting up 2fa - to the point that a lot of people give up, even if they give subscribers a 20% monthly bonus in in-game currency for using 2fa...).
Highly recommended for debugging/playing with OATH, in addition to the "main" oath tools, which IMNHO are much better documented (and comes with the binaries needed to do everything, like manually generating codes etc):
See also the always excellent Arch Linux wiki, which adds a tip about generating qr-codes from the secret (so you can store the secret in eg: Google Authenticator easily):
> it does state it supports "emergency scratch codes" as well as HOTP -- from looking at the code again, I think they are considered the same thing, and it appears if you enter a scratch code
No. HOTP and TOTP are treated separately. Both of which are separate from scratch codes.
HOTP can't "show the future" (well, you can generate multiple codes but it won't be useful for this) and have an order. Scratch codes are exactly N of them, and they're stored in ~/.google_authenticator and don't have an order. They're also twice as long because unlike the normal codes there's 8 (IIRC) valid ones, and they're ALL valid all the time. (until used)
And of course the switch statement that handles the core logic starts by checking scratch codes, and if that doesn't work, proceeds to check TOTP/HOTP:
But at least there's a comment documenting the magic return code (#DEFINE VALID_SCRATCH_CODE = 0, or an enum, or basically anything else, anyone?):
/* Checks for possible use of scratch codes. Returns -1 on error, 0 on success,
* and 1, if no scratch code had been entered, and subsequent tests should be
* applied. */
You could change the phone's time settings to match the computer's. TOTP doesn't require precise sync anyway, it usually works as long as the two clocks are within 30s of each other.
If your virtual machine can't sync with an NTP time server for an extended period of time (outbound security group), it will drift beyond 30s from actual time (just saw this in AWS about a year go).
Yep, I'm using 2FA with a SSH key on my private web server that's virtualized and regularly have time drift issues. still trying to find a way around it.
We use TOTP for MFA in AWS. Twice now I've had the situation where my token has had the wrong time and the workaround is to enter two successive tokens one minute apart to resync my token with AWS. I didn't RTFA, but I'm assuming it's at least _possible_ to implement an "oh crap!" fallback like this.
https://en.wikipedia.org/wiki/Time-based_One-time_Password_A...
The only requirements of TOTP are an accurate time source and keying data for an HMAC. No internet connectivity explicitly required.