2 factor HOTP counters becoming unsynchronised

[Simon Davy]

There have been a few support incidents of folks being unable to login because they'd generated too many OATH/HOTP tokens on their devices and the counters had become out of sync. Reasons include "to show their friends how it worked"

A mitigation might be to increase the counter window (currently 3).

Another mitigation is to include some help text warning users about the possibility of going out of sync in the new device pages (or other location ) if they generate many tokens

If this becomes a regular issue, it *might* be worth moving to the time based OATH/TOTP tokens.

[Selene ToyKeeper (toykeeper)]

This may be a bit tricky. Time-based tokens would be great, but not all auth devices have access to the current time. Or at least, not to a degree that is sufficiently accurate. The Feitian OTP c100 keyfobs, for example, have no I/O other than a single button and a small LCD, so no means of syncing the time. The Yubikey acts as only a USB keyboard, so it doesn't have access to the time.

Increasing the window size would make the system more forgiving, but it also increases the risk of successful brute-force attacks. See Bug #979303 for more info on that. It also wouldn't help in some cases. I had one guy who set up his system to have a 2FA passcode on screen at all times, and it updated the code every 5 minutes. Later that day, he couldn't figure out why he was unable to log in. When I looked at the details, his client was 54 passcodes ahead of the server. Other users have gotten themselves significantly ahead too, though not quite as much.

I've documented the issue in the FAQ, but that doesn't help if the user hasn't read the FAQ or is already locked out:
https://wiki.canonical.com/CDO/ISD/Docs/SSO/2ndFactorFAQs

The solution I've been recommending to users is that they have two auth devices on their account -- one primary and one as a backup. If one gets out of sync, they can use the other to log in, remove it, and re-add it.

[Selene ToyKeeper (toykeeper)]

FWIW, the method I use to determine where a user is in their passcode sequence is:

1. Ask the user to generate a new code and send it to me. This also serves to authenticate them to me, and show that they actually have the auth device. Let's say their next code is 479818.
2. Look up their shared AES key in the SSO admin UI. Let's say their key is DEADBEEF.
3. Find the code in the sequence. This command works:
    for n in $(seq 0 1000) ; do echo -n "$n: " ; oathtool -c $n DEADBEEF ; done | grep 479818
    14: 479818

Their sequence number is on the left, assuming it is found at all. With this, I can tell how many auth codes they have spent between logins, and can re-sync the server to their device. Normally I'd have them use their backup device to delete and re-add their primary device, but sometimes that's not possible. If they have a Feitian OTP c100, it's necessary to sync the server to the client instead of re-adding it.

[Stuart Metcalfe (stuartmetcalfe)]

Switching entirely to time-based tokens brings its own set of potential problems but we may consider 'adding' time-based clients as an option in the future. I think we could consider displaying some kind of warning when the user first sets up a device to avoid PEBKACs but further increases in the drift window are probably a bad idea for the reasons Selene has explained.

[Selene ToyKeeper (toykeeper)]

I suspect that paper auth (Bug #911942) can largely eliminate the counter sync issue, since it can work as a nearly universal backup auth method that lets users to recover their accounts without our help.

[Daniel Manrique (roadmr)]

Paper auth, HOTP resync and TOTP support should be reasonable mitigations for this. We still get the occasional lost soul who got so out of sync our resync process doesn't work, but those are few.