Ask HN: What is a secure way to allow 2FA resets?

(A) Secret key. When a user is setting up 2FA for his/her account, the system generates a secret passphrase/QR Code as a crypto key, with instructions for user to write it down or print it out, then store it at a secure location.

(B) Manual review. The policy of a hosting company I use, is that when a 2FA-protected account is lost, the user must submit a national passport and proof of payment to reset the account manually.

And if user wants to add a new device.

(C) Send a challenge to the original device. If the system is in form of an app, it's as easy as showing up a Yes/No warning in the app: someone is adding a new device to your account, do you trust it? This is commonly used for various chat apps.

However, all the methods are not going to work for your use case, as the user wants to bypass the 2FA when setting up a new device... Currently, I don't see a satisfactory solution, otherwise, it effectively opens up a loophole and nullify the advantage of 2FA.

Let's see what other readers are saying.

An adversary takes over the email account, and checks if they reused their password on your site. If they didn't, then they'll try to reset the password, and you should check the second factor before resetting the password. If they did reuse their password, then you should check the second factor on login (assuming it's coming from a previously unrecognized source). At this point, the attacker will either give up, or attempt to contact your support channels, impersonating the user.

It's up to you what restrictions you place on your support mechanism for resetting 2FA. I would suggest a combination of the following:

- photo of a currently valid credit card associated with the account

- photo ID with address that matches billing address

- mandatory 7 day delay in the reset

- prove access to the payment method by issuing a payment for some fractional amount and request the amount, then refund it (or don't and keep it as a "security fee")

But no matter what you do, please please please be consistent. Train your entire support staff (if any), keep records of when people talk with you, don't disclose when the last time you talked was, and insist on following a process. If your process fails, see how and improve it.

Consider the risk involved, and who is responsible for keeping the reset procedure secure.

If you're building a bank app, make sure you have a proper reset procedure, preferably with human validation, like how user 'steventhedev' described. The bank (your company) is responsible for this.

If you build commercial/enterprise software, the 'admin' user should be able to perform resets. Preferably a customer must have at least 2 admin users, to prevent locking out. The customer is responsible.

If you are building consumer grade software, go with a reset procedure through email. The consumer is responsible for keeping that secure. If their email gets compromised, it can't be your responsibility.

It's built on public/private crypto, so it's not like TOTP where the QR code is the plaintext private key that has to be distributed around like it's candy.

When a reset is requested, you should then allow a grace period - possibly up to a month for the reset to be cancelled. You should notify the user via email/out of band mechanism that a reset has been requested.

On each login you should prompt that the reset is ongoing and that it can be cancelled.

Finally after a month, you revoke the 2FA and allow a new device to be activated.

Or alternatively/as well, you require that the user sets up a new account. You may allow them to merge this account after the reset has completed.

Fundamentally the question is "if a user took over someone else's account what the impact be?"

On reset, you may want to delete any sensitive recoverable data - e.g. Credit card details or Passport info.

1: This sends the message that you think it important, which might help them realise it is too.

2: They will have printed the QR code. Putting it somewhere safe is a small additional step.

Once you add in 2FA/TOTP, you're looking at the rate of resets skyrocketing as well as social engineering getting much easier because it's so plausible and frequent that code generators are lost.

* SMS reset is so bad it's comical. Hackers went from having to crack billions of possibilities to having to catch a six-digit number sent not even to my phone, but to my phone number. I've spent a lot of effort getting my number out of services who demand it as a reset option when I turn on 2FA. If you're using it as single-factor reset, I'm much safer with 2FA off.

* Email reset makes TOTP and passwords pointless. Just get access to the email and it's as if neither of those ever existed. No reason to even have passwords. Use magic links like Medium does for login. It's the same thing as a password reset with one less thing to remember.

* Documents like passport or license mean instead of cracking a password with 40+ bits of entropy, all I need is the person's real name and Photoshop and some motivation.

* Personal information like last 4 of credit card, birthdate, SSN turn those publicly available bits into passwords themselves which are also far easier to get ahold of than any password.

Obviously not very convenient. But one approach is to simply let a third party, like Google, do the identity management. Have only third party sso login, and don't do any identity management - only authorization.

I'm not aware of any frictionless, convenient and secure method. That was the reasoning behind Mozilla's web auth/sso project (I forget the name); access to email equals access to account recovery - so why not just allow proof of email account access be proof of identity?

For me, the central problem always comes down to mobile providers. I've managed to make some really serious changes to my mobile account without a hint of authentication. And, I would switch providers, but frankly, I've had that experience with every provider I have ever tried. When the secondary device itself is a major attack vector under every reasonable threat model, it makes the whole exercise seem like playing chess when your enemy is conducting full scale war games.

The right answer might be a mixture of manual review, sending challenges to the original device and conducting some profiling based on user agent, location and networks used to connect to the service. However, it's also entirely possible (and even likely) that our current means of authentication are fully hacked, completely fucked and due for a complete replacement.

During registration, a user adds a reset email that was different from the user's primary email. The email address is of someone you know who can give you the reset key when it is emailed to them.

With this approach, your designated reset buddy's email would have to be hacked as well then. So, even if you've been completely Pwn3d, your buddy hasn't.

In order to be able to prove who you are to reset your auth credentials, you have to have proven who you are when you set up the account, in a way which distinguishes your identity from that of others who share some-but-not-all of your attributes (e.g. your legal name.) Otherwise, anyone with those same attributes “has the key” to your account.

The only convenient way to create such a distinguished profile, is to hand over some legal identifying document that is linked to a pool of other identifying documents, such that if you later see a different such document, you can ask the relevant government whether it identifies the same person as the previous document you saw.

This requires keeping around identity documents for later comparisons, which is a fraught problem. I’d rather trust as few companies with my identity documents as possible—especially if I know that they’re going to need to keep them on file.

Thus why I say that probably only SSO providers can manage TOTP 2FA: without a secure 2FA-reset flow, they don’t “really” have 2FA; and only very few companies (i.e. identity providers) are able to be trusted with the documents required to implement such a secure flow.

——

...none of which matters all that much, because the real problem is TOTP itself, and the solution is to switch to a better type of 2FA. In the original enterprise 2FA smart-card implementation, it wasn’t the company with the account requiring auth that issued the 2FA token, but rather a separate 2FA issuer. The client would then get their card bound to each account they wanted to use it to authenticate. The card had a signing key, and the services just needed its matching public key.

With “real” 2FA impls like this, you aren’t supposed to need N 2FA tokens that you would need to reset separately with each rinky-dink authable service, but rather just one 2FA token, with token rollover—and the security around it—handled by the issuer. Use better 2FA.

While there's still a balance between convenience and security, this is an effective deterrent, as it generally requires the attackers to risk being identified (and makes it hard for non-local attackers who may rely on effective immunity from prosecution because their local gov't won't care), so the attackers will pick another target.

Depending on what's possible, things like requiring them to actually visit you with an ID (some financial institutions do this), verifying identity and documents over a video chat (much harder to fake than photoshopping a single scan of ID, and in case of fraud, you'd have identifying info - video of face and voice of a fraudster or their associate), delivering new credentials by courier to the HQ of the company who's your customer, delivering new credentials by physical mail to the billing address, things like that - things that tie to the physical identity of the real customer instead of just their online accounts, or things that require a potential attacker to surrender part of their anonymity.

Maybe add a workflow that checks whether they have the backup code or not and if not prompt them to note it down again. Maybe on second login/usage after setting up 2FA. If they still don’t do it just revert to email reset.

There isn’t much you can do if the user isn’t security conscious and doesn’t intend to be.

Is it a particular demographic? I’d assume this is an issue faced by most of the apps with 2FA.

Which is more important, retaining the person, or protecting their data? If retaining the person, then give them some simple and less secure method like a recovery email address. If protecting the data, I would leave them locked out of their account. Unpopular opinion, but I do that a lot it seems.

Trust isn’t cheap. Credit based verification services are better than email. Adding verification via physical mail adds some value.

Fundamentally, you need to decide whether it’s important to know that I am in control of the email address associated with “Spooky23”, or that I am a particular human being.

Manual review with proof of ID is the only way. Anything else will just have people not following instructions and requesting manual review anyway.

If anybody asks for higher security you can add a profile option to disallow manual review for their account. This should be visible on the settings screen but I would suggest making them write a request to turn it on. This can then open into a conversation about security if you are interested. And prevents people who don't understand it from turning it on to "increase security".

you have to do some diligence to ensure the contacts aren’t all the same person, decide if they (or some minimum) have to also be 2FA, prompt the user from time to time to confirm the list, etc.

ps. this is called the recovery problem and is indeed the hardest part of 2fa. if you can punt entirely, eg like github, you can save yourself 95% of the grief of supporting 2FA