SMS 2FA is not just insecure, it's also hostile to mountain people

> Interesting, I was under the impression that SMS over IMS was implemented transparently to external senders. But given what a hack the entire protocol is, I'm not really surprised.

I can probably illuminate some things here. This is almost certainly the SMS API they're using. Your phone, and your network by extension, does not care if the phone is technically online - so those messages get received because they're literally sending in the blind (and if the recipient is offline, the message gets temporarily stored by the receiving carrier for around 3-7 days before it is discarded).

These SMS OTP systems validate "reachability" (using APIs like https://developer.vonage.com/en/number-insight/technical-det... and https://www.twilio.com/docs/lookup/v2-api/line-status) and will not send a message if a number is 'not' reachable. Unfortunately, as implied by the air quotes, these methods are not infallible. This is done to reduce the costs of sending the message (carriers charge a lot more for commercial customers) but this is definitely stupid for a already-validated number like in this case.

>>> I really wish that were illegal. A phone number is a phone number.

European speaking. For completeness:

Financial directive PSD2[1] allows to use an SMS as a 2FA only because there is an KYC already done for that number (anon SIM are no longer allowed in the EU)

Also note that the 2FA is not the OTP code you receive. This code is just a proxy for probing "something you have", with the "something" being the phone number which, again, is linked to a physical person/company.

I have commented this several times, but as of today, SMS is the only 2FA method that can be easily deployed at scale (all demographics, all locations, compatible with all mobile devices)

[1] https://en.wikipedia.org/wiki/Payment_Services_Directive

It really is absurd that the same companies that won’t allow 2FA with any other method outside of SMS are the same ones not sending to VoIP. Maybe they all go through a service for SMS that blocks it, but it still upsets me.

It’s insane to me that maybe every bank I use requires SMS 2FA, but random services I use support apps.

  {
    "data": {
      "name": "LASTNAME, FIRSTNAME",
      "line_provider": "Google/Bandwidth.com (SVR)",
      "carrier": "Bandwidth.com",
      "line_type": "landline"
    }
  }

Phone numbers are used like this because in the Year of our Lord 2025, they’re the best way to semi-solve the Sybil problem even somewhat without having to literally do some kind of KYC

>>> she turned on wifi calling on her phone. now she could receive SMS messages from friends and family, but 2FA codes still weren't coming through.

Completely different beasts. One is P2P, the other is A2P

I use Wi-Fi calling on a phone only for 2FA SMS. Never had a problem with it. It was RedPocket (MVNO) with T-Mobile. Annual plan of 200MB, only a few dollars a month. No T-Mobile service here* so only SMS over Wi-Fi works. Only ever used for SMS 2FA.

*The bands acquired with the Sprint merger have service, but the cheap used phone I bought was pre-Sprint-merger and lacked those bands.

"port her cellphone number to a VOIP provider that does support receiving SMS from shortcodes over wifi"

...

"... unless the company she's dealing with is one of those that don't send SMS-OTP codes to VoIP numbers for seCuRiTy reasons ..."

Correct.

This is, in fact, a terrible idea because even if you do find a VOIP provider that can receive SMS from "short codes" (the weird little numbers your bank sends codes from) that is a temporary oversight and will get "fixed" eventually.

Remember:

None of this is for your security or to help you. All of these measures are just sand in the gears to slow down the relentless onslaught of scam/spam traffic.

Your bona fide mobile phone number is a "proof of work" that these providers are relying on in absence of any real solution to this problem.

If you port your cell number to a VOIP carrier, I don’t think senders have any way of telling that it’s not still a regular cell number?

I have such a ported number and have no issues receiving SMS 2FA codes.

> That's generally a great solution – unless the company she's dealing with is one of those that don't send SMS-OTP codes to VoIP numbers for seCuRiTy reasons, or demand that the number is somehow "registered in her name" (which many smaller carriers apparently don't do). I really wish that were illegal. A phone number is a phone number.

It pisses me off to no end. I use a few different banks and some are fine with google voice, others are not. One only allows customer service to send SMS tokens to google voice but not through the regular flow. In all but one case, they will happily robo call my google voice number and have a tts engine read me the same code that they didn’t want to SMS.

Security policy by rng, ffs!

The problem isn't discrimination of SMS number types, it's SMS itself should be illegal, period.

It seems t-Mobile no longer offers such hardware: https://www.t-mobile.com/support/coverage/4g-lte-cellspot-se...

> She just needs a microcell/femtocell.

Those come with their own set of problems. In particular, they have to be able to receive a GPS signal, which is often not possible in mountainous terrain. I had a microcell for years and it was nightmarishly unreliable. Not only would it regularly (but randomly) just stop working, it would give absolutely no indication of why it was not working.

I have a 4G LTE Network Extender provided free by Verizon. My only issue is calls drop as I leave my property.

I called 911 in January and gave my address before the call dropped as I moved my car from my driveway to the street. The 911 operator called me back once I was back in range.

A few months later Verizon asked me to edit the location data with my address. Hopefully, I won't need to test anytime soon.

I'm surprised the major cell providers are cool with letting randos operate cell towers that back into an unknown untrusted ISP and their customers will automatically switch to when in range. It's unbelievably chill for companies that are usually so concerned about their image and controlling the whole experience end to end.

"When I am roaming internationally, I leave my SIM card in a spare android at home plugged into a charger. Android has an app that forwards SMS to API ..."

This is called a "2FA Mule":

https://kozubik.com/items/2famule/

I have done this for 4+ years now and it works wonderfully. Good for you!

If your phone supports WiFi calling and dual SIM, you can get a data-only eSIM for the country you're visiting and you'll receive texts for your primary line over the data connection of the secondary eSIM.

I did something similar where I left an old Android phone at home and logged in to what I think used to be messages.android.com (now google.com) from a laptop praying the session wouldn't get lost before I got back from my trip. :)

Lately though, SMS works over WiFi calling and usually if I need a real SMS where Google Voice won't cut it, it can wait for WiFi...

Looks like this might stop working soon unless this process works without logging into the phone: https://mashable.com/article/android-smartphones-automatical...

I’m sorry how is this related to roaming?

I roam all the time in Europe and have roamed a lot outside of it, I have never had any trouble receiving any SMS?

I have been living outside the United States for twelve years.

I always had problems with SMS until I got Google Fi. And that's a problem because, as the article here says, many banks insist on SMS these days. There are various services that give you a virtual number. But they always suffer from one of two problems: (1) VOIP numbers are 'blacklisted' by some banks for security reasons: they want a real cell phone number (2) I simply don't get SMSs in some cases some technical reason

Google Fi works everywhere. Even when there is no cell phone service: it will tunnel over WiFi.

Google shuts off the data on Fi after you've been outside the USA for a month. No problem, I'm happy to pay $25 a month for a 'dataless' connection that gives me SMS and voice.

Are you able to use rcs and "messages for web"?

The last time I checked if you wanted "cellphone is off" texting/voice (basically the old hangouts), you had to enable "fi syncing" which disabled rcs features. Is that still true? What url do you goto to do texts/voice? (i see hangouts.google.com redirects to google chat).

Reminds me of DHL parcel lockers in Germany. The new ones don't have a screen anymore, so you are forced to use their app to use the locker, which somehow requires both a working bluetooth connection to communicate with the locker, AND you need a working internet connection on your phone. What's the point of that?! The parcel locker evidently already has a working internet connection, that should be enough.

4. Get a USB modem and hook it up to a computer somewhere safe that has coverage, and access it via internet.

I'm building the opposite, using the modem and a Raspberry Pi to send me metrics from my cabin, but could easily work in reverse.

While prototyping I had it parse SMS messages I sent it.

Obviously not for everyone but we're on HN here...

> Subscribe to mightytext.net so you can get SMS on your computer. I don't know if this works if your cell phone can't get signal

It can't – how would it?

The only entity that can forward texts is the carrier, and I doubt that that service is integrated with all US carriers to somehow get them forwarded (which is technically quite difficult for various legacy protocol reasons).

Apple's satellite messaging service is the only solution I know of that can somehow hook into carriers' SMS home router (or IMS equivalent) infrastructure to intercept and out-of-band forward SMS.

The real bonus to security here, access to your SMS is protected via MFA.

> Privacy Advocates would lose their minds

Privacy of authentication may be a valid concern (e.g. during voting), but I don't see how it applies here. If what I want is to confirm to the bank that I am who I am, with all the details about me that I have told the bank already anyway, I very clearly and openly forfeit my privacy. I explicitly ask to be precisely identified.

> Yubikey and like have cost problem and you still have recovery problem.

Recovery is relatively straightforward if you have more than one key. You enroll all your keys, and if you lose one, you buy a new key and use one of the other keys to enroll it.

>your data is more valuable if marketers can assign your real name to your data. or aggregating all data about you, phone number helps with that.

This is mostly a red herring because most of the places that require SMS TOP already have your full name/address (eg. financial institutions, healthcare providers) or are in a position to intercept communications that they can infer that information (eg. google). If apps/sites like tiktok wants my phone number for 2fa, they can fuck off, or get a burner number.

Neither TOTP nor HOTP provide "what you see is what you sign" property, unfortunately, which can be critical for bank and other transactions.

"Enter this code only if you want to pay <amount> to <merchant>" is much more secure than "enter your TOTP here", which is a lot like issuing a blank check in comparison (and in fact required by regulation in the EU, for example).

Not even WebAuthN provides that property on a compromised computer; for that, you'd need something like the SPC extension [1] and a hardware authenticator with a small display.

That's unfortunately why we're currently stuck with proprietary bank confirmation apps that can provide it. I really wish there was a vendor-neutral standard for it, but given how push notifications work (or rather don't work) for federated client apps, I'm not holding my breath.

[1] https://www.w3.org/TR/secure-payment-confirmation/

> This made me wonder whether it would be possible to build a Wi-Fi-only, roaming-only carrier for computers.

This has been essentially been tried multiple times, e.g. by FreedomPop and Republic Wireless.

> Carriers would probably hate this and might not be willing to sign roaming agreements with such a company.

This is THE problem with your idea. Congress would have to pass a law forcing them to do it, or they won't.

You'd probably have more luck physically keeping someone's SIM card, keeping it installed in a phone, and watching for new texts. Perhaps you could make a box that simulates 10 phones at once.

While that is a solution someone could use, it wouldn't work for the subject here:

> she usually doesn't even have service 100 meters down the road.

> TOTP codes typically last for 30s and mulitple actions can happen within 30s

The server just needs to remember which TOTP codes have been used and to reject after the first use.

The code is no longer sensitive after it has been used, so jam it in a database that can expire tuples after a few minutes or stick it in an login audit table if you have one.

My personal 2FA favorite is OTP + authenticator app. It behaves predictably and doesn’t have weird failure conditions.

SMS 2FA tied to your mobile number sucks if it doesn’t support Google Voice, especially when traveling internationally and your SIM card isn’t in your phone.

Email 2FA usually works, but I just find it annoying.

App-specific push notifications mostly work, but it’s hard to debug if you don’t get the notification. For example, I recently bought a new phone and all of my apps were reinstalled when I restored from a cloud backup. For some reason app notifications didn’t work until I uninstalled & reinstalled the apps. And reinstalling the apps was a bit confusing because some of the apps were not available in the app store based on my physical location in a different country at the time.

I have some rural Duo customers and we always end up having to dial up the timeouts because it can take longer than a minute to receive a push notification in some areas. One of them has told me that duo is the only 'notification thingy' that works because the other implementations won't wait long enough.

Beyond "just" being phishing resistant, for banking/payments, WebAuthN even has the opportunity of providing "what you see is what you sign":

The Secure Payment Confirmation [1] extension to WebAuthN supports using passkeys on third-party sites (think merchant checkouts) and including signed structured messages (think "confirm payment of <amount> at <merchant> on <today>").

It wouldn't be crazy to imagine authenticators with small OLED displays to provide an end-to-end secure channel for displaying that information, similarly to how cryptocurrency hardware wallets already do it.

Of course, this would require a certain popular hardware and software manufacturer with a competing payment solution to implement the extension...

[1] https://www.w3.org/TR/secure-payment-confirmation/

Short code SMS goes through different providers than regular SMS, so the deliverability will differ.

For the longest time Authenticator was almost abandoned by Google, so it's not surprising the team responsible for the bundled Android apps swerved it.

It didn't need bells and whistles and constant security updates, but it took 13 years for it to get cloud-sync support so you could backup your codes.

Doesn't this kind of defeat the purpose of MFA in that you now have both factors within the same application?

TIL! Thanks, I had no idea Passwords did this until now.

I implemented 2FA at a previous job and I was responsible for the production implementation working as expected. My thoughts were that uncompleted 2FA attempts are common for a number of reasons: typos, someone gets distracted, didn't have access to phone at the time, SMS sucks (either our sending side or the receiving side), etc. I didn't put much thought into it beyond that. (Should I?)

I implemented rate limiting/lockouts for too many 2FA failures. I added the ability to clear the failed attempt count in our customer support portal. If we had any problems after those were implemented, I never heard about them.

Every second SMS authorization does not reach my phone. Just yesterday I couldn't log in to my GitHub from new computer, because my phone did not receive authentication code. I didn't have any bans because of that. I think that a lot of people experience similar problems, so it makes no sense to look for fraudsters, 99.9999% will be false negatives.

I do not know but I am given a code via SMS for each operation, and each SMS costs more than what a regular SMS costs like, so the bank often deducts quite a lot of money from me for "SMS fee".

I assume it shows up as a hAcKErS sToPpEd figure in a quarterly report where they pat themselves on the back for it along with CAPTCHA hassling, blocking browsers that are too secure, network address bans, popups about "passkeys", forced password changes practically every login, etc. If they had any sense they wouldn't be pushing this nonconsensual trash to begin with.

Those definitely work over wifi. iMessage strongly prefers it.

Maybe verizon is incompetent or malicious?

What happens if you’re overseas or in a cell dead spot with wifi? The latter happens to me all the time in the city.

It’s amazing how many hip “use your phone to order!” restaurants are in cell dead spots, and have set up wifi access points as a workaround.

I'm pretty sure they both do have TOTP but it's not well documented that it even exists, and it's difficult for regular users to use. In iOS it in the Passwords app (née Keychain) and in Android I think it's buried in the settings app of all places. People don't know it exists and don't know how to use it, and even if they did, unless you're already using it for password management, it's difficult to know how to find it. Instructions usually default to a single authenticator app, like Google Authenticator or Microsoft Authenticator, so people end up with multiple apps (Not to mention the garbage adware that always pops up in app store search). And half the time the instructions simply say "Your authenticator app," which doesn't help Joe Schmoe who has no clue where he saved that OTP.

> I'm surprised ios and android don't have native TOTP apps (afaik).

They do.

Google's Authenticator is as close as it gets to a native Android app, and your secret keys are sync'ed in Google's cloud for a while now (it's a shame they waited so long).

Apple's Keychain has supported TOTP for ages too.

That said OTPs over RCS instead of SMS are a major improvement if you don't mind your phone number being used as an identifier.

It's absolutely not discrimination and you're harming people by making such an absurd claim. Unreliable SMS delivery is not discrimination. This is how things end up on Fox News: "Is website security now discrimination?"

> I still think they have a good chance in court

Can you share the law you think was violated?

> but I still think they have a good chance in court.

On what grounds?

The ONLY accounts I have that require SMS and offer no other 2FA are financial institutions. They already have more information on their customers than most other businesses I can think of. Heck, I WANT my bank to have my phone number so they can call me if there's ever a problem. I just want insecure SMS to stop being the only minor hurdle between a fraudster and my life savings.

Companies do SMS because their VP of security compliance demands 2FA and because it's easy and has mature existing third-party vendor support. No tinfoil hat needed for this one.

The article mentions that they've encountered problems receiving messages from short codes via that.

Daito does this:

https://www.daito.io/2fa-via-sms/

And keep in mind you have everything stored on your phone, too.

Putting the username and password fields together has other advantages than you mentioned. It means no additional requests (or JavaScripts or CSS) are required between entering the username and password, and it also makes it more difficult for attackers to guess usernames.

I would want to see X.509 client authentication used more often. It has many advantages, such as:

- Cookies and JavaScripts are not required.

- The credentials cannot be stolen. (With TOTP, the credentials can be stolen for one minute. I have been told that some implementations only allow thirty seconds, but that can cause problems with legitimate authentication if the clock is not precisely synchronized.)

- It does not require a web browser; it can also be used for command-line access as well (rather than using API keys, which are really just another kind of passwords, with the same problems).

- It is independent of HTTPS; it can be used with any protocol that uses TLS (which includes HTTPS but also others). Therefore you can authenticate with multiple protocols if wanted.

- The private key can be passworded for additional security, if desired. (This means that it can already be like a kind of 2FA, but on the client side instead of the server.) This password is never sent to the server.

- If permitted, the keys can be used to sign data which is distributed, allowing other receivers to verify it. This is true of using public/private keys in general, even without X.509. (If X.509 is used, the keys might or might not match those used with X.509, and this might be mentioned in extensions inside of the certificate.)

- They can be used to allow using credentials from one service to log in to a different service if the user intends to do so (and the service allows it, which it should not be required to do). No authentication server is needed for this, since the necessary information is included within the certificate itself. (The buttons to authenticate a variety of other sites, that you mention, also will be unnecessary.)

- Partial or full delegation of authorization is possible (if the service that you are authenticating with allows it). Each certificate in the chain can include an extension specifying the permissions, and the certificate chain can be verified that each each one has a (not necessarily proper) subset of the permissions granted to the issuer certificate.

- You could have an intermediate issuer certificate to fully delegate authorization to yourself (as mentioned above), where the corresponding issuer private key is stored on a separate computer that is not connected to the internet, in addition to being passworded, for additional security, if this is desirable. If the certificate that you are using to authenticate with the service is compromised, you can create a new one with a new key and revoke the old one.

- Some services may allow you to authenticate with any OpenID identity provider, including making up your own. X.509 is a better way to do something similar; if self-signed certificates are allowed, then anyone can make up their own, without requiring to set up an authentication server. OpenID also allows additional information to be optionally provided, and this is also possible with X.509 (without the additional information being limited to a fixed set of fields or being limited to Unicode). Also, OpenID requires a web browser but X.509 doesn't require a web browser.

- DER is a better format than JSON, in my opinion.

(However, I also think that TLS should not be mandatory for read-only access to public data. TLS should still be allowed for read-only public access though; it should not prohibit it. The use of X.509 client authentication means that you can't authenticate with unencrypted connections by accident, anyways.)

It would still be possible to support 2FA if this is desired because some users prefer it (and when doing so, it should do the things you mention, since they would avoid some of the problems with existing systems), but should not be required.

Passwords are terrible. They're Human Memorable Shared Secrets, it's "What if somebody who doesn't know the first thing about cryptography tried to invent secure authentication?" and should have died out last century yet here we are.

We have known for decades how to do better than that. The fact that at least twice a month (often much more) I read an HN comment saying passwords are great is like discovering most of your friends don't know about germ theory still. I feel so fucking tired.

With a Shared Secret system the person authenticating you can give away the fucking secret and we already know we live in a society where they will blame you and act as though there's nothing they should have done better - that's what "Identity theft" is - blaming other people for the fact you didn't do your job properly.

When you use Human Memorable secrets the humans try to remember them, which means they're usually very low quality, dog's name, favourite band, that sort of thing. Worse, since humans can't remember many things they usually choose only a few and re-use them, so now they're not only a Shared Secret they're also Reused which is even worse.

So then we end up with a whole pile of kludges to try to use "passwords" which aren't really memorable, losing most of the benefits yet still retaining most of the disadvantages. This is an awful situation to be in, it's taken a considerable amount of laziness and incompetence to achieve it.

I also hate this state of authentication on the web, but passwords have problems as mentioned in the other comment. API keys are also just another kind of passwords, so they aren't very good either. I think X.509 client authentication would be better, especially for connections that insist on using TLS.

(However, for some uses, signed messages which can be verified by anyone would be better, in case the message is intended to be public anyways; this is independent of the protocol.)

> When you choose an eccentric lifestyle

Many "eccentric" lifestyles are not chosen.

For instance not owning a smartphone or not having access to power easily is not necessarily limited to well-off tech-savv hipsters who want to make a statement, homeless people, older people in less connected areas or people in developing countries can also be in that situation.

When you make your services depend on specific access, and you give people without it no escape hatch, your service becoming successful usually means worsening access for people that have fewer means to adapt.

I'm pretty sure that their mother lived there before SMS was a thing, it's not exactly eccentric. Especially in the USA. You're not seriously suggesting that she leaves her home because of poorly implemented 2FA?

20 minutes outside of Asheville, NC is hardly "an eccentric lifestyle". Let's break it down: which part of this is "eccentric"?

1. Has internet, has WiFi calling.

2. Has a cell phone, but the signal is crap at the house.

Before you answer, that describes my house exactly. And I live in Redmond, WA, and a 10 minute drive from the Microsoft main campus. Though the neighbors might disagree, there is nothing eccentric about my lifestyle.

the article is about a retired woman who lives twenty minutes from Asheville, NC.

The terrain is rugged there, but it is not an "eccentric lifestyle"

It is extremely typical, however, to see the most basic needs of Appalachian people ignored on the grounds of their perceived choice of lifestyle

just this weekend I endured yet another incest joke.. I bet you have one of those ready too