You're absolutely right - SIM swapping is a major threat in many parts of the world. If you're a target and the attacker is determined, you could be in serious trouble. However, it's more cost-effective for bad guys to launch phishing campaigns using malicious proxies like Evilginx or Modlishka to target the masses.
Authentication is one thing. When it comes to banking - the authorization is the key (no pun intended ;)
Believe it or not, SMS is still one of the best ways to authorize sensitive transactions, even when compared to other popular options like TOTP or FIDO. The cool thing about SMS is that it gives you more context about what you're authorizing, so you're not blindly accepting requests from the bank without understanding what they're for. It's not perfect, but it's still pretty handy
> The private key is stored on your device, say on iOS it would be stored encrypted in the secure enclave and accessible via TouchID/FaceID.
What's important is that even though they are stored in the SE, they are no longer tied to the device and can be exported. Prior to the introduction of passkeys, all FIDO-based keys were minted inside the SE, without the option of being exported.
Seems like it :) but I would be more pragmatic and didn't bash the system for the reasons you brought up :)
ad 1 - IMO, it's still sufficient at scale with some basic infra. hardening
ad 2 - AFAIK the "secret" was never meant to protect from brute-force, but rather mitigate threats from actors controlling the email part
ad 3 - again, let's be more pragmatic - no one would use it if it required typing 13-letters OTP :) there are other ways to mitigate the potential attack you've described.
> You didn’t explain how this gives you any protection akin to a physical chip on a debit card…
In both cases you (an admin) control how many attempts you wish to accept before sacrificing the usability over security (temporarily disabling the card and forcing you to call the bank and disabling 6-digits OTP in favour of ie. 12-digits OTP).
Your real-world analogy is, this time, too simplified :) Let me counter-argument with my example:
You are in a a possession of 1 million user emails and request OTPs for all of them (let's assume no other security measures are in place). If you hit all of the 1M records with 3 attempts of OTP - according to my simple experiment - you might hit (on avg) 3.18 accounts.
Of course, in real life, your attack would be mitigated on other (non-application) level.
PS. When OTP size is increased to 7 digits - the avg account hit drops to 0.33. For 8 digits - it drops to 0.02. (please mind I'm using lousy RNG :)
PS2. What I'm trying to emphasize is that there's nothing wrong with OTP-auth like this if properly implemented with other basic anti-bruteforce techniques. You could get "better" results with simple password spraying.
You're over complicating this. In fact it might provide a similar kind of protection the physical chip provides for debit cards. Let me explain:
1. Someone (anyone) initiates the login flow
2. The user record in a DB gets enriched with
- the 6-digit OTP (sent via email)
- the "secret" (shared with the initiating browser)
- the current session failed attempts counter (default: 0, max: 3)
- the total failed attempts counter since last successful login (default: 0, max: 20)
Let's assume that you've initiated the session (hence own the "secret"), but have no access to the OTP - you will always have 3 attempts to guess the OTP before the session gets reset (a new "secret" + new OTP). So after the 3rd unsuccessful attempt you start from scratch. And at that point other means of protection might come into play based on the second counter (throttling the auth. requests on the WAF/fronting server, blacklisting IP addresses, etc.)
The number of accounts you're targeting does not matter - in fact it may help other systems mentioned catch your malicious attempts sooner.