11–20 of 76 posts
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.
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 attac…
> 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.
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 attac…
> 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.
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.
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 attac…
> 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.
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.
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.
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 locatio…
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.
Earlier quoted context omitted.
> 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.
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.
Earlier quoted context omitted.
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.
Or they could have used a billing address different from where they live to start with.
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.
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…
That defeats the whole point of 2FA.