Ask HN: What is a secure way to allow 2FA resets?
26 comments
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.
(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.
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-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.
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-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.
> 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.
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.
>D. Reset via email is the most commonly used one. It's scalable, unlike manual review. Less secure, arguably.
What's the argument that it's not any less secure? That seems like a pretty obvious conclusion to me.
What's the argument that it's not any less secure? That seems like a pretty obvious conclusion to me.
Password reuse and 2FA enforcement.
Although, we at HN are the shining tier of amazingness (/s), most people will use the same password across as many accounts as they can, or use some dirivation of the password.
The bigger issue is that plenty of people don't enable 2FA onto their emails as it's never really suggested by the providers, some just don't support it, and the fear of getting locked out of something so central.
It's better than SMS 2nd Factor though.
Although, we at HN are the shining tier of amazingness (/s), most people will use the same password across as many accounts as they can, or use some dirivation of the password.
The bigger issue is that plenty of people don't enable 2FA onto their emails as it's never really suggested by the providers, some just don't support it, and the fear of getting locked out of something so central.
It's better than SMS 2nd Factor though.
Gmail at least (sort of) pushes 2fa with their 'security reviews'.
GitHub has 16 recovery keys which you can print in advance, and use if you don't have your authentication device at hand. They are also retrievable from the account's security page at any time.
https://help.github.com/articles/configuring-two-factor-auth...
https://help.github.com/articles/configuring-two-factor-auth...
They'll also reset it if you have the ssh private key for one of the public keys you've registered on the site
doesn’t work / N/A for the OP. recovery keys require the user to do something in advance of reset. his users won’t do that.
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.
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.
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).
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).
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.
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.
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.
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.
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.
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.
> 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.
Please don't do this. There are people who move often to not have their current address on their photo id.
For a business setting, that's a red flag for KYC, but for a B2C app, that's a very legitimate concern. If I were in that position, I'd probably just insist on seeing some proof that I can tie to the payment method, because otherwise how do I know you're John Smith from 123 Residential St, or John "the crook" Smith from the bad side of town? Bank statement, photo ID, etc.
Remember that this process needs to be painful. You already screwed up by losing your 2FA. It sucks, but if it doesn't, then it defeats the point of having that 2FA in the first place.
Remember that this process needs to be painful. You already screwed up by losing your 2FA. It sucks, but if it doesn't, then it defeats the point of having that 2FA in the first place.
Photo ID is not used for authenticating that the person lives at the address. That's why voting registration or driver's license requires proof of residency [1]:
> A few examples of acceptable documents to prove California residency are:
> Rental or lease agreement with the signature of the owner/landlord and the tenant/resident
> Deed or title to residential real property
> Mortgage bill
> Home utility bills (including cellular phone)
> Medical documents
> Employee documents
[1] https://www.dmv.ca.gov/portal/dmv/detail/pubs/newsrel/newsre...
> A few examples of acceptable documents to prove California residency are:
> Rental or lease agreement with the signature of the owner/landlord and the tenant/resident
> Deed or title to residential real property
> Mortgage bill
> Home utility bills (including cellular phone)
> Medical documents
> Employee documents
[1] https://www.dmv.ca.gov/portal/dmv/detail/pubs/newsrel/newsre...
I've never understood why these documents are meaningful in any way. The people at the DMV aren't qualified to judge whether these documents are forgeries, and certainly not in the ~5 seconds they spend looking at them. Anyone with a printer and Microsoft Paint can produce one of these in two minutes.
When I was getting my state ID, I wasn't prepared to have proof of residency, so I ended up downloading a bank statement from my mobile banking app, and presented the corner with my address & name on it to the clerk. I also wouldn't put much trust into the address information on IDs.
Another example is WA state DoL, which does not automatically reissue (nor require) a new license when you update your address.
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.
California drivers licenses are not reissued when you update your address [1].
> A new driver license, identification card or registration card is not issued when changing your address.
[1] https://www.dmv.ca.gov/portal/dmv/detail/online/coa/welcome
> A new driver license, identification card or registration card is not issued when changing your address.
[1] https://www.dmv.ca.gov/portal/dmv/detail/online/coa/welcome
Which is the correct answer, thank you. It does need to be painful otherwise it has no value. but it needs to be fair, for example I moved home a year ago with my now wife. Hireright needed utility bills in my name, but she pays them and I pay the mortgage. This caused a lot of stress. I swear a load of these gatekeepers have never tested or thought about this process.
Or they could have used a billing address different from where they live to start with.
True.
I'd argue that trumps all other control over the account. If you can show that you control the payment method, then I'll accept you as the legitimate controller of the account. So, notarized, translated, and apostilled letter from the bank branch manager stating that you are the person in control of the account, sent by certified mail with signature delivery and I'll send you back a link to type in manually the same way.
As a shortcut, I'd say it's mostly safe to accept a picture of someone's face holding up their photo ID with the same billing address.
Or confirming the amount and/or origin (some banks/credit systems do not display the merchant name for some halfbrained reason) of a small transaction (e.g. 1.37 USD from merchant account ACMECORP-294817) that is refunded after a week.
I'd argue that trumps all other control over the account. If you can show that you control the payment method, then I'll accept you as the legitimate controller of the account. So, notarized, translated, and apostilled letter from the bank branch manager stating that you are the person in control of the account, sent by certified mail with signature delivery and I'll send you back a link to type in manually the same way.
As a shortcut, I'd say it's mostly safe to accept a picture of someone's face holding up their photo ID with the same billing address.
Or confirming the amount and/or origin (some banks/credit systems do not display the merchant name for some halfbrained reason) of a small transaction (e.g. 1.37 USD from merchant account ACMECORP-294817) that is refunded after a week.
Also, some countries don’t issue photo IDs with an address.
A service I use requires me to resubmit my identification every year. Interestingly they do not allow scanned images. It must be a photo of the credential.
In another thread here users reported success in sending Facebook IDs that have been photoshopped.
We first all need to agree on how we will authenticate government IDs before we can trust them.
In another thread here users reported success in sending Facebook IDs that have been photoshopped.
We first all need to agree on how we will authenticate government IDs before we can trust them.
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.
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.
> 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.
That defeats the whole point of 2FA.
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.
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>.
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>.
> 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).
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).
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.
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.
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.
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.
>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.
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.
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.
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.
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.
There is no staying out of the weeds when it comes to security. The weeds are where the threats hide.
We all better get a cabin in the wood then ;)
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.
Still vulnerable to a "I know this user is on vacation for a week" attacks, but it's fairly effective.
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.
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.
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.
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.
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.
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.
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).
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).
With a PM you're trusting that the PM is:
a) Trustworthy
b) Secure
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.
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.
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.
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.
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?
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?
I believe Persona is the project you are thinking of:
https://en.wikipedia.org/wiki/Mozilla_Persona
Yes, thank you.
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.
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.
> 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 :)
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 :)
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.
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.
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.
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.
That is good approach for all invite-only and referal-based services.
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?
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.
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.
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.
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.
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.
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.
If their app is team based, they should be deferring 2FA to the IdP that that team should already have.
[deleted]
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.
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.
NearlyFreeSpeech has a pretty comprehensive guide for how they handle 2FA resets, it might be worth a look: https://faq.nearlyfreespeech.net/section/login/losteverythin...
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.
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.
What happens when a user loses their FIDO key?
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".
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".
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.
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
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
Thanks!