Hacker News new | past | comments | ask | show | jobs | submit login

This is a fine example why nobody should rely on SMS "2FA" for anything.

SMS "2FA" is not actual 2FA

SS7/PSTN are horribly broken. People need to stop using them entirely, whenever possible, and stick to that as a firm principle. For the same reason why scam calls and fake caller ID are epidemic. Just disregard the existence of the PSTN, even if your phone has a DID, never give it to anyone or use it for anything. I say this as someone who's worked in telecom for 20 years.

Social engineering mobile phone operator customer service departments to execute a SIM swap attack is trivially easy if you already possess some basic personal info about the target.

You should never rely on having something important that's only protected behind a SMS-based password reset/login authentication module.




People love to say this, and while I agree with the general gist, there are a couple problems with this statement:

1. For large swaths of the population, hardware key-based 2FA or TOTP-based 2FA are too difficult to use, and they can also be more difficult to remediate if the user loses the hardware key or TOTP secret.

2. SMS 2FA is much better than nothing for most people. The bigger problem is when SMS can be used as just a single factor in account recovery scenarios.

3. There is a push to make telecoms more responsible for sim-swapping fraud: https://krebsonsecurity.com/2021/10/fcc-proposal-targets-sim...


> 1. For large swaths of the population, hardware key-based 2FA or TOTP-based 2FA are too difficult to use, and they can also be more difficult to remediate if the user loses the hardware key or TOTP secret.

This doesn't mean software providers should not offer the ability to use TOTP instead of SMS. This irritates me to no end when applications force me to establish MFA using SMS before I can also establish TOTP.


And sometimes no way to remove the sms ability to reset an account credentials for login even after totp is set up.


These same people who can’t handle pasting a 6 letter code from an app are also driving multi-ton vehicles on the freeway, one muscle twitch away from massive casualties. Scary. You don’t think that maybe they can learn?


I use Google Authenticator TOTP/HOTP. But when I first started using it, and was switching to a new phone, I learned the hard way that the keys had not been included in my backups. Sorting that out was a royal pain in the butt. Since then I have started ensuring that I have the keys backed up properly. But it’s one of those things that you might not realize until it happens. And it’s why even though I like to use it, I’d still be unlikely to recommend even to my family that they use proper 2FA instead of SMS based ones. Lest they end up permanently locked out of their accounts.


I switched to BitWarden for my ToTP needs and wouldn't go back. Having everything to hand, both on my phone and in my browser, saves so much time.

I keep BitWarden safe with a YubiKey.


Surprisingly it’s usually banking and investment company’s that require SMS based MFA. Including my main 401k brokerage.

In those cases I keep a google voice number. It’s also the same number I use to give to anyone/any company and it’s just on do not disturb 24/7. If I need to deal with a company on that number I just turn off DND. This practice of never giving out my actual number has drastically decreased the number of “car warranty” trash calls to my actual phone. They all go to that and generally a message is never left, and the phone doesn’t ring. Sometimes I get a voicemail of 3 seconds of dead air but that’s it.

I know a lot of people de-google but my thought is this isn’t a normal PSTN endpoint, and it’s not nearly as easy to sim swap, if not impossible but still works as a second factor. And I’m not aware of another service that can do it better and like it or not, google is a big target so I trust their auth over some other fly by night competitor.


My strategy for people that need to reach me by voice involves a one step IVR on my own asterisk system. This IVR is linked to a DID that I give out for this purpose. It answers and has a voice greeting prompt that says something like "press five zero zero to be connected". If someone does that, x500 initiates a new outbound call to my actual number, preserving the calling party's caller ID.

This cuts down on 99% of your car's extended warranty and IRS scam calls.


>If someone does that, x500 initiates a new outbound call to my actual number, preserving the calling party's caller ID.

Which provider allows this? Won't stir/shaken authentication requirements break it in a few years?


I am my own provider: incoming DIDs reside with a wholesale SIP trunking service. Outgoing SIP with the same provider, usually, though I have multiple possible routes. The asterisk system, I run myself. My outgoing caller ID (and my carrier's links to its upstreams such as bandwidth.com) are SHAKEN/STIR compliant.


This sounds fascinating and also completely over my head in terms of possibilities… is there a basic “getting started guide” you would recommend for someone who may not have the bandwidth to go all-in learning telephony from soup to bolts but would still like the benefits? :)


Wouldn't recommend it unless you do network/telecom stuff for a living, it has a bit of an ongoing time cost in maintenance...

some of the SIP trunking providers that have more focus on the consumer market such as voip.ms do let you define your own custom IVR and menus, to accomplish pretty much what I described, without having your own SIP-speaking system registered to it persistently. You should be able to define a voip.ms IVR destination as your cellphone.


Thinking about this a smidge, you probably can just use voip.ms to (a) order a DID (aka a phone number), (b) setup an IVR for the message, and (c) instruct them to dial an [internal to your account] extension that forwards to your real number, all on the voip.ms platform.

You wouldn't have to set anything up, just pay them for per-minute charge. You will have to pay 2x per minute, once for the inbound, and then outbound to your real number, ..... unless you go through the extra steps of setting up SIP phones.

FWIW; I've used voip.ms for a long time, and just a very happy customer. The biggest trouble they've had was availability issues a month or so ago when they were the victim of a DDoS :-/. You probably could pull off this trick with any of the pay as you go SIP trunking providers ...


How do the calls actually get routed to your phone? Via SIP, or through your cell provider (ie. it dials your phone's phone number)? If everything is over SIP, then it makes sense that everything is SHAKEN/STIR compliant.


at present I do it as the latter. My cellphone's direct number is an external destination on the asterisk system and it initiates a new outbound call to it, and bridges the audio/call from the incoming caller to it.

I can also do it direct over SIP if I want. The android linphone SIP softphone client is not bad. My cellphone can register to my asterisk system as the same extension as my SIP desk phone in my home office. Or if I want I can give it a new extension number and make my desk phone extension number, and the linphone softphone extension number part of the same ring group for me as a person. In which case I would send x500 from the IVR main menu to that ring group.

I generally don't leave linphone running and connected unless I'm actively using it because it can be a battery/CPU hog (in order to SIP register to my asterisk system I also need to be on my personal openvpn link, my server doesn't accept incoming connections from any public IP on the internet). So a combination of the openvpn client running and linphone simultaneously.


> at present I do it as the latter. My cellphone's direct number is an external destination on the asterisk system and it initiates a new outbound call to it, and bridges the audio/call from the incoming caller to it.

But under that scheme, would it still work SHAKEN/STIR? I would think not, because to your cell provider it's effectively indistinguishable from a bad guy spoofing caller ids. Or perhaps there's some forms or whatever you can fill out to get a certificate that allows a third party to spoof calls to you?


I called someone today and they appeared to be using a generic call screening service that offers exactly this feature - a computerized voice asks you to enter a random number to be connected.


I didn't even randomize mine, it's literally the same greeting every time and a fixed extension number. Just the fact that it exists as a roadblock to listen to, comprehend and put in some DTMF tones seems to stop 99% of the scam calls.


I'm guessing most scammers don't even hear your prompt. I have a simple, short, "leave a message <beeep>" prompt and the vast majority of my scam voicemails go:

0:00 - 0:10: silence

0:10 - hangup: "Hello? Hello?"


once stir/shaken is in place, won't the underlying problem go away?


I'm surprised this works for you. Every time I've tried to use my GV number for MFA it's rejected. It's easy for companies to check if a number is assigned to a "legitimate" mobile provider and if not, they just don't accept it.


Is has come up occasionally. But not for anything that’s been a show stopper. I think discord was the most recent, which I use totp for MFA anyway but they want some type of verification or something.


I don't think this is good advice. Your intuition about the vulnerabilities is mostly correct, but the absolutism here seems likely to lead to worse decisions, not better.

> SMS "2FA" is not actual 2FA

That's not correct. I mean, of course it is. If you have SMS authentication as one factor and a password as the other, you're safe from compromise even if the carrier hands your phone number over to someone else. That's the whole idea behind 2FA, and it works here. A "SIM swap attack" is, contra the article and your points, not sufficient to compromise a working 2FA environment.

You need something else, like a crypto wallet system that uses SMS as a single factor, which seems plausibly to have been the case here.

> Social engineering mobile phone operator customer service departments to execute a SIM swap attack is trivially easy

True, but that's a hole in that one system that can be patched, and it's not something specific to the PSTN network at all (literally everything can be human engineered, including the customer service departments of authentication providers like Google/MS/Apple!). For example, require physical mail as a second (third) factor as an authentication mechanism and the whole problem goes away. This is already implemented for e.g. address changes, and it works fine.

Don't take a specific hole in one system as evidence that the system needs to be replaced or redesigned. That's generally a recipe for creating new security bugs, not fixing them.


NFC cards is obviously best way to do u2f yet Apple completely ignores it in their laptops..?

Why?

Also, do banks carry any liability if you are sim swapped? If so - wonder if the banks can get scammed that way instead?


How much does SIM-locking (i.e. adding a PIN to lock it) mitigate the risk in your experience? I understand that if the telecom service dept. is compromised it's useless, But in a low-effort social engineering attack are the telecom personal trained to suspect the lack of PIN?

Phone numbers are like social security number or at least a parallel identity where I live, Banking to vaccine happens through 2FA auth(Often only through it). Recently banks have started to advise SIM-locking to prevent SIM jacking; My cries to support hardware tokens have been in vain so far.

What's funny is SIM-locking was quite common during pre-smartphone era, I think the Nokias of those time even asked for a SIM-PIN with each reboot; Even then the customer service would just reset it when you said you forgot it. I don't think it would be any different now, after-all they just ask your name & address to confirm identity.

It feels like SMS based 2FA + Oligopoly Telecoms are a disaster waiting to happen.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: