|
|
|
|
|
by lkozloff
2139 days ago
|
|
Support Manager at GitLab here. We did use to do identity card verification. The issue that we had was that we often didn't have a lot of information about the folks who opened free accounts. Often names would be pseudonyms or match only partially with their ID. Not to mention, of course, the difficulty of verifying the authenticity of IDs from all over the world. We wrote about this back in 2018:
https://about.gitlab.com/blog/2018/10/08/enforcing-managing-... |
|
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.