I have 2FA on one of my web apps. Most users are using Google Authenticator which uses TOTP (Time-Based One-Time Password). On first login, we show them a QR code. We instruct them to save a copy of this QR code in the event they get a new phone or want to install a new 2FA app. However, I am running into a situation where users are not doing this. I can easily enough reset their account to show a QR code again on next login, but my question is: What is the safest way to "authenticate" them for a reset? I could do things like send a reset email to the email associated with the account, but I am just wondering what others are doing for situations like this. I want to make sure I am doing it as securely as possible.<p>Thanks!
This is the most tricky issue about 2FA: who's going to authenticate the authentication system? From what I've seen in practice, if an account is lost, there are two primary ways for recovery.<p>(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.<p>(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.<p>And if user wants to add a new device.<p>(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: <i>someone is adding a new device to your account, do you trust it?</i> This is commonly used for various chat apps.<p>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.<p>Let's see what other readers are saying.
You probably want to request a reset.<p>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.<p>On each login you should prompt that the reset is ongoing and that it can be cancelled.<p>Finally after a month, you revoke the 2FA and allow a new device to be activated.<p>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.<p>Fundamentally the question is "if a user took over someone else's account what the impact be?"<p>On reset, you may want to delete any sensitive recoverable data - e.g. Credit card details or Passport info.
Consider the threat model:<p>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 <i>before</i> 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.<p>It's up to you what restrictions you place on your support mechanism for resetting 2FA. I would suggest a combination of the following:<p>- photo of a currently valid credit card associated with the account<p>- photo ID with address that matches billing address<p>- mandatory 7 day delay in the reset<p>- 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")<p>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.
To add to the (mostly excellent) comments on this threat:<p>Consider the risk involved, and who is responsible for keeping the reset procedure secure.<p>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.<p>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.<p>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.
One option would be on the sign-up side: get them to "test" the recovery option. Keep bugging them about it every log-in until they do. This has two advantages:<p>1: This sends the message that you think it important, which might help them realise it is too.<p>2: They will have printed the QR code. Putting it somewhere safe is a small additional step.
Put a timer on the reset - Allow them to start the reset process, but make it so it takes a while (At least a few days), and during that time make sure any successfully logged in person on that account sees large warnings that someone is resetting their 2FA. This ensures that whoever actually owns the account can react in time to stop a takeover, at the cost of making the reset process kindda painful.
Most answers here are things that won't work because people are human and will lose or forget stuff one way or another. What I've seen that works quite well is to have a user list a number of email accounts that they trust to vouch for them. If they lose their 2FA and 2FA backup then they can do an email reset, but only if n of m of their friends authorize it and only after a delay of some kind (24 hours, say). Now an attacker needs to figure out what the likely friendlies are, pop multiple email accounts, and the delay gives enough time for someone to notice something and lock the account down.
Personally, I think true 2FA—of TOTP-type 2FA tokens that most people mean when they say “2FA” these days—can only work in the context of a SSO service / “identity provider” (in OpenID parlance) which requires KYC document submission (birth certificate, passport, etc.) upon sign-up.<p>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 <i>distinguishes</i> 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.<p>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 <i>different</i> such document, you can ask the relevant government whether it identifies the same person as the previous document you saw.<p>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.<p>Thus why I say that probably only SSO providers can manage TOTP 2FA: without a <i>secure</i> 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 <i>secure</i> flow.<p>——<p>...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 <i>bound</i> 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.<p>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.
I've been pondering a trusted network using shamir secret sharing for this case - where you can rely on other parties to hold the secret key and call on them. For example, origin player loses 2FA to system A, origin player calls out to their immediate backup personnel (origin player sets limit of how many are required to recover secret). Each backup personnel can say OK - sending partial to system A, once enough have been sent the secret is recovered. Complex, and time in-detriment, and still prone to failure or breach of trust.
This problem has me considering that TOTP/2FA is inherently less secure than password only. If you're using a password manager and that site has a unique password, you're almost certainly secure as long as the login process has rate limiting against brute force.<p>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.<p>* 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.<p>* 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.<p>* 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.<p>* 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.
aliexpress has a good hat-trick for it. If you're resetting your password, or authentication, then all stored credit card data is wiped from your account.
You're running up against the issue of identity management. The schiboleth sso technology of colleges and research institutions solved this by letting institutions manage accounts. To reset your login, go to you it department with photo ID and request a reset.<p>Obviously not very <i>convenient</i>. 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.<p>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?
Honestly, I'd be a liar if I said that I knew. PaulAJ might have the best idea that I've read - force people to test the recovery option. Though sadly, I've never had much luck convincing really smart people to test that mission critical things like backups work, so my inner marketer fears what that kind of friction will do to user retention rates.<p>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.<p>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.
For valuable accounts, it may make sense to require physical contact in any "I've lost all credentials" scenario.<p>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.<p>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.
How about a "Reset Buddy"?<p>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.<p>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.
As of now there’s not much you can do other than educating your users.<p>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.<p>There isn’t much you can do if the user isn’t security conscious and doesn’t intend to be.<p>Is it a particular demographic? I’d assume this is an issue faced by most of the apps with 2FA.
What are you protecting? Financial data? If so, have them go to a branch office and prove their identity to a person.<p>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.
Look at the NIST defined identity assurance levels and the guidance for MFA issuance.<p>Trust isn’t cheap. Credit based verification services are better than email. Adding verification via physical mail adds some value.<p>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.
NearlyFreeSpeech has a pretty comprehensive guide for how they handle 2FA resets, it might be worth a look: <a href="https://faq.nearlyfreespeech.net/section/login/losteverything#losteverything" rel="nofollow">https://faq.nearlyfreespeech.net/section/login/losteverythin...</a>
Give them FIDO keys.<p>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.
Don't use email or SMS as it weakens the security to that of their email or - yuck - phone company customer service.<p>Manual review with proof of ID is the only way. Anything else will just have people not following instructions and requesting manual review anyway.<p>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".
Account recovery is the #1 problem with any authentication system. Facebook's optional trusted contacts is probably the most scalable, secure version I have seen.
social. 3 out of 7 pre nominated contacts.<p>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.<p>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