Author here: that's fair; I admit that it's sort of an extreme position to hold (and the framing is intentionally polemic).

Perhaps more fairly: services should only provide recovery codes by default once they (1) fully understand the role of recovery codes within the 2FA scheme, and (2) make efforts to relate that role to users and encourage best practices beyond "don't save this text file to your desktop!".

You're already asking a lot of users. Let them save the recovery codes wherever they want! The real point of the codes is to prevent people abandoning 2FA in frustration, even if it is at the expense of some security.

First of all: thank you for your work on securing congressional campaigns! I can count on my hands the number of people I admire in the intersection between technology and politics, and you're one of them.

I agree it's a lot to ask. But I think it's better to demand extreme security considerations from users and fall slightly short in practice than to encourage any practice that improves account security beyond a single password (e.g., SMS codes).

One frustrates users and makes them abandon 2FA, the other (IMO) encourages some complacency and makes it harder to justify changes to users (especially ones that are really great from both UX and security perspectives, like WebAuthn).

Thanks for the kind words!

Do I understand you right as arguing that having some people not use 2FA because the requirements are too harsh is better than bringing people onto "2FA lite"? Or are you saying something different?

Well, I guess that's the hazard: it's definitely better to have "2FA lite" than to have no 2FA at all, but I don't think our mentality when it comes to 2FA advocacy should be resignation towards the mistakes that users make. But that's a really hard line to walk.

What mistake is a user making? Sophisticated users lose access to their 2FA credentials all the time. The conventional advice is "enroll multiple TOTP devices". Most users don't have multiple mobile devices to enroll. Now you're asking them to enroll something on the desktop, which effectively undoes the "something you have" benefit of TOTP (see: the 1Password thread above). At least a recovery code _can_ be printed out.

I don't think the logic you're employing here is coherent. Consider it a bit longer! This post could be a good longstanding reference, but this is a big flaw.

Yeah, we discussed this a bit internally and concluded that opt-in recovery is an unreasonable standard to encourage. I'll update the post shortly.

Edit: Updated.

I like this post a lot!

Tom, just to be clear, your counterpoint to the original wording is "Recovery codes _should_ be mandatory", correct? Would you consider "Recovery codes should only be mandatory if a user has only configured a single second factor" to be a reasonable alternative?

I have multiple U2F keys configured on all of my important accounts. I'm comfortable enough in my belief that I won't lose _all_ of my keys to not want recovery codes to exist so I don't need to worry about storing them. This places me in the extreme minority of users to be certain, but I still don't want my security weakened by recovery codes that I won't ever use.

I'm ambivalent about the multiple factors case (unless one of the factors is SMS). My feeling (can't back up with evidence) is that most people who do that are savvy, but remember that part of the point of recovery codes (which are in fact a second factor) is to protect you from the service provider's account recovery flow. The more routine account recovery has to be, the less secure the service is likely to be.

Let's be clear though on who is at fault: this is way too hard to use correctly even at expert level. Users make mistakes because we are putting them at the controls of the 747 when they just wanted to send a spreadsheet to their colleague.

100% agreed. I've updated the post to soften the argument around recovery codes.

What? A constructive outcome? But my nerdfight!

It's unclear from the post that it's a polemic; it's structured more like a standalone reference. I think it's pretty good for that, except that the recommendation to avoid recovery codes is going to get users hurt.

> they're keep some number of customers out of your terrifying, manual account recovery flow.

What is the ideal, secure manual account recovery flow for users? Having worked at a SaaS startup previously (where application login 2FA was mandatory for staff initially, but providing it to end users was discussed extensively internally before eventual roll out), it doesn't seem like there is an easy solution to have random user prove who they are if their 2FA auth goes south (no recovery codes, access to TOTP lost).

I like the approach some MMOs use:

- Provide the printed CD-Key from the game box in full

- Provide details about the transaction used to purchase the game (address, date/time, name)

- Provide names of characters on the accounts

They're not impossible to get if you've compromised someone, but they're far from trivial.

In fact, it's actually very similar to the algorithm-based verification my bank uses...

Curiously, Blizzard had hardware tokens (and later phone authenticator apps) 10+ years ago, before most banks and I kind of want to say 'before most consumer online services in general'. And they had the exact same account recovery hellflow problems everyone else has, just earlier.

Namecheap just asked me a bunch of questions that anyone with access to my mail could answer (all in invoices)

First step is to understand your data and why or why not it might be important to hackers. Then base your implementation of 2FA around that.

Thanks for pointing that out! I think we made the wrong call too. Will and I updated that bullet to strongly recommend recovery codes, and note they provide an acceptable usability/security tradeoff.