Allowing customer service to bypass customer auth requirements is just weakening your system. There will always be a CS agent who is bribed, makes a mistake, etc. And besides, the agent following a flow chart has no better info to make the decision on than a computer.
Instead the auth requirements should be sane from the start, well publicised, and make a good tradeoff between letting bad guys in vs locking the real owner out.
There should be options beforehand to adjust the balance (eg. enabling 2FA).
To prevent lockouts, there should be some time-based weakening. Eg. if you are trying to access your account, and know only some of the required auth info, and have been unable to for 1 week, and, after blasting messages to every associated recovery phone/email address nobody else does either, then you should be allowed in.
That solves the classic "my house burnt down with my phone in. All I have is my email and password, but I have no devices left, no backup codes, no access to my phone number, nothing" case.
In this particular case I feel like it's a bug that backup codes are not treated as secure as 2fa codes, and that I need explicitly a 2fa code to disable 2fa is just broken (in my specific case)
Right? Backup codes should be considered the most secure overrides for the other resources. What's the point of them being "backup" codes if you'll need something other than the backup for a break-glass event?
> Allowing customer service to bypass customer auth requirements is just weakening your system. There will always be a CS agent who is bribed, makes a mistake, etc. And besides, the agent following a flow chart has no better info to make the decision on than a computer.
This is true, but OTOH there will _always_ be edge case scenarios that no one anticipates until they actually happen. Or maybe someone did anticipate, but they were drowned out by the other voices in the room saying "that can't/won't happen," so it wasn't included in the requirements. What happens when a customer encounters a problem that doesn't fit neatly into one of the user journeys that the product team planned out? Are they just shit out of luck?
> Allowing customer service to bypass customer auth requirements is just weakening your system
I disagree, in regulated industries such as banking this is a solved problem. A combination of onshore staff, good career prospects, pay and working conditions and audit logs means I haven't heard stories of bank insiders breaching into accounts to steal. I'm sure it happened but nowhere near as frequently as fraudulent SIM swaps for example.
TLDR: don't outsource your customer service to the third world and you're already 80% of the way there.
I suspect that the level and sophistication of attacks on the banking sector is far lower than equivalent attacks for data/accounts.
In general, if you break into someones bank account and transfer money out, that money can be traced by authorities. In almost all cases, that money is recoverable by the government, even if individual banks like to shrug and tell the customer it isn't recoverable.
If you break into someone's email and steal their private info, it can't be traced. That makes the latter much more attractive.
Instead the auth requirements should be sane from the start, well publicised, and make a good tradeoff between letting bad guys in vs locking the real owner out.
There should be options beforehand to adjust the balance (eg. enabling 2FA).
To prevent lockouts, there should be some time-based weakening. Eg. if you are trying to access your account, and know only some of the required auth info, and have been unable to for 1 week, and, after blasting messages to every associated recovery phone/email address nobody else does either, then you should be allowed in.
That solves the classic "my house burnt down with my phone in. All I have is my email and password, but I have no devices left, no backup codes, no access to my phone number, nothing" case.