[tgsovlerkhgsel]

I suspect that support cost also played into the decision.

Consider requiring payment: It covers your support costs, and provides some ties to a real-world identity as well as rate limiting/imposing a real cost on attackers.

For credit cards, AFAIK you can set which security level to apply (i.e. whether you'd rather have a higher fraud risk or more shopping cart abandonement because the customer didn't have/want to deal with whatever auth the bank requires at the highest security level). I imagine cranking this to the max would reduce the risk of stolen cards significantly.

I'd imagine requiring

- identity verification (even if you can't link it to the account, it will deter attackers) through a third party provider - payment (both to cover the cost and as a second form of verification/audit trail generation) - inactivity of the account - contacting and warning the user for a week - requiring the user to confirm a confirmation link at the beginning and end (i.e. an attacker would need control of the user's e-mail)

would strike a good balance. If you don't want human judgement in the loop on your side, it can also be completely automated if the ID check is done by a third party.

If there is no way to recover, it creates a perverse incentive to not use 2FA in the first place.

[whatl3y]

> I suspect that support cost also played into the decision.

I respect this if it’s the case, but just say it, don’t hide behind a “best practice” security blanket when your true motive includes other factors.

> If there is no way to recover, it creates a perverse incentive to not use 2FA in the first place.

Agree. The user has to now perform a cost benefit analysis in her head to determine if she’ll use MFA with the most punitive risk being she loses access to her account forever.