You'll need to implement views for handling recovery tokens, processes for people losing their second factor due to stolen phone or corrupted app, and FAQ pages for questions about why my second factor is not accepted.
Also had a firewall rule that dropped NTP packets and took 3 months for the click to drift before anyone with 2fa codes couldn't log in anymore.
Can you even address this without defeating the purpose of 2FA?
You could also try human-in-the-loop authentication by having the user describe their account contents to customer support. However, that's notorious for allowing account takeovers because people are always the weak point in security.
It’s frustrating to see technical people discount or ignore that side of the deployment work, because that’s the kind of issue that actually blocks most security and cryptography measures in practice.
If I had a thousand dollars for every time I heard “just make the user keep a key safe” I could fund so much UX research :)
* generate, authenticate, distribute, back up
https://github.com/andOTP/andOTP
(And yep, I found out about Google Authenticator the hard way, trying to transfer from my previous phone!)
You're exactly right! The pure TOTP algorithm is the easy part. The underestimated part is the extra overhead of human customer support of users that messed up 2FA TOTP.
Title of blog post asks: >So what's your excuse?
One excuse is the issue outside of 2FA algorithm: lost 2FA credentials has more complicated recovery than 1FA. Many websites don't have an established procedure to deal with 2FA customer support.
Whether the 2fA user uses a smartphone, or Yubikey hardware, or software like WinAuth, it's not the simple process like 1FA of "just let customers self-service their own password reset by emailing a temp password to the email address we have in our records".
Case in point is me. Back in 2020, my web hosting service forced everyone (admins) to 2-factor TOTP and I kept putting it off because I was fine with just using a simple 1-factor password to manage my accounts. But then the day of reckoning came for 2-factor and it happened on a day where I was juggling a lot of problems and was in a hurry to login to my admin control panel to fix a configuration issue.
I didn't want to use my phone number for 2-factor because I didn't want the hoster to have it (prevent spam) so I downloaded "WinAuth.exe" and did whatever extra steps I needed to log in. But because I was in a hurry and didn't take meticulous notes and screenshots of what I did to enable 2FA, I now have no idea how to log back into my email host admin panel with a "verification code". I guess they gave me a "secret" for WinAuth to generate TOTP but I don't remember if I copy-pasted it somewhere or saved it to a file I can't find.
Either way, I'm now a customer support ticket because I'm locked out of my account. I was logging in successfully for 15 years with 1-factor before 2-factor came along and complicated the password situation.
Yes, it was my fault that I lost my TOTP procedures but that's not the point. The issue is that 2FA helps improve security but it also adds underestimated extra customer support issues and small websites can't deal with this extra workload. Just copying some trivial algorithm for TOTP doesn't solve that.
You should record the last successful count/time window to prevent code re-use. In the rare case that you expect clients to use devices to generate the codes that may be offline for a long time (or never connected dongles) you also need to compensate for personalized time drift for each device.
Solution: Backup/recovery tokens (never require phone/OOB recovery by default). Use email as a fallback 2FA if the service isn't critical.
For internal services/services at a business org, put in workflows for getting manager voice auth/phone call/etc. for more secure and trusted recovery validation.
Anyway, the point is for simple TOTP, it's a lot of security improvement for relatively minimal, one time work.