2 factor HOTP counters becoming unsynchronised

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.

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.

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.

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.

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.