Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Is this worldwide or US?

Worldwide. SMS is just like e-mail, you can put anything you want in the sender field. You should absolutely not trust SMS.



Actually, I trust e-mail more than SMS. With e-mail at least you can look at the headers and if you know which part you can trust you can verify where it came from. With SMS there is no such possibility.


Any idea on the extra security measures? In Turkey for example, when you change your SIM card the 2FA from the banks will stop working and you need to call your bank to re-activate it. That of course seems like a measure to prevent SIM cloning but maybe there are some security protections against spoofing. In many places SMS is a popular way to do payments and 2FA for high security applications.


Carriers can indeed expose APIs for banks and other third-parties to check if a SIM has recently been reissued, but that's a separate problem from spoofing.


Where does SMS get used to do payments? (...and how?)

SMS for 2FA is known to be a very bad idea, and some security experts have been shouting about the need to stop doing that for a while.

I also can't see any country managing to implement more restrictions on SMS without either breaking a lot of "legitimate" sources of SMS or being ineffective outside of a very narrow window (e.g. only blocking forged SMS for numbers originating within one country)


"Where?!" Everywhere. It's being phased out in many places, but as a rule of thumb, mostly everywhere still.

"known to be very bad ... been shouting ..." Right, yeah, to put it in some perspective remember that you're talking second factor here. This is not your login, this is a secondary confirmation and you still need some serious motivation to bypass it. It's definitely doable, I work in security and I know what kind of attacks you're thinking of, but it's not the opportunistic kind of thing that a common thief will do without technical research and planning it out. If you know how to do it, you can probably find better jobs than this. It also doesn't scale well because you can only use it on people whose bank login you've already cracked in the first place.


I'd never seen or heard of it being used for payments before, which is why I asked - I'd heard of phone numbers being used as account names (effectively) in some payment systems, but being involved in the workflow of making payments is entirely novel to me.

I'm aware it's not your login, but it feels the same as asking someone for publicly searchable information to "verify your identity" - an additional "security" step that doesn't actually slow down any attacker more dedicated than a passing whim, but makes people feel good about whoever is using it, when there are better options that don't have the problems of SMS.

Yes, it doesn't scale well to bulk attacking, but most of my interactions are with people who take reasonable precautions like keeping their machines patched, not installing random crap from the internet, and generally avoiding other fun ways people get swept up in low-hanging fruit campaigns.

SMS 2FA is better than no 2FA at all, it's just frustrating to watch many companies deploy it and go home when there are better options, some of which solely also require a phone.

edited to correct my statement: I originally said "SMS 2FA is better than no 2FA at all in a number of cases", but no, I'm pretty confident it's strictly better, even with all my laments about it.


What better options are there that have approximately the same ease of use?

SMS works with every conceivable phone, even most landlines if need be, users don't have to install a separate authenticator app, which may require a Google/iCloud password (now where did I put that post-it note?), that takes up space that may be scarce on low-end phones and that may not even be compatible with very old phones, leaving affected people in a really unsatisfactory spot.

Then they need to set up codes for every login, figure out how to switch back and forth between apps and how to copy codes, which is not very discoverable at least in Google Authenticator – most people seem to memorize and type instead, cumbersome.

Hardware tokens are even worse, people misplace those a lot and unless you are a bank with a mature process for issuing these, setup is probably even more of a hassle.

All of this may be big deal if you (also) target less technical people and want them to use your product when they have the option not to.

With SMS, all the user needs is a phone number. Pretty much everyone is familiar with that, most will readily share it, too. iOS will even extract codes and show them on top of the keyboard, just wait a second or two and tap the code, done. It's about as painless and frictionless as it can reasonably be, with apparently relatively inconsequential security drawbacks – given it's supposedly trivial to fake SMS, there don't seem to be a lot of people doing so at scale. Maybe a breach like this one will finally change that? Remains to be seen.

For now I can totally see why one might stick with SMS as a second factor.


> users don't have to install a separate authenticator app, which may require a Google/iCloud password

If they wish to use Apple then that is their own choice, but on Android it's quite trivial to download Red Hat's open source authenticator app[1] from f-droid (the website, you don't even have to install the store if you don't want that). It's quite bare bones on graphics and features, doing only what you need it to (the f-droid build is 0.5MB, frankly still large for what it does but consider that it's like half of a single photo).

And if people don't have a phone with support for apps, then you can still fall back to SMS. Doesn't mean you need to force everyone down to that level.

Fun fact: my grandpa can't use SMS either, your solution is not as universal as you make it seem. He never has been able to due to sight issues (it's not an age thing, though it doesn't help if you're close to illiterate and now need to start to learn how to use solutions for sight-impaired people due to this information age having onset). Does that mean we cannot support anything better than sending a letter, which is accessible to him as well? Can't we have the better solution as well as the accessible one?

[1] https://f-droid.org/en/packages/org.fedorahosted.freeotp/

> With SMS, all the user needs is a phone number.

No no, you got that backwards. All Facebook needs is your phone number, or whoever it is that pinky promises to only use your phone number for security. I get what you're saying about everyone having a phone number that you can identify them by, but that is also the issue: everyone has typically a very very limited amount of phone numbers (and typically linked to a government ID) whereas a throwaway email is easy to make and each TOTP code is throwaway by design. I think there's something to say for supporting this.


> If they wish to use Apple then that is their own choice, but on Android it's quite trivial to download Red Hat's open source authenticator app[1] from f-droid (the website, you don't even have to install the store if you don't want that).

That's even less intuitive than using the default app store. That's a whole new slew of concepts you need to grok (you can download an app from the web and install it without an app store; what is this fdroid thing? is this a virus? what do these dialogs mean?), plus training people to do this without also giving them the knowledge when and why this is safe isn't exactly helpful, but that's a lot to ask from a simple sign-up flow for a hypothetical niche app built by a hypothetical two-person team.

> And if people don't have a phone with support for apps, then you can still fall back to SMS.

You can, but that adds to the complexity and support burden and probably also costs you users due to sign up friction.

> Fun fact: my grandpa can't use SMS either, your solution is not as universal as you make it seem. He never has been able to due to sight issues (it's not an age thing, though it doesn't help if you're close to illiterate and now need to start to learn how to use solutions for sight-impaired people due to this information age having onset).

That's an interesting case. I'd like to think there would be a fallback for people like him, but I guess, in the vast majority of cases, he'd just be left out. The current state of inclusivity in tech is abysmal, though I've seen vision-impaired and deaf people get around their devices surprisingly well; it's still an embarrassment that this industry won't do better. It's hard to get this right when it should be hard to break this, but current frameworks and paradigms don't prioritize this. It's shameful IMO.

I do think SMS is a lot more accessible than authenticator apps and the like, even though that still will not work for everyone.

> Can't we have the better solution as well as the accessible one?

I'm not saying you can't or shouldn't offer the best solution you can. By all means give me Yubikey support and several fallbacks. But I can see quite well how not everyone might want or be able to.

> No no, you got that backwards. All Facebook needs is your phone number, or whoever it is that pinky promises to only use your phone number for security.

Facebook definitely should get rid of SMS factors. If anyone has the resources to do much better, it would be them and the other giants. Not sure how they handle that, though. They'd still collect phone numbers in any case, but they'd happily image people's internal organs if they could, so that is a separate issue.

Apart from that people seem to be quite happy to use their phone number for signup if it makes signup quicker and less annoying. Even if the primary flow is email and alternatives are hidden in another tab, phone number still tends to get used a lot, in my limited experience. Same with Facebook/Google login.

Plus, for most people ai guess it isn't as black and white; in quite a few cases I've given my phone number even if signing up via email, because it helps a lot if people can just call me in case of issues (e.g. the restaurant is out of my extra topping).

That said, I'm all for offering as much choice as possible, and I'm not happy with the inflationary use of phone numbers as the only way to sign up, and I'm all for Yubikey support in every app, and it's disappointing that OS/browser vendors don't make this easier and more convenient, and if anyone wants to let me have as many anonymous phone numbers as I need, I'm very interested.

But, still, I can totally see why a resource-strapped product/dev team might come to the conclusion that SMS second factors are sufficient for now.


> it's just frustrating to watch many companies deploy it and go home when there are better options

I do agree with you there. To be clear, while I think the problem is of a smaller magnitude, I do agree with your general point. Other alternatives like very simple TOTP tokens additionally don't require a phone number and so you don't have this stupid "add your phone number now, we'll use it only for security, pinky swear!" prompts.

Heck, there could even be an argument that SMS OTP is now illegal with GDPR unless the user gives explicit consent. You can't use user data (PII) if it's not with consent, for a legitimate purpose, to fulfill a contract, for the user's own good, to comply with law enforcement, and I'm probably forgetting one or two reasons. Now that it's clear that stuff like TOTP is a better alternative, there is no reason to process people's phone number anymore for this purpose, making it impossible for you to send that SMS OTP. (Of course, you'd have to convince a judge that TOTP is better than SMS before we actually get case law on this specific use of a phone number so... *mumbles something about nine-tenths of the law*.)


> Where does SMS get used to do payments? (...and how?)

Look up M-Pesa[1]. Which is a hugely successful, mobile phone based payment system in multiple countries.

In Kenya alone, where it started, it had 17Million subscribers. In 2011, that was.

[1] https://en.wikipedia.org/wiki/M-Pesa


> Where does SMS get used to do payments? (...and how?)

In India, for every card transaction, for every DMAT transaction, for every password/PIN change SMS is used as 2FA. It is also mandated to require SMS 2FA for every one of these cases.

If my bank has any means to use TOTP/Yubikey, it is absolutely not made obvious, led alone clear or even possible.


Okay, so SMS gets used as 2FA for all those things, not somehow a primary method of creating transactions, correct?

Unfortunately, quickly looking, [1] suggests at least one of the listed services for sending arbitrarily forged SMS messages explicitly works in India, so it seems like this is still true for you. :(

[1] - https://www.usethistip.com/5-websites-to-send-anonymous-or-f...


Are there Android apps for that?


I'm absolutely no expert on this, but I think your provider would usually filter this spoofing attempt out, just like with IP spoofing. But if you're in the right spot in the network (e.g. your provider doesn't check for spoofing or you're your own "provider") you can do whatever you want.

Another problem with Android could be that the operating system might not have enough control over the SIM-Card/Modem to spoof phone numbers.

I have heard about people using some services to send/call from spoofed numbers though


Hushsms is one, but requires Xposed Framework.


Does that let you spoof sender address on any phone? I was under the impression that you had to create an account with a SIP provide to do that.

(Btw a Google search for "Hushsms" results in shady/cancerous app stores that all seem to mirror each other. Where is the official website/thread?)


I'm pretty sure Italy requires a company to register to an official list before being able to put a personalized sender ID in your SMS communications. I'm not sure about the inner workings but seems far from "whatever you want".

I kinda assumed this was a widespread modus operandi, apparently it's not?




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

Search: