[samuli]

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.

[jabart]

This 100%. Yes those functions are easy but that isn't the issue with 2fa, it's the people. I just had a customer send in a ticket that their account from 3 years ago had 2fa enabled. They didn't remember setting that up, clearly had a new phone since then. These quick clickbait articles never bring up those subjects and how to properly address them.

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.

[Wowfunhappy]

> These quick clickbait articles never bring up those subjects and how to properly address them.

Can you even address this without defeating the purpose of 2FA?

[FiloSottile]

Bingo. The support cost of MFA, especially non-SMS methods where some of the recovery process is delegated to the mobile operator, is the top-level bit.

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 :)

[sneak]

sneak’s law: users can not and will not securely manage* key material

* generate, authenticate, distribute, back up

[jasode]

>You'll need to implement [...] , processes for people losing their second factor due to

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.

[unethical_ban]

So, yes, I suppose a good totp article would cover the user experience as well. But just because some places implement it poorly does not mean it is a bad idea.

[radranic]

You also need more than just a yes/no just for the authentication.

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.

[unethical_ban]

Time drift is the clients responsibility. You’re letting perfect be the enemy of good - very few people use fully offline devices for years at a time, and if you’re not a bank, even something like a 2-5 minute diff is tolerable.

[RL_Quine]

The amount of support requests it produces is unreal.

[unethical_ban]

TLDR - "It's an extra feature".

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.