9 ms·

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

• Spooky23 8y ago
  Look at the NIST defined identity assurance levels and the guidance for MFA issuance. 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.
• MaxGabriel 8y ago
  If your app is team based, you could set it up so that admins of the team can reset people’s 2FA device, similar to how AWS does it with IAM roles.
  • eropple 8y ago
    If their app is team based, they should be deferring 2FA to the IdP that that team should already have.
• StavrosK 8y ago
  Just don't let them proceed without generating and inputting a code. Why are you just showing the QR code and hoping they save it?
  • jeremygaither 8y ago
    Services like AWS do this. Requiring them to provide at least one (if not two) generated codes before proceeding ensures they have at least captured the 2FA code.
• segfaultbuserr 8y ago
  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. (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.
  • nindalf 8y ago
    A. OP's original problem is that users aren't noting down the secret when they're requested to. B. Manual review works, unless there is a sufficient incentive to break it. Here's an example of PlayStation Network struggling with hackers disabling 2FA via customer support - https://waypoint.vice.com/en_us/article/43ebpd/the-long-weird-story-explaining-why-i-bid-dollar700-for-a-stolen-psn-account https://waypoint.vice.com/en_us/article/43ebpd/the-long-weir... C. If a user is resetting 2FA then most likely they've lost the device on which they had the authenticator app installed. If they still had access to it, authorizing them to perform a 2FA reset would be trivial. D. Reset via email is the most commonly used one. It's scalable, unlike manual review. Less secure, arguably. > This is the most tricky issue about 2FA: who's going to authenticate the authentication system 100% agree here. It's a hard problem.
    • segfaultbuserr 8y ago
      > B. Manual review works, unless there is a sufficient incentive to break it. In my example, there is a sufficient incentive for an attacker to break into a server though the 2FA loophole, since there are valuable assets hosted on it. This is why my hosting provider requires users to obtain and submit all the paperwork, which must be corresponded to the address in payment information. I'd summarize the disadvantage of manual review as low-efficiency: as a casual player, I would feel ridiculous that a company requires my utility bills and passport to reset my gaming account. I'm sure a rigorous identity check was not performed your the PSN example. Poor scalability: the number of accounts is much higher in a game than in a professional service like hosting or payment. Humans need to do all the works. And prone to social engineering.
• PaulAJ 8y ago
  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: 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.
  • Klathmon 8y ago
    Even then a backup code like that isn't going to work in all cases. This is the same issue that electronic/cryptographic voting schemes run into. You can't in many cases just tell your user "too bad you lost the code", you need a way for a user who has lost everything to get back in. Shit happens, theft, floods, fires, other natural disasters, etc... And in those cases it's somewhat common for the user to lose their phone (with the 2nd factor app on it), as well as their backup codes. Sure, a game might be able to get away with saying "sorry, you lost your 2fa and backup, so you are SOL" (the user won't be happy, but it's not the end of the world), but for a bank account? For a utility company? For your email account? Telling the user "so sorry you are fucked" is a very bad thing, and could even be illegal in some cases. Forcing the user to verify that they printed it out and saved it can help cut down on the number of reset requests, but it won't completely solve the problem. You still need a way for someone who has lost everything to get the account back.
    • naravara 8y ago
      >Shit happens, theft, floods, fires, other natural disasters, etc... And in those cases it's somewhat common for the user to lose their phone (with the 2nd factor app on it), as well as their backup codes. >Sure, a game might be able to get away with saying "sorry, you lost your 2fa and backup, so you are SOL" (the user won't be happy, but it's not the end of the world), but for a bank account? For a utility company? For your email account? Telling the user "so sorry you are fucked" is a very bad thing, and could even be illegal in some cases. In some cases you might be able to get away with using waiting periods. You can establish like a month or so and ask them to re-request after that with a recovery code you give them when they first make a request. If nobody accesses the account in that time, you can have a bit more confidence that the request is legitimate and the account owner really has lost their credentials. And then when they re-request with their recovery code that's the authorization to start the reset. In some cases you could tide them over with a temporary account that has limited privileges for the duration of the waiting period that can be merged back into the original account once its unlocked. You could probably even do some analysis behavior in the temp account to see how well it matches up with points of contact, frequency of use, word choice, location, etc. on the main account. I wouldn't trust that for a bank or a primary email, you really need to verify identity for that. But for a utility company it might be ok.
• richardwhiuk 8y ago
  You probably want to request a reset. 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.
  • Klathmon 8y ago
    This is the one that I like the best if manual human review doesn't work for your use case. Set a reasonable time period (a month seems like really long, I was thinking more along the lines of a week), use every piece of information you have to attempt to alert the user multiple times that a reset is happening (email, text, in-app alerts, etc...), make sure that each "alert" gives the user a one-click way of stopping the reset, and when the reset is successful, delete all information that is easily replaceable (like saved credit cards or addresses, or as much personal information that you can get rid of).
    • nmalaguti 8y ago
      One of the problems with that is it makes account recovery after a compromise that much harder. If an attacker manages to prevent you from seeing those notifications (compromised email/sms) and you aren’t actively signing in, it’s possible for the month to lapse. Once the attacker has control and you try to reassert ownership, the attacker gets a loud warning every time you try to login/change the TFA and a month to respond.
      • Klathmon 8y ago
        That's very true, so I guess at the end of the day manual verification is needed for just about everything where you absolutely need a user to be able to recover their account. A scheme like the above still helps cut down on the number of times that manual verification will have to be used, and hopefully can be made rare enough that you can spend the proper amount of time verifying each one to do your best to prevent "stolen identities" from being used.
• steventhedev 8y ago
  Consider the threat model: 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.
  • amf12 8y ago
    > photo ID with address that matches billing address Please don't do this. There are people who move often to not have their current address on their photo id.
    • DennisP 8y ago
      For this to be a problem someone would have to lose their 2FA device, and their backup codes, and change their billing address but not the address on their ID. If all that does happen, they can solve it by updating their ID, which most states require within 30 days of moving anyway.
      • zodiac 8y ago
        Or they could have used a billing address different from where they live to start with.
• e12e 8y ago
  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. 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?
  • rrdharan 8y ago
    I believe Persona is the project you are thinking of: https://en.wikipedia.org/wiki/Mozilla_Persona https://en.wikipedia.org/wiki/Mozilla_Persona
    • e12e 8y ago
      Yes, thank you.
• lozenge 8y ago
  Don't use email or SMS as it weakens the security to that of their email or - yuck - phone company customer service. 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".
• hluska 8y ago
  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. 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.
  • dmoy 8y ago
    > force people to test the recovery option login.gov at least makes you prove you copied the 2fa backup number... at least on the next screen. So far that's the best I've seen. After dealing with the shitshow that is the treasury's login, I was pleasantly surprised that login.gov appears to be pretty good. I was literally feeling sick to my stomach when creating a login.gov account in anticipation of more crap, but nope turns out it's fine :)
• LeonM 8y ago
  To add to the (mostly excellent) comments on this threat: 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.
  • steventhedev 8y ago
    > 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. That defeats the whole point of 2FA.
    • CharlesW 8y ago
      > That defeats the whole point of 2FA. Does it? I think of "security" as a relative thing, and would rather be more secure than less secure even if imperfectly secure (which isn't possible in any case).
    • LeonM 8y ago
      I don't agree. If my password for <random_consumer_service> gets compromised, the attacker can not login at <random_consumer_service> due to the 2FA. To 'defeat' the 2FA, the attacker must also know my email address, and password, and have access to the 2FA of my email account. Your email inbox is a SPOF to most services you use, if it's compromised, you are fubar anyway. That cannot be the responsibility of the creator of <random_consumer_service>.
    • move-on-by 8y ago
      I'd say on average anyone who is concerned enough about their security to turn on an optional 2FA feature is also going to have 2FA enabled on their email as well. If I were only allowed to have 2FA enabled on a single account, it would be a very difficult decision between my password manager and my email. As you point out, email access is the key to the kingdom. Also, the only password that I do not put in my password manager is my email account password.
• monocasa 8y ago
  Give them FIDO keys. 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.
  • SheinhardtWigCo 8y ago
    What happens when a user loses their FIDO key?
    • DanBC 8y ago
      They use their backup key.
      • Klathmon 8y ago
        And if there is a flood that destroys that too?
    • monocasa 8y ago
      You give them another one. But people lose their FIDO keys about as often as they lose their car keys, which is far less than they forget their passwords, or don't finish setting things up.
• nimbius 8y ago
  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.
  • CharlesW 8y ago
    That's brilliant. You could even hide other data (shipping addresses, purchase history, etc.) until valid payment information is re-entered, or until the next successful purchase.
    • sowbug 8y ago
      To generalize the idea: as long as anyone can create a new account, then the value of a new account is zero. The value of the lost account is the value of the differences between it and a new account. The recovery cost should be directly proportional to the value of the account. Aliexpress turns this formula on its head, starting the recovery operation by taking a high-value account and turning it into a low-value one, then presumably using a correspondingly low-cost recovery method. There is an issue of not needing credentials to delete payment data as a kind of DOS attack. Your idea is smart as well: it turns the high-value component of the account into a credential of its own.
• 3pt14159 8y ago
  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.
• arama471 8y ago
  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.
  • SlowRobotAhead 8y ago
    Counter that if I’m a hacker, I’ll already have knowledge of this and try and time my attack when my target is unlikely to log in, but I suppose we’re getting into weeds with that.
    • lisper 8y ago
      There is no staying out of the weeds when it comes to security. The weeds are where the threats hide.
      • SlowRobotAhead 8y ago
        We all better get a cabin in the wood then ;)
    • bad_user 8y ago
      If you’re doing that in July or August, or between Christmas and New Year’s Eve, there’s a high probability that the target is offline.
  • ceejayoz 8y ago
    Authy does this - 24 hours during which there are repeated texts, emails, etc. to the addresses they have on file with dire warnings. Still vulnerable to a "I know this user is on vacation for a week" attacks, but it's fairly effective.
• miketery 8y ago
  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.
• derefr 8y ago
  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. 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.
• deleted 8y ago
  [deleted]
• LinuxBender 8y ago
  What are you protecting? Financial data? If so, have them go to a branch office and prove their identity to a person. 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.
• Lucent 8y ago
  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. 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.
  • mont 8y ago
    With a PM you're trusting that the PM is: a) Trustworthy b) Secure With TOTP/2FA you would need to crack both the PM/password and the second authentication method.
  • techsupporter 8y ago
    If the reset process allows for both the 2FA and the password to be reset using a single one of the four points you've mentioned then, yes, it's a terrible design that should be scrapped immediately. However, if any of the four points you've mentioned allow for only resetting the 2FA option and still require possession of the password, then I think you're more secure with 2FA enabled. Why? Because the reset step, if nothing else, provides an additional hurdle to be crossed. Yes, SMS 2FA is terrible and anyone who uses it should be barred from owning anything more complicated than a light switch, but that doesn't discount all of the other, better methods. Even e-mail as a reset factor can be more secure if the e-mail account is secured. In my experience, people are more willing to put up with "hassle" to secure their e-mail because it has stuff they care about in there. It's been far easier for me to get people I know to enable app-based or (shockingly) even physical device 2FA with a Yubikey on their e-mail accounts. I even know two older, non-technical people who already had it enabled because "I read that it's better for e-mail so I turned it on and put that printout it made me do in the safe." So 2FA seems to me like it can be more secure as long as it is really 2 factor auth and not "oh enter this other code...or also just use your phone to reset all access methods" (like some banks do, damn it).
• jiveturkey 8y ago
  social. 3 out of 7 pre nominated contacts. 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
• spullara 8y ago
  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.
• parliament32 8y ago
  NearlyFreeSpeech has a pretty comprehensive guide for how they handle 2FA resets, it might be worth a look: https://faq.nearlyfreespeech.net/section/login/losteverything#losteverything https://faq.nearlyfreespeech.net/section/login/losteverythin...
• Dowwie 8y ago
  How about a "Reset Buddy"? 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.
  • imhoguy 8y ago
    That is good approach for all invite-only and referal-based services.
• PeterisP 8y ago
  For valuable accounts, it may make sense to require physical contact in any "I've lost all credentials" scenario. 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.
• balladeer 8y ago
  As of now there’s not much you can do other than educating your users. 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.