Yes, SIM-jacking is a real threat, but it still requires directed effort on the part of the attacker. It can’t be done en-masse.
I think the author also fails to mention techniques for detecting account hijacking - Facebook and google for example both look at IP addresses and user agent strings, probably along with other factors, to detect unusual account activity.
It's not about the user, it's about the attacker. If your account has something worth bothering with, SMS 2FA is a way for an attacker to tell support "yes, I own the phone number, I just forgot the password", which gets the account transferred to the attacker more easily. It's a tradeoff between that and a keylogger meaning game over, but, really, how hard is it to implement TOTP?
> I think the author also fails to mention techniques for detecting account hijacking - Facebook and google for example both look at IP addresses and user agent strings, probably along with other factors, to detect unusual account activity.
That's a very good point, but those are more high-effort functions and only allow detection after the fact, rather than prevention. They're definitely great to have, but I wanted to show two simple features that can help your users' security greatly while being easy to implement.
It’s still not great - U2F is the way to go in my opinion - but good luck getting my dad to use any of that stuff.
That's exactly the reason for the "poor process", most users have trouble with these things and it's not uncommon for people to say "the email address I signed up with is old and I don't have it any more, but I do have my phone number". So common that support can't just ignore those, unfortunately, which is how attackers get in.
That, and support staff are people and sometimes just want to help users, even though you've said "absolutely no password resets without email verification".
I’m not saying doing this properly is easy, but I think “don’t use SMS ever” is a bit extreme.
Another way is to charge a fee for last-resort password resets. Charge $10.00 to the user's credit card, if the account info matches, and refund $5.00 in two random small amounts for them to retrieve off their online account statement and report those numbers back to you.
That said, I wonder if it would be useful to encourage more usage of Notaries for ID verification in such matters. There's no easy digital API to request a notary's involvement (yet?), and there are complications between states/countries in what powers/abilities/checks/balances notaries have. But it is an ancient business practice to ask "please get this form notarized with valid ID", so why not just update that for contemporary needs?
I've been asking BofA and Merrill for awhile. Apparently for the institutions that control my money, "very."
Here is an open source Java example of some of the algorithm impl, and an HTML / JS example to test out in the browsers.
https://github.com/inversoft/prime-two-factor/blob/master/sr... https://github.com/inversoft/prime-two-factor/tree/master/we...
I think what you are talking about is "SMS password reset", which is a different beast. And it also sounds like you are talking about SMS based identity verification for customer service representatives. If you are only using SMS for identity verification in your CSR workflow, that is a broken workflow.
In FusionAuth (https://fusionauth.io), we implemented SMS MFA that only works after the user has successfully put in their password. Therefore, the attacker would need their password and a clone of their phone. While this is still possible, the threat surface is quite small.
You MUST ensure that ALL involved parties are aware that the secondary measure is a 'bonus' and CANNOT be used to consider the entire system safe.
For example, let's say someone calls the helpdesk and says: I forgot my password, but, I can answer the 2FA thing for you. Maybe the helpdesk operator makes a reasonable judgement here: That's pretty good, the party on the other end of the line sounds pretty convincing, okay, I'll reset their password for them. Whoops: Now JUST a SIM jack gets you in, whereas if there was no SIM based 2FA whatsoever, the helpdesker wouldn't have reset the password.
Another example: During a security audit, some pentester figures out that there is no rate limit on trying passwords, there are no logs or any other detection for figuring out that some system is trying a ton of passwords, and a password check is very fast (let's say no bcrypt or similar system in place either) and the server is hosted in a virtual datacenter, and it is not too difficult to spool up a (virtual) server in the same place: That would allow an attacker (because latency has now been reduced to next to nothing) to have guessed many billions of passwords over the past 6 months. The team analyses this potential leak and concludes that, due to the existence of the secondary system, there's really no need to go public or otherwise spend any further resources. However, you don't even need to be all that capable or motivated to do a targeted attack here; SIM jacking is easy enough, and getting a server under your control that is latency-wise extremely close to the target is pretty easy for, say, AWS ec2 servers. Had the 2FA not been there, this issue would have received more appropriate attention.
Generally, I advise to never add a security feature just because 'hey, can't hurt': It confuses the authentication pipeline and muddies discussion and understanding. Either a feature is adding real security, and any circumvention of said security is definitely something that should be escalated, or, it's useless and should not be added.
With that mindset, I'd prefer to just get rid of SMS based 2FA vs. keeping it around (I'd _strongly_ prefer to fix it and make it 2FA that isn't sim-jackable, for example by using TOTP protocol, but let's hypothetically posit that that's somehow not an option).
Example 1: at a first approximation, 100% people have their phones set to display the content of SMS messages even if the phone is locked. So gaining the physical possession of a phone (even for a brief time) allows the attacker to gain access.
Example 2: taking out a SIM from a modern phone takes less than 10 seconds. Again, at a first approximation, 100% people have no PIN on their SIM cards. The card can be inserted into another phone and used to gain access immediately. Note that while you might notice that your phone is missing, you might not immediately notice that your SIM is missing.
I'm not even considering other (more complex) ways of redirecting SMS messages.
And what I hate most are services which allow you to use SMS or a phone number to recover/unblock your account. That makes it so much easier for attackers go gain access. The only way to recover your account should be with recovery codes. If you lose those, there should be no way to recover.