Hacker News Reader

Comment by Someone1234 | Hacker News Reader

The number one reason I don't turn on MFA has nothing to do with the effort in entering the MFA code/pressing a confirm button. The lifecycle of MFA is the problem.

The backup/recovery options are just terrible. You either print out a sheet of "one time codes" (which I need to not lose forever), my phone simply needs to never break, or I need to configure an insecure recovery account (creating a whole chicken/egg problem).

This is in no way mitigated by using physical keys either. Which can also be lost/broken/stolen/etc. You still need recovery/backup.

Plus a ton of vendors allow customer support to trivially turn off MFA via social-engineering, so what is the point? If people want MFA to be more common, make the lifecycle better. Right now the backup/recovery situation is all over the place and frankly bad.

View on HN

I was blown away when I discovered that there was no way for me to export my Google Authenticator TOTP secrets from my locked Android phone, since unlocking it wipes the disk. I guess I will not make the mistake of not immediately unlocking an Android phone again.

You can save the TOTP secret on your own when setting the Authenticator. Usually you have a choice between a QR code and a text, just save the text to your separate "account recovery" database in your password manager, then set the phone with the QR. I do that with any service not offering recovery codes for their 2FA (shame on you).

Likewise, it was not fun when my phone with GA suprise died. Many services with 2FA do not provide backup codes. I switched over to Authy for this reason--they allow an encrypted backup of the TOTP secrets.

So what do you do? How did you get your account back?

I ran into a similar issue. I had 1100 dollars in an account secured by authenticator and did not save the recovery codes when I set it up. I had to jump through hoops to get it back, which is good.

But I didnt realize I would have to reset up every single code on authenticator on the new phone. When you have a lot of accounts it's pretty obnoxious even with recovery codes. It didnt help that google support directly told me that they would be automatically be restored on the new phone along with the rest of the settings.

This is why you need two options. It could be a yubikey and your phone, or a yubikey and backup codes kept in a safe, or two yubikeys, one of which might belong to a trusted relative.

Or if you're really worried about getting locked out, maybe three options.

And keeping a truly reliable backup is hard. Do you print out recovery codes, laminate the paper, and put them in a fire resistant home safe, or a safe deposit box?

> And keeping a truly reliable backup is hard. Do you print out recovery codes, laminate the paper, and put them in a fire resistant home safe, or a safe deposit box?

This had me thinking about off-site backups and eventually my mind got to steganography (as the trust placed in the off-site custodian is a lot). It's a shame backup codes don't match phone numbers in terms of digit count, that would make keeping a book of them more easy to obscure, or even leaving a couple in your synced contacts as unassuming names.

You don't need to laminate or fireproof as long as you promptly regenerate the key if one of the two is destroyed.

Yes, those are good ideas. It's not that hard. You need somewhere to keep other important papers anyway.

Use an MFA app that supports exporting an encrypted backup, like Aegis.

I hope a future version of U2F will support enrolling a not-physically-present token by public key.

Not practical.

The public key is different for each enrollment, on purpose to deliver pseuonymity. If you enable U2F for Facebook, and then I borrow your Security Key and also use it to enable U2F for Facebook, although obviously that key will now work for either of us for signing into Facebook, Facebook don't learn that it's the same device. If Microsoft compares the data from GitHub to their own U2F data, they don't learn anything about whether GitHub users are also live.com users from that data, none of it correlates.

You can actually make it work and still maintain pseudonymity. A primary key could register a backup key by generating a site-specific keypair, encrypting the site private key using the backup base public key, and then using the encrypted site private key as the key handle. The primary key would need to know the backup key's base public key, but not it's base private key, and each site would still get a unique public key and key handle.

Hmm. This would need a fairly substantial redesign in FIDO and might make the hardware more expensive, but in outline it sounds viable.

The hardware today doesn't have a "base private key" (or public key) in the sense you mean. I feel like you're thinking about this like it's RSA, which it really isn't. RSA is weird because Encrypt and Sign are related operations, that is not how most things work. So you'd have to use key agreement plus symmetric crypto, and you'll struggle to fit everything into the current data structure sizes.

Way late reply you'll probably never see, but I'm fairly sure it's possible with the U2F protocol and existing hardware. I simplified the algo so as not to obscure the big picture, but I have actually worked out all the details and identified hardware I think would work. (I seriously considered trying to build a business around the idea and worked through the feasibility in a lot of detail. In the end I decided it was completely feasible but a crapload of work and limited marketability.)

You've correctly identified most of the tricky bits: the real algo involves key agreement plus symmetric crypto, it's a tight fit size-wise, and not all hardware has the necessary capabilities. However I think you're wrong about the conclusion. Can't say for sure though, as I didn't produce a working prototype. If you actually see this and want to discuss it in more detail you can find my email in my profile.

>The backup/recovery options are just terrible

This is not the case if you are using a corporate controlled account

Reply on news.ycombinator.com