Re:Gitlab Support is no longer processing MFA resets for fre...
by whatl3y on Wednesday August 05, 2020 @06:47AM
(#24059274)
> 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.
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.