…and just see how I’m going.

[Comment removed by author]

You addressed your question to @jcs, but it’s certainly my feeling that it’s nice to have a norm of 2FA everywhere.

A lot of financial institutions still don’t offer it, or offer it only with significant limitations - for example, only via SMS, or without support for app-specific passwords for services such as Mint and Quicken. Of course it’s usually possible to choose ones which do, but it’s often necessary to compromise on it for other reasons…

The stragglers are going to hold out as long as they can until there’s resounding public outcry. If we can create a culture where of course every site has a robust 2FA implementation, they’ll face a lot more questions.

Besides, personally, my social media profiles are important to me. I could create new ones if they were compromised, but I’d lose my username and history, and my followers on sites where that’s relevant. And there’d be the stress of having to spend a couple days dealing with it - making sure nobody was using it to do a “grandmother scam” on people I know, and that sort of thing.

I’m using this http://www.nongnu.org/oath-toolkit/ especially for testing. The UI here at lobste.rs does not expose the secret directly, but you can view source and get it there:

<a href="otpauth://totp/Lobsters:XXX@YYY.net?secret=abcdefgh&issuer=Lobsters">

Then using oathtool:

$ oathtool --totp -b abcdefgh

There’s a couple of different U2F gems, and none of them look hard to use, but to test it you’d need a U2F token or token simulator. If there’s a good way to test U2F support without messing around with Yubikeys, I’d love pointers.

Good catch, I’ll file a bug to make password changes require the current password as well.

The QR code shown during enrollment contains a link with the TOTP secret, which is what you would use to add it to any other TOTP app at any time in the future. If you’re storing backup codes somewhere in a password manager or offline, just store that TOTP secret instead and you’ll be able to get back in later even if your 2FA app/device goes belly up. It’s a 16-character ASCII string, so it will be easy to store.

I’m not entirely clear what you’re asking.

The lesson I take from stories like the one you linked is that email accounts have to be extremely secure, because access to them grants access to everything else. If an attacker has compromised my email account, they can and will change credentials everywhere else to lock me out.

I think you might be proposing a solution where, in case your email is compromised, you might still salvage other accounts because of backup codes. I don’t think this is viable if those accounts have any value; a motivated attacker will regenerate the backup codes and invalidate your old ones. Also, you shouldn’t be using a setup where the backup code alone lets you log in - it should always be a one-time code and a memorized password. Your description was vague, so perhaps this doesn’t speak to quite what you were trying to suggest?

It’s absolutely appropriate to treat email more carefully than all other accounts, as you do. Personally I use my main email for that; that way, its password is one I actually use frequently, so there’s less chance I’ll forget it.

Other than Google, the only service I use that has meaningful protections against that is Blizzard’s battle.net, which applies existing notification settings any time credentials are changed, even though they are being changed by a user who is nominally the correct one. (Some financial services I use also have that feature; I just don’t feel their other protections are sufficiently in-depth that the notifications will help.)

As an early adopter of password managers and 2FA, I’ve been locked out of quite a few accounts over the years. Some I got back; some I did not. In several cases, the backup codes were the only way I was able to get back in. So yes, backup codes provide a tangible protection. They do compromise security, intentionally, but I think they are a reasonable compromise.