Hacker News Reader

Comment by skrebbel | Hacker News Reader

But then where did the 2nd factor go? I mean how is a recovery key meaningfully different from a password, except that it's a random string chosen by the service instead of by me?

Fear is being locked out is exactly why I'm reluctant to enable 2FA. To enable it and then just store the password (err, I mean, recovery key) in my password manager seems to just get me more hassle for exactly no additional security.

What am I missing?

View on HN

The recovery key is different because it's "locked in a safe" and used rarely, if ever, instead of being used constantly.

But.. is passwords being used a common way for them to leak? I've never heard of this before but I'm no expert. Isn't the threat model either company databases being (badly hashed and) leaked, or password managers being hacked wholesale?

I mean where am I supposed to store the recovery key if not in my password manager? My dropbox surely isn't better encrypted than my bitwarden. I work with the assumption that my password manager is the least insecure piece of data storage I use.

I really don't get it. How isn't 2FA just security theater if we're all supposed to store the recovery keys "somewhere safe"? Can we really expect people to deal with recovery keys in a more responsible way than they do with passwords?

>I mean where am I supposed to store the recovery key if not in my password manager?

My password manager (keepassxc) supports multiple databases. I store all TOTP recovery codes in a separate database (and with a different unlocking password) from the one that has regular passwords and the TOTP secrets.

All my databases are backed up on someone-else's-computer, but I only keep the regular-passwords-and-TOTP-secrets database synced to my devices.

I think "ideally" you print out the codes and physically secure them somewhere, so the risk isn't high. Recovery codes aren't about safety from being hacked, they're about mitigating the risk of you losing your 2FA code device.

In practice, 2FA is just another password anyway. What it really helps with is password reuse.

The best-case ordinary person is going to store them in "<user name>/My Documents/Security Keys/keys.txt".

The average-case person is going to ignore the generated keys because they are deluged with nonsense every day and can't filter out what is important anymore. Lots of people will get locked out of accounts before they learn that there is now yet another unwanted tech bureaucratic layer to take seriously.

I'm guessing in 5 years it will be normal to set up security questions for 2fa recovery keys. Or we'll add another 2fa for 2fa key recovery. The adding of layers will continue until we are all "secure" and we'll all have to ask for our misplaced keys from the NSA.

But what about on the server side? We generally know about passwords being salted and hashed. How are these recovery keys stored, regenerated etc? (I suppose they are also salted and hashed, but they are shorter and potentially easier to crack than good passwords, given a breach, no? Or just one longer, tougher recoveryKeyGenKey need be salted and hashed.)

This is of course implementation dependent, but ideally a recovery key is single use. You should also be notified by email or some other channel that the recovery key was used. Then you are immediately aware if this use was unauthorized and you can take appropriate action. This type of response is not possible for unauthorized password use.

you can get notifications for logins from a new device. isn't that just as useful?

I think there's at least a couple ways these are different:

1. It's easy to start ignoring such notifications if you regularly log in to new devices (or if logins expire). I don't think this is true to the same degree with notifications of recovery code usage.

2. Devices can potentially be spoofed.

Recovery codes are generated by the server, so:

• there's no temptation for the user to use them on another website, where they could leak

• the server can ensure they are high-entropy (although AFAICS GitHub's recovery codes are only 40-bit…)

Moreover, if someone takes over your e-mail account, they can reset your password; but they can't reset the recovery codes.

If this is all though, then couldn't we just use username+password auth but have the server generate the password? Why at the phone to the loop at all?

Are you saying that iPhone-maker Apple and Android-maker Google (and TPM-mandator Microsoft) might not be able to imagine a future where the whole world isn't dependent on them for identity?

No, I am not suggesting that 2FA is a secret ploy by BigCos to make them needlessly important. It's perfectly possible to log into services without using your Google/Apple/Microsoft identity, even if they insist on 2FA. Use the email and SMS, Luke!

Reply on news.ycombinator.com