> port her cellphone number to a VOIP provider that does support receiving SMS from shortcodes over wifi
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.
> 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.
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.
> 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.
> carriers charge a lot more for commercial customers
I've been used to unlimited free SMS for so long now (though I remember the days when it was limited), I forgot that commercial customers get charged for these
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.
May vary by institution, but both banks I have accounts with also support having a robot call my phone where I can confirm the login. That should at least work with WiFi calling.
I absolutely cannot stand that no bank I have (US) supports generic TOTP, which is more secure and easier to recover from backup if my phone is broken or stolen.
This is probably compliance-related. For me, TOTP isn’t “something I have”, it’s another thing I toss into my password manager and sync to all devices.
I really agree with it, but that’s probably their rationale.
Banks didn't support TOTP long before we were able to easily sync them across devices. It's likely more along the lines of banks generally have bad IT departments and outdated digital security policies.
That same rationale wouldn't support SMS as "something I have." iMessage and other solutions easily spread SMS into cloud and PC lands (ones that are more easily accessible than password managers.) More likely it's because of legacy and "good enough" reasons.
Personally I don't put TOTP tokens into my password manager and keep a dedicated app for it, just in case my password manager is pwned.
I'm not really defending it, I'm explaining the mentality. iMessage is probably closer to "something I have" but yeah, often not true for many American users.
I'd probably keep a TOTP app if I actually brought my cell with my everywhere but I really don't feel like it; if I'm heading to a cafe to work for a bit I might need to access something and can't be bothered to bring two devices.
Plus, people increasingly access stuff from cell phones, so it's not a guarantee of "something you have" anymore. And no shot we're convincing everyone to start carrying some kind of hardware token.
You have to remember that cybersecurity is driven by what is secure so much as what is compliant, and increasingly so.
I do the same, and it somewhat defeats the spirit of 2FA, but I still believe it's more secure. It's basically a second password where intercepting it in transit once isn't enough to be able to repeat the login in the future.
My bank sends me 2FA codes in their app, which I then have to type into... their app. No kidding. Both the key and the validation in the same place, really ridiculous. Even something as crap as SMS 2FA would be better. TOTP or FIDO2 would be miles better.
TOTP is alright for logins, but it's generally very phishable. For transaction confirmation, not being able to tie a code to a given recipient and amount is somewhat of a dealbreaker.
Fwiw, Symantec VIP is TOTP under the hood, and you can extract the seed with some hackery. There is at least one financial institution in the US that uses that.
USAA. Better than nothing, but since it doesn't do push notifications it's a needlessly proprietary piece. It's probably a combination of legal and a slow IT infrastructure.
There is at least one major US bank that supports Yubikeys and a different major that one supports (with some convincing) phone notification-based second factor.
I could not use my Google Voice number (that I've had since Grand Central) for most companies that only do SMS 2FA until it became my Google Fi number. Then I guess some flag got set in the database they check against.
>I could not use my Google Voice number (that I've had since Grand Central) for most companies that only do SMS 2FA until it became my Google Fi number. Then I guess some flag got set in the database they check against.
I was wondering about that, because I can't get google voice because I have google fi, so clearly it's using the same bank of numbers, but maybe once they are fi, they are ported to T-mobile instead of their own CLEC.
Yeah, I think that restriction was due to that extremely strange way of using Hangouts (remember that?) as a possible backend for both Google Voice and Google Fi text messages.
yeah, I use GV with all sorts of things that don't normally allow most likely as a result of being grandfathered in - i.e., I suspect they don't recheck old active numbers as being invalid per VOIP classifications/etc.
GV still works on BOA to an extent: general balance queries through their app or the web will go through but anything involving identity and real transactions via wire or zelle will ask for your real mobile number. Even if you do happen to visit one of their branches they will ask for confirmation through your real mobile number (landlines will obviously not work).
I think your experience is typical. I use my Google Voice number for everything and have rarely had any issues.
There are a few popular companies that blacklist VoIP numbers, but most don't. Even Chase, which historically blocked Google Voice, started allowing it a couple years ago.
Ah, I always assumed Google uses Bandwidth.com completely transparently – I wasn't aware there's a separate level of "line provider" look-up available. Thank you!
There must be something unique about my GV number. It's even allowed on WhatsApp (knock on wood).
I registered it about 13 years ago. I didn't transfer it from a landline/cell phone, it was picked from a list of Google Voice numbers available in my area code. I've never had Fi.
We actually had it that way on accident in a few of our applications - we had a `#isTextable(e164)` function that would do a carrier lookup and voip carriers sometimes returned as landlines or as arbitrary values that didn't mean mobile. We eventually did some work to refine that function to be smarter and actually better represent if the number was textable. At least for us, it wasn't a conscious decision, it was a gate being aggressive in our SMS pipeline.
>>> 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)
Ironically, this is only true for prepaid SIMs. As a result, in some EU countries it's easier to get a month-by-month postpaid plan – sometimes there's no KYC at all for these...
Yes the problem with UK ones though is that they route all the traffic through a prude proxy if you don't register. Because the UK is getting back to the Victorian era.
I had a SIM from three Ireland that tried to apply this UK policy also on the republic of Ireland customers where this is not required. It was unusable, it blocked pretty much everything it didn't recognise like VPNs, even email servers. Luckily there's many sane providers there too. And no they don't require registration.
Possibly less secure, considering the existence of sim-cloning crime rings. SMS 2-factor potentially gives a hostile actor a way to 'prove' that they're you.
I'd argue that there isn't one: you have to offer multiple choices. Auth through any TOTP app, Yubi key, pre-generated codes, mailing a physical code generator, etc.
> 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)
I don't think that's true. Is there even any way for banks to ask your mobile operator for your identity (or confirm it), in the way that US banks seem to be able to? That seems like it would run afoul EU privacy regulations.
And regarding the EU "anonymous SIM" regulation: That one ironically only seems to apply to prepaid cards. To my surprise, I was just able to register a postpaid line using no identity verification whatsoever a few days ago...
> 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.
The "thing you have" is actually the SIM card. That's supposedly why email OTP does not count – an account on some server is not, or at least not cleanly, "something you have". (A pretty poor decision, IMO, but that's a different story.)
> 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)
All demographics except for people that change phone numbers frequently. All locations except those that don't have cell signal (or for plans without roaming). All mobile devices except those without a SIM card slot. An authentication solution for absolutely everyone! /s
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
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.
VoWiFi (as Wi-Fi calling is called in the 3GPP specs) is similar to VoLTE, but not all SMS go over VoLTE: Unlike for calls, where there's mandatory VoIP in 4G/LTE and beyond (there is no more circuit switching), there's still a fallback path for SMS that uses legacy signalling instead of IMS (which powers VoWiFi and VoLTE/VoNR).
Maybe there are some SMS gateways that are somehow incompatible with some IMS message gateways? (Theoretically, the IM-SM-GW should be transparent to external networks, I believe, but practically I wouldn't be surprised if some weird things lurked in there, requiring a fallback to the signalling path, which is not available on VoWiFi.)
Unfortunately there are a lot of "is this number voip" services that use various tricks to detect voip numbers, or simply buy this data from the voip provider or someone else in the path.
If nothing else, if a particular voip provider only does voip, you can just put them on a blacklist. You can get any number's provider from the number portability clearinghouse (this might be country dependent, where I live, there's only one, and anyone can query it).
"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.
> 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.
Why ? I still send SMS. Wifi is not available overall. The Google SMS app is not able to retry sending when connectivity is back and the UI is enshitified, but this is norm in modern software.
Talk to your provider, explain to them you get poor service at your home or place of work, and they'll send you a free Internet-in cellular-out radio AP. She doesn't need a tower-based booster if she's got fiber/cable/DSL, those only serve to amplify weak signals and she's too many miles and too many mountain ridges away from the nearest tower, she wants something with RJ-45 input, a little GPS antenna so the cell supports e911 location data, and it will broadcast LTE (or now 5g) cellular data.
I work at a shop with metal walls located in a river valley. It's a cellular data black hole. People used to climb the hill up the driveway to make and take calls, but various people called their ATT, Verizon, and T-Mobile providers and all three shipped us femtocells. Mow the users and the contractors/customers who come to visit can't even tell that their phones have switched to data over our ISP instead of a tower, it just works - including 2FA codes and MVNOs.
She may have to switch to first-party Verizon service instead of using an MVNO.
Maybe T-Mobile doesn't need to. I've used their WiFi calling for, what, going on ten years probably. Works a treat, including getting short code SMS. Ergo, I don't know the use case for femtocell for T-Mobile. That's why I was surprised to learn via TFA that WiFi isn't the solution in all cases.
We moved to a T-Mobile femtocell precisely because their wifi calling was absolute shit in our experience. Dropped calls, no group SMS, no SMS/RCS images, frequently no calling service at all. The femtocell fixed all of that for us, and it has remained fixed.
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.
They do not have to receive GPS, but it causes issues for e911 service if they do not. It has no impact on anything else, at least not the T-Mobile version.
The one I had, an AT&T Microcell, which was the only model offered by my cell provider, refused to work without a GPS signal.
Strange, because my AT&T Microcell didn't require a GPS signal. I kept it in the cabinet under the sink deep inside a large apartment building where there's no way it could get a GPS signal.
I haven't used since I moved a few years ago. Perhaps it's changed.
"After giving the MicroCell some power and ethernet, it will start blinking the 3G and GPS LEDs. Wait, what.. GPS? Yep. To limit the MicroCell from working outside of test markets (or out of the country too), it must get a GPS lock on your location. AT&T suggests this should take no longer than 90 minutes. It took me about 5 hours."
And this was the fundamental problem: there was absolutely no way to know if progress was being made or if it was going to run forever. It was literally a real-world Halting Problem.
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.
>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.
A lot of office buildings have these in them. I think the personal ones are how they get around some of the issues with government requiring them to build networks to certain coverage. They just don't build it out and when someone complains they offer them one of these.
A lot of office buildings have these in them. I think the personal ones are how they get around some of the issues with government requiring them to build networks to certain coverage. They just don't build it out and when someone complains they offer them one of these.
Also because a lot of office and residential towers have people high above street level, and the buildings have radiation-minimizing windows so that no cell signal can penetrate. The cell companies put their sites 30 feet above the street, not 600+ feet up.
Femtocells are remotely controlled by the carrier, they require GPS location (and maybe spectrum sensing), and I assume the backhaul is over VPN. Obviously they can't guarantee any QoS but it's better than having no signal.
(Fun trivia: Our office paid $XX,000 for AT&T MicroCells which wouldn't activate because they couldn't get GPS signal.)
Eh, assuming it's 4G LTE (or above), it's literally the same thing as Wi-Fi calling. This is technically called IMS (IP Multimedia Subsystem, https://en.wikipedia.org/wiki/IP_Multimedia_Subsystem), and is powered by "magic" DNS (no kidding, everything points to 3gppnetwork.org) and literal IP + IPSEC. Even when your phone is connected to Wi-Fi, it enters a special mode called IWLAN which powers your Wi-Fi calling, SMS, and RCS. The only actual factor here is if the ISP that you have versus your mobile network has a good peering.
No, in this case the consumer femtocells on the market (AT&T Cell Booster, Verizon LTE Network Extender) are actual eNodeBs inside the carrier’s RAN. They will IPSEC tunnel back to a security gateway (SeGW), grab provisioning information, and then come up on the carrier’s commercial license as just another (fancy low powered) LTE radio on the network.
AT&T did try to add some additional tamper switches and protection inside their units so they’d brick if you opened them - that was known since the MicroCell era. I believe T-Mobile’s former CellSpots were also tamper-protected in the same manner (they both deployed Nokia LTE small cells).
AT&T also appears to now charge you for the privilege of deploying the newer Cell Booster Pros if you want 5G - I assume that cost ($30/mo per cell!) is basically covering licensing the backend for all of that.
Wi-Fi Calling uses a different SeGW endpoint and is pure IMS back to the carrier voice network, regardless if you shoot it over WiFi or back over a dedicated APN on the LTE network in the normal VoLTE fare.
Thanks for adding some information on this, I had almost forgot about these devices.
So would a cell booster / network extender using eNodeBS ( https://en.wikipedia.org/wiki/ENodeB ) actually help in the scenario in the original article?
Or would it end up as the same issue with wifi calling, where "messages from 5 digit shortcodes often aren't supported over wifi calling" ?
If the device is remotely managed and all IPSEC back to the carrier, who cares what network it's on? At worst you'd just get poor connectivity, I don't think there's any additional exposure here.
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.
Some of the comments pointed out that this is hostile behaviour for people roaming as well, and I completely agree. Here is my solution for this : 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 : https://f-droid.org/packages/tech.bogomolov.incomingsmsgatew.... Every time I receive a SMS I forward it to this API. The API in turn emails me the whole message.
I have been using this setup for a few years now without any issues. Even when I am not roaming, I still have this setup on my primary phone. So when I am on my computer and need a SMS OTP I don't need to go find my phone, I receive it in email :-).
(Note : This doesn't work with MMS but I don't need them anyway)
"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 ..."
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 hate SMS 2FA because of roaming: I'm from one EU country that lives in another EU country. I still have my origin country sim, but it's a prepaid that I can top-up twice per year to keep alive (but because it's prepaid, I can't use roaming with it unless I buy the most expensive option and if I go back to origin country something like once every 2 months). Now I need SMS 2FA for certain services in origin country, and those services don't allow any other numbers outside of the country (why I still keep the number to use when I travel back to origin country) or any other type of 2FA. So basically phone 2FA is useless and a blocker.
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...
Technically you are right, the SIM card isn't roaming, but I am physically roaming outside of my home network (internationally).
Some phone plans in my home network do not support international roaming, or if they support then it is ridiculously expensive that it doesn't make any sense to take the phone roaming.
Google Fi can receive all SMS 2 factor messages on Wi-Fi including short codes. It doesn't even require that your phone is on, you can get them in any web browser on any device even if your phone is destroyed. One of my favorite features.
You can get service starting at $20 per month. Fi used to have good service in some mountain areas too, with US Cellular. Not sure what's going on with US Cellular right now though. Some kind of half acquisition by T-Mobile.
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.
>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.
To be somewhat more specific: while I travel extensively and am in the US often, I am often outside of it for more than a month at a time, and it appears that Google will shut off data outside the US if you use data outside the US for too long. If you are using a different SIM for the primary data connection, it appears that they won't even if you have it enabled as a backup.
My comparison here is actually that I've never had it shut off. I'm not quite sure what the criteria are. I do have a friend who had it cut off after a few months of using it for all his data in the EU.
compared to prices for the rest of the world, you wouldn't want to use Fi for data anyway... just get a local or even "travel" esim and run with dual sims.
I’ve found that it’s easy to data-only eSIM package through an app store app such as Saily, but it’s harder to find a service that gives you a “real” phone number when traveling internationally. Any recommendations?
I don’t have direct experience, but I’ve heard about or seen the following online (there may be many other MVNOs). All of them are activated with an eSIM and they have WiFi calling, which means it’s a real US phone number as any other and you can make/receive calls and send/receive SMS as long as you’re connected to the internet via WiFi or through a data connection on your second SIM on the phone. If you wish, you can buy real roaming too, but that tends to be expensive.
* Tello
* Red Pocket
* Good to Go Mobile
If you’re looking for a real local phone number in the location you’re traveling to, then eSIM providers like Airalo can handle that (Airalo has “global plans” that support voice and SMS). Getting such a connection for voice and SMS, as compared to a data SIM alone, would be expensive. So you could get a data eSIM that works locally and use that for “WiFi” calling/SMS with the providers mentioned above.
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).
Yeah no it still disables RCS which is super lame now that iPhones finally support it. I hope Google gets around to fixing it someday. I'm not holding my breath. I'm just happy they didn't kill the feature when hangouts died. The URL changed, it's now https://messages.google.com/web/
Something somewhere is always hostile to particular group. That's just facts of life. You do your best to minimize but can never eliminate it.
As someone who has dealt with 2FA support, all the methods suck.
SMS 2FA is least secure but has broadest support with quickest recovery method.
TOTP Applications (Google Auth, Authy, iOS Passwords) is more secure but people switch phones, lose phones and so forth and recovery is always a nightmare.
Yubikey and like have cost problem and you still have recovery problem.
A clear solution in my mind is having the Federal Government run some form of centralized hardware based system where hardware could be replaced by government office after verifying identity. Government does this already for DoD CaC cards. However, in the United States, Privacy Advocates would lose their minds, and funding would constantly be under attack.
So yea, I get SMS 2FA is hostile to mountain people but 2FA is hostile to login services and executive yachts.
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.
For banks an other cases that (1) need to know you true identity, and (2) provide no expectation of privacy regarding sharing the existence of accounts with the government, a government run authentication would be fine from a privacy point of view.
The issue is that every site has moved to using 2FA, and most of them have no legitimate need to know your true identity. So using a government ID based solution would unnecessarily conflate authentication and identification and would be a real privacy concern.
Can you offer an example of a situation when the second factor authentifies without identification?
Assume a service S wants a confirmation that user U is indeed legitimate. The centralized auth service A could receive from S a bunch of data S knows about U, like name, address, phone, SSN, whatever S needs to know about U. Then A should respond whether the fields match the data which A knows about U, without revealing to S any additional data that A may know about U.
The problem if a centralized service is that it's a SPOF, and the juiciest target for compromising.
I still think that TOTP and personal crypto tokens like yubikey are the most resilient, and technically the easiest, solution to that.
Any TOTP where the user enrolls it on account creation, without going through a third-party service. Or SMS on a burner phone. Both are pseudonymous, since using the same authentication at multiple sites could be linked, but neither have to be tied to a real-world identity.
Any system in which the government can re-establish account access on my behalf is a system in which the government can access my account without my knowledge. No thank you.
If you mean the government just replaces hardware and re-establishing access is up to me, that’s no different from Yubikey.
> 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.
Much agreement with the others that there's too much expectation. I rented a lime scooter for the first time last year. But, I messed up my VPN settings so I had no Internet. There was no way to tell the scooter I'm done. Even though it was stopped, no button to end the ride. They refunded me the extra time (which was maybe 5 of the 10 minutes) because they could see it was just stopped at a bike rack on gps. Idk what I'd do if my phone died or any other reasonably possible things when you're out and about and on a scooter.
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.
Are you sure that the locker has an Internet connection?
Requiring Bluetooth and an Internet connection on your phone suggests that that's exactly what they removed on their side. Quite clever, if true – why pay for network connectivity if you can just piggy back on your customers'? (Nevermind those customers without a smart phone and data plan...)
> Are you sure that the locker has an Internet connection?
Let's put it like this: The old ones (with a display) definitely do, because they can send email notifications. I would be very much surprised if the new ones didn't. The main reason for requiring the app isn't connectivity to the outside world, it is that they can save money on the terminal screens, which get vandalized frequently in some areas. The internet connection is probably a fraction of the cost of replacing those touch screens every few months.
Reminds me of a cashless hotel laundromat that I had to use that didnt accept coins, tokens or had a credit card reader. So to wash my clothes I had to find a charger to charge my phone, download an app, being able to receive SMS 2FA while roaming which is a hit or miss depending on roaming agreements, having working internet connection, enabling Bluetooth and Bluetooth Nearby Devices, and then top it up with a foreign credit card. It took about 30 minutes to set it up.
I guess this would be easier in a beighbourhood laundromat with local clients, but in a hotel with many foreigners it becomes a pain with so many dependencies needed to use the washer and dryer.
They always had internet access. Of course it is possible that they decided to rip out the internet connection in the new models together with the touch screen, but I heavily doubt that they want to trust the internet connection of a random stranger to do whatever important communication they have to do with their servers. The app only requires internet access because... well, it always needs internet access.
I'm currently developing firmware that supports both Bluetooth and cellular connection for a hardware device. With proper cryptography, you don't have to trust the random stranger (e.g. using TLS). In fact, you can get away with no connection at all. For example, when someone locks the locker, it sets a "password" via Bluetooth and when you open it, your phone simply transmits the "password" via Bluetooth.
I'm not just thinking of trust in terms of whether the device will tamper with the data, but also stuff like: What happens if you just put the parcel in the locker and in that exact moment the internet connection cuts out? Normally the parcel locker would send some data to DHL servers (as made evident by the fact that the lockers can send a confirmation mail), how do you get that information out now? Of course you could queue it up until the next person arrives, but all of that seems... suboptimal to me.
Cellular modems and data plans can be expensive and unreliable. If you can do without, at the cost of very rarely being out of sync (like in your scenario), it can be considered an interesting tradeoff. Plus, even if they were equipped with cellular modems, they probably have a business requirement that the locker should be usable even when the cellular connection goes offline, so you have to design your protocol to be Bluetooth-first.
SMS needs your number, 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.
>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.
I don't understand how this post stacks up against the myriad of communications apps that not only require phone verification when creating a new profile (and maybe SMS2FA), but put great effort into blocking as many VoIP/burner/prepaid numbers as possible.
"Most"? maybe "a troubling few"?
Phone verification is absolutely a widely exploited data mining opportunity, I don't see how it's a red herring at all. It's one of the worst surveillance mechanisms we live with today, only partially waved away with the 2000's concept of burner numbers.
To single out Meta properties, I'd point to both Instagram and WhatsApp. It was an official policy early on that you could only create a WhatsApp account if it was connected to a "real" cellular number, I think the same has been true about Instagram for a while in that every time I tried to create an account without a cellular number it didn't work. Put in a cellular number and it worked just fine.
Last time I tried to create a throwaway account for facebook it didn't actually ask for my mobile number. Just automatically banned me for being suspicious and then demanded a video of my head with no assurance that would actually help. I generally avoid meta but it seems like most craiglist sales have moved to facebook marketplace.
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.
only system which does it securely is bitcoin cold wallet / offline computer signed transaction
or as you pointed out, signing it on smartcard with keypad reader.
but for login TOTP is better then anything else. i can put it on arduino with small oled board and have it in safe/vault offline.
and there is no way for attacker to MITM, and here lies the problem. companies can not blame you as easily as with currently deployed technologies... they hide breaches all the time, f... PCI
> but for login TOTP is better then anything else. i can put it on arduino with small oled board and have it in safe/vault offline. and there is no way for attacker to MITM
There totally is! How do you know you're entering the TOTP on a legitimate website?
WebAuthN prevents that, both by not letting you use a given key on the wrong website, and by including the origin in the signature generated using the key which the relying party can then check for plausibility.
1. Download the Google Voice app. This phone number works for some but not all 2FA services. Not all, because some explicitly forbid GV numbers because they're afraid of fraud. GV can receive SMS messages over wifi.
2. Ask the cell phone company for a femtocell. These used to be called "AT&T Microcells" and they were cheap. I used one before cell service improved because I live in the mountains. But apparently AT&T don't make them any more and now they cost $2500.
3. 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; I use it because I find it easier to use my laptop keyboard to type SMS messages than to use my thumbs on my phone.
> 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.
> Apple's satellite messaging service is the only solution I know of that can somehow hook into carriers' SMS home router
Are you sure it actually does this?
I thought it was a pseudo-carrier that could speak MAP / Diameter, and just pretended you were roaming with them when you used satellite connectivity, perhaps with the original carrier's knowledge and consent.
As far as I understand, that's how this kind of service usually gets implemented.
I assumed that that's how it works because I couldn't think of any other way to achieve the observed behavior, but pseudo roaming sounds plausible too, and presumably requires much less work on the carriers' side!
Would that approach also allow the extra functionality they seem to be offering, such as only recently messaged numbers and emergency contacts being able to send messages to satellite users, though? I suppose they could just reject all MT-Forward-SM with sender numbers they don't like?
> As far as I understand, that's how this kind of service usually gets implemented.
Do you have any other examples for solutions like this? Are you thinking of (pre-VoWifi) carrier apps or services that could receive texts, sometimes on multiple devices?
> Do you have any other examples for solutions like this
I have a vague recollection that Pebble had something like this to get texts on the Pebble watch.
> Would that approach also allow the extra functionality they seem to be offering, such as only recently messaged numbers and emergency contacts being able to send messages to satellite users, though?
Hmm, you could definitely do this with a "Stripe-like" approach, where the actual traffic goes over the usual protocols to ease implementation, but the carriers provide Apple an API to query messaging history in some way (which they probably already offer in their apps, and so have good integrations for anyway).
Stripe uses this pattern for fraud detection. Their card transactions still go over the antiquated ISO protocols from the 80's, because that's just what everybody integrates with and agrees on, but they can also speak a custom API directly with participating banks, mostly for better fraud detection and fraud-related information sharing.
TOTP are okay for some things but often regulation means each code/challenge needs to be tied to a specific action. TOTP codes typically last for 30s and mulitple actions can happen within 30s, so it's not possible to use TOTP in many cases.
PUSH approval could be used instead but then you need to download an app for every service you use, which isn't very convenient.
PASSKEYS offer a solution which will work on both web and mobile and don't require you to download an app for every service. But it's a new concept that people need to learn so how fast they will be adopted is yet to be seen.
> 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.
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...
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.
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.
TOTP isn't phishing-resistant, which is the whole ballgame. I've had the job of working on authentication for highly-targeted mass-market systems, and code-generators basically don't work: they raise the bar on phishing attacks to a level phishers still easily meet.
TOTP and SMS 2FA prevent credential stuffing attacks, which is very valuable considering how bad people are with password reuse and how many breaches with plaintext or weakly hashed passwords there have been.
Yes, but other authentication factors also prevent credential stuffing, as well as phishing, which is probably the most important problem in authentication.
I hate email 2FA because I purposely don't have email on my phone. Unless I'm in front of my computer, I'm unable to log in to websites that use email 2FA.
Have you considered installing an email client on your phone, but not giving it the credentials it would need to fetch mail from the mailboxes you don't want to be tempted to look at when away from a keyboard?
It's basically all one mailbox, but lots of forwards, so that wouldn't work. But my reasoning is not so much because I'd be tempted to look at email when AFK, but more for security: I don't want email to be accessible from my phone.
Oh, this happens to me. I didn’t even realize that’s why I wasn’t receiving some sms codes, because sometimes it works and sometimes it doesn’t. I live in a rural area and have spectrum for both wifi and mobile (just like the woman in the article). I have some cell service, but depending on how strong it is in any given day am usually relying on wifi for calling and sms.
SMS codes have been hit or miss, and this explains it well.
This made me wonder whether it would be possible to build a Wi-Fi-only, roaming-only carrier for computers.
Your carrier is already capable of redirecting your SMS messages to other carriers, that's what they do when you're abroad and roaming with a foreign operator. You could make a fake carrier that speaks the right protocols on the roaming side, but communicates with the customer over the internet (using an API or a proprietary app) instead of LTE or GSM.
This would essentially work like an SS7 redirection attack, but with the full knowledge and consent of the "victim." You could alleviate the security impact here by requiring SIM card authentication, just like a normal carrier does, which could be performed through the internet and an USB reader just fine.
Carriers would probably hate this and might not be willing to sign roaming agreements with such a company. I wonder whether a gray-hat route would be possible here, especially if the company was outside US jurisdiction.
> 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.
> congress would have to pass a law forcing them to do it
Well, I'm not so sure about that. SS7 redirection attacks exist, so clearly shenanigans like these are very hard to stop for carriers. The question here is whether such "attacks" are legal if performed with the consent of the customer, but against the wishes of their carrier.
One could also do some "legal optimization" here, and ally themselves with a major carrier outside the US. There are plenty of those, and all of them have access to the networks (SS7 and IPX) on which roaming happens.
"SS7 redirection attacks" means, more concretely, "hacking into some phone company that's connected to the one you want to redirect, and using that system to send false data to the one you want to redirect".
It's BGP hijacking but for the phone system. If Comcast is connected to Verizon, and I want to hack your connection to Google, and you're on Verizon, one of my options is to hack Comcast and have Comcast tell Verizon that Comcast has a really fast connection to Google. It might let me intercept your traffic if circumstances are good; it's also fraudulent and illegal through and through. If caught, I will go straight to federal prison.
(Of course the analogy isn't 100%. The set of things you can do by hacking one side of a SS7 link is not identical to the set of things you can do by hacking one side of a BGP link - in particular, there's no BGP roaming. But it's a similar principle.)
I remember in 2014 going to play a Bitcoin poker game at some Google VP's house way up in the hills, Charlie Lee was there. We tried to buy-in at the beginning to a pot address but no one could get their Coinbase SMS 2FA to work because we had no reception so we ended up writing IOUs on scraps of paper.
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.
You don't actually need MFA. This whole thing came about because people reuse passwords between websites and websites have their databases hacked all the time so the same password can be used to log in on other sites.
2FA codes solve that because you can't reuse them between websites so one website getting hacked doesn't expose all of them.
You can easily reuse TOTP between websites, but not many websites let you set your own TOTP secret. They could easily do the same for passwords, but none do.
If cell service is available in at least one area of the property, you could have a dedicated sim for receiving SMS 2FA and use a 4G router to forward the SMS to an email, e.g. Teltonika have this functionality [1].
The 4G router also has the benefit of being able to use externally mounted antennas. Which might help in low signal areas.
Not ideal, but might at least be a solution for some people.
You can also get antennas with suction cups. I have used this before to get 4G internet in a house with no access downstairs, by sticking the antenna on an upstairs window.
An outdoor antenna would be better, but yeah more of a pain. I guess it really depends on how badly someone wants SMS.
The point of SMS 2FA is not security and never has been.
The point of SMS 2FA is tracking.
It's to force you to give them your phone number, for their own marketing, but also selling your customer profile to companies like Palantir.
This also makes the government happy, because they can scoop up your SMSs and they get a nice handy list of every service you use which makes warrants easier, but also gives them info about when you log in or do other actions on those accounts.
SMS 2FA costs these companies far more than TOTP would, but they still use SMS 2FA. That tells you everything you need to know...
I remember running in to this problem in university too where one of the basement lab rooms didn't have cell service, but we had to log in to the school computers with our university accounts that had mandatory 2fa
also was surprised to learn from the article that some carriers don’t support the 2fa 5 digit numbers over wifi calling/sms. when I travelled abroad recently that was such a life saver since my carrier supports it
This is a problem with her carrier or her specific account provisioning. SMS over WiFi calling works just fine, including from short codes.
I'm often traveling outside of the US, and my AT&T prepaid line most definitely does not roam outside of CAN/US/MEX. I spend the bulk of my time in WiFi calling mode. I have never had any issues receiving or sending SMS over WiFi, including to short codes.
TOTP might not be perfect, but they don't need networking. There's absolutely no reason a third-party or the server needs to maintain a source of secrets on demand needing to be sent over a network when the user can maintain an offline-capable 2FA generator themselves.
I'm not sold yet on non-portable, proprietary passkeys.
"it turns out messages from 5 digit shortcodes often aren't supported over wifi calling."
This does not seems plausible. I live in urban area but do not have good cellural connection at home and my mobile phones are usually route calls via home Wifi. All SMS come through. It is just a low-lever transport and I doubt it cares about message size or numbers.
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.
Anything else could be lost. I can always get new SIM card for this number. I don't need to backup it and I can't accidentally delete it. That's the biggest reason for me to link phone number everywhere. I'd hate to lose access to my GitHub account.
It's also not very hard for scammers to get a SIM card for your number, unless you're using a carrier that specializes in not allowing SIM swapping attacks.
That's why 2FA is called 2FA. It should require two factors. SMS + Password, for example. So scammers would need to steal both password and perform SIM swap, which hopefully is a bit harder.
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.
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.
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 did some digging, and it turns out messages from 5 digit shortcodes often aren't supported over wifi calling. sometimes they are, but in her case they're clearly not.
This seems like a rather specific problem that isn't related to mountain people as such but services blocking "shortcodes" apparently for a variety of reasons. It is true that text and call reliability is becoming a real problem generally where you have these authentication issues. I myself in the mountains and have dealt with reliability issues.
She should switch cell phone providers. I’ve never had a problem receiving 2FA SMS from five digit numbers over WiFi, and heavily rely on it working. I know this for sure because I have an automation set to put my phone in airplane mode + wifi when I get home. (It eats battery when there’s a weak 5g signal.)
> and TOTP, the obvious alternative solution, is still pretty sorry. you have to download an app to do it, it's not just a capability that a phone has by default
iOS Passwords can serve as your TOTP authenticator app.
This is a really good point, "cell service will always be available" is a classic incorrect assumption that needs to be shattered. I do kinda wonder what the correct way forward is, I think it's silly that ISPs don't support this type of SMS over wifi but I have no clue why. Meanwhile TOTP apps are rightly pointed out to be too numerous with unclear trade offs, I'm surprised ios and android don't have native TOTP apps (afaik).
As an aside, I hate the nuance-less "SMS 2FA is insecure" line. It's the weakest 2FA form for sure, but it's still so much better than not having 2FA. Even if you support multiple options depending on your product it may very well make sense to stick with SMS as the default to reduce friction.
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.
Many of the big companies seem to really want you to use their app so there's this big game of smoke and mirrors to avoid saying it is TOTP or what they're actually doing. And of course they make it as big of a pain to export your codes as they can get away with. Then they hide behind it being complicated and that is why they have to do this to help grandma, but much of complexity is due to their obfuscation.
> 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.
Google Authenticator is a separate app that you need to download from Google Play. Native android solution is Google Password app which is pre-installed (at least on Pixel) and its functionality is extremely rudimentary even compared to Apple Passwords. No TOTP support there.
I think that Google does not care about security for their users, because their passwords app is clearly some intern work, not something really well thought. They just slapped it to mark a checkbox in their "Chrome password autofill" TODO list and moved on to a more pressing issues like implementing user tracking and extracting more ads revenue. Apple had similar issues for years, but I think that their recent releases significantly improved.
Until recently, Google Authenticator codes could not be backed up or transferred to a new phone. When I replaced my Android device, I had to re-register every TOTP code that I had in Google Authenticator. This led me to Authy, and later on to Yubikey since the code is removed from my phone completely.
I'm not sure we can blame Google for not pushing their Authenticator more, most services have been dead set on SMS and are now slowly moving to Passkeys, probably for the best.
Passkeys are going to make these problems much worse.
What do you do if google/ms/apple won’t let you log in, or you lose a device, or you lose your phone?
If the answer is “there’s an account recovery path involving a password”, then just accept passwords!
If the answer is “recover the passkey provider account”, then that forces everyone to have a single password / security question / whatever that grants access to all their accounts.
I don't want Google to push their Authenticator, I want Google to retire their Authenticator, implement TOTP codes in their Passwords app (it's very trivial to implement) and implement passkeys on Google Chrome Linux (now those are not trivial, but if they push passkeys so hard, they could at least implement them). I also want to be able to store any items in Google Passwords manager, like ssh username/password, my bank cards, software serial codes and other sensitive information (again trivial to implement, just provide me multiline textedit with notes). I also want password generator in their app. I also want to configure multiple domains for entry, like microsoft.com + live.com. Are those big requests? I don't think so.
I have garbage cell signal in my house, was only an issue for sending/receiving large pictures/video's over iMessage, apparently those don't send over WiFi for some unknown reason as well... I called Verizon and they sent me a Fem2Cell, problem solved.
1. 2FA over SMS is only $23 away from a compromised phone service
2. People love binding individual accounts to specific IP addresses, and large marketing firms especially like websites that use free DNS service to quietly track said users across the session
3. Much like DRM, the account auto constrains a single user to a single IP. Makes sense... unless you run a business account with a dozen people clearing a shared inbox
4. SMS inbox phone numbers are $2.75, and that requirement is bypassed if the company smartphone hardware/emulation is in use for account "recovery"
5. SIM hijacking and email server snooping is far more common than people like to admit
6. People feel safer, but it only increases the CVE difficulty level slightly above third world skill levels
I had this problem a couple years back, when I was living in a small coastal town where cell service was spotty. Generally I could either be in a place where I could receive text messages, or a place where I could get access to wifi, but not both at the same time. When I wanted to get into my bank website, I would drive 20 minutes up the road to the next, slightly less small town, where I could get wifi and receive SMS, then drive back when I was done.
If I had stayed there longer, I might have found a better solution for my personal situation, but the experience as it was left me pretty uncomfortable with mandatory SMS 2FA as a general security tool. I'm sure there are many other people running into similar edge-cases.
I've read a fair number of cases where sim-swapping led to account hacks when the providers got talked into resetting passwords. It happened to a friend of mine. So I would say SMS 2FA is more hostile to people who are able to use it.
This is a niche article, where it reads as though the SMS 2FA messages started coming through right as the lady purchased a cell service. Well the lady would have needed to have activated 2FA first and walked away from the house to even enable it.
Then goes on to say that TOPT is also too difficult, firstly because you have to download an app to do it, yet she supposedly knows how to use her phone.
There will always be edge cases where something doesn't work perfectly the way it does for everyone else. The solution here seems to be help her choose a TOPT app, print out those backup codes and be done with it.
> and TOTP, the obvious alternative solution, is still pretty sorry. you have to download an app to do it, it's not just a capability that a phone has by default. and then when trying to find an app to use for it, you're presented with a multitude of high-stakes choices, and often pretty technical explanations if you start internet searching about which app to use.
A reminder that mandatory iOS App Store / Android Play Store / (Xiaomi store ???) is even less acceptable than SMS 2FA unless maybe you're a USA(/Chinese) citizen living in USA(/China).
Sounds like discrimination of a broad group of people. Granted, it's not a designated protected group, like by national origin, but I still think they have a good chance in court.
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'm not sure where "absolutely" comes from. I'm not an attorney to make assured statements, I can only guess.
I'm not talking about unreliable SMS delivery, I'm talking about banks not accepting other options like passkeys, software/hardware OTP keys which are more secure than SMS, thereby discriminating a whole class of people "living in the mountains".
Yep, but in this case lawyer might try to make it a class-action lawsuit and work for a percentage. Up to the attorney, of course, if they are will to risk their time on that.
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.
No, I think he's mostly right but it is a little more complicated. Most services demand a cell number verification on account creation for user tracking and identification under the guise of security for you. The SMS 2FA setup flow just helps push the user into coughing it up and helps sell the security cover story. Theoretically this helps prevent abuse, but there's no reason they have to abuse the data themselves after getting it for that. Its just that they will. They'll even lie to your face that they only use the number for security purposes and then use it for advertising anyway.
I implemented 2FA for my previous employer and we would have gladly skipped SMS 2FA if we could get away with it. It's more expensive for the company and the customer. And it sucks to implement because you have to integrate with a phone service. The whole phone system is unreliable or has unexpected problems (e.g. using specific words in a message can get your texts blocked). Problems with the SMS 2FA is a pain for customer service too.
"Wi-Fi calling" (LTE over IP over wifi) often allows you to get SMS messages over wifi only, on an ordinary cell plan: https://support.apple.com/en-us/108066 (Android supports it too)
The part that was interesting to me in this article was that companies could somehow detect that the lady had a cellphone when previously the 2FA thing hadn't been a problem for her. I wonder if this was just poor timing or if places like financial institutions actually get an alert.
SMS 2FA is also quite expensive. In the US it's $0.0083 per SMS, which at bulk is going to add up quickly. Even before the war started, it was $0.70 to send an SMS to Russia. And then there's the premium SMS line fraud that's led to massive bills for some companies.
Isn't SMS 2FA immune to SIM swapping attacks when the SIM is an unregistered PAYG one?
i.e. there is no way to contact the carrier and get the number reassigned to a new SIM unless one first registers the SIM, and hence binds the number to a known identity.
It's not just people who live in the mountains that have this problem. People who do a lot of international travel see it too. There is absolutely no reliable way to predict the circumstances under which I will be able to receive an SMS.
Hey! I'm interested in that local AVL signal group. I've lived here for 6 years and I haven't met any friends because I'm a recluse with children. If you'd be willing to share, I would be greatly appreciative. :D
Voip.ms is fairly inexpensive (a couple dollars per month) and if you get an SMS-capable line you can set it up to forward incoming SMS to email.
Edit: I have not tested it with short codes
I exclusively use wifi calling because my home doesn't have cellular coverage, and have never once had issues getting SMS codes delivered. Seems like a provider issue on her end.
Why does SMS need a cell tower booster but the internet router doesn't need a cell tower booster? SMS will be much less bandwidth so it should be easier to receive than a whole web page.
The article does not support the title in my opinion. This has little to do with living in a mountain but more having an ISP that doesn’t support a lot of default telco functionality.
In Israel some providers started to offer code in WhatsApp (for example credit card companies). This ensures that if you don’t have access to your phone number (for example: abroad) you won’t be locked out of your phone while implementing the same security mechanism
Trying removing consent to receive text messages on that number, or that it's only a land line and only phone calls are accepted.
You might even try to block incoming SMS. In fact, you might also try a forward with Twilio or free Google voice number, since a lot of SMS TOTP refuse to with with those numbers :)
I've even had success removing my phone number entirely from certain types of accounts, but sometimes I had to deliberately break the account (eBay) and then it tries to get you to confirm on each login which you can sometimes bypass by changing the URL or clicking the company logo.
Be sure to have strong security in other ways; strong, non repeated passwords.
But this is truly insane. Large banks don't even offer the option of TOTP but instead require far more insecure SMS. Maybe they'll offer RSA dongles, because they never bothered to remember when they all got completely leaked ten years ago or how they accepted $10M to completely compromise their constants.
What can you say, large enterprises are behind the security eight ball, as always! It's a tale as old as time.
I travel constantly and this is a HUGE issue for me. It used to work with VOIP but now everyone wants to make sure they have maximum sellable data so they require mobile numbers. Also, clownworld security, which is totally bunk as an excuse on this.
Meh. SMS basically has the same problems as capability URLs for password resets. Sure, Mail is usually TLS encrypted these days, but they are still not regarded as secret.
That said, I still would prefer both over another shitty authenticator app that really gets on my nerves.
Additionally, I would like an option toggle with "Yes, I do have a safe and uncompromised password", where I can get rid of this crap.
Some 2FA systems do work if they don't ask more than once a month, but they are the exception.
Nice article, although I despise the "lowercase only" affectation that so many of us techies pass through. Capitalising the first letter in a sentence is a courtesy to the reader, not a stylistic choice you should impose to make yourself feel special.
Not only SMS 2FA, but in the past maybe couple years, many sites have been making their logins worse in many ways.
For example, I'm actually liking Walmart.com more than Amazon in some ways lately, but logging into Walmart.com takes minutes while I wait for the 2FA after I already password authenticate. So Amazon wins all the casual browsing and impulse sales, and by the time I do log in to Walmart.com, it's only because I know I want to order something from there specifically, and it's already feeling tedious.
Some off-the-cuff suggestions, since the worsening authentication experience really bugs me:
1. Present the email/username and password fields simultaneously, so the browsers like Firefox can fill out both fields. (A lot of site have started showing only the email/username to start, and also making that rely on non-login form field filling. And only after you type in your admin/email, because you don't form autofill in general, does it present
2. After user opts to authenticate with a password rather than SMS/email code, let them in, unless you're something like a bank or a medical provider. (Don't then make them do the SMS/email code anyway.)
3. If your mega online store handles HIPAA-sensitive data for some small percentage of visits, and you need 2FA for that, maybe only do the 2FA to upgrade the authentication confidence for session. (Or maybe the more sensitive data is on a different backend anyway, so as not to encumber all the developers implementing Wheaties logistics, with all the additional protections that are needed for medical records, nor to add additional weak links leading to leaks.)
4. When SMS/email 2FA is really necessary, send it immediately and reliably, and make it copy&pasteable. (Sometimes I wait minutes, and other times it doesn't come through at all. And I've even gotten email ones where competent-user text-selection picks up whitespace somehow, or even a weird unprintable Unicode character, which breaks the code entry when pasted.)
5. Those buttons to authenticate a variety of other sites are needlessly leaking information, and creating additional ways to compromise the account. (That's what you do if you want to reduce friction to first visits to your site, for which people aren't interested enough to create a password to use -- but not for logins from recurring customers.)
6. Don't prompt for "remember this browser?", and don't otherwise rely on the persistent tracking data deposited on the user's browser, across explicit authentication sessions, such as to decide whether to 2FA. For one reason, those persistent data mechanisms are overwhelmingly for shady abuse by the adtech/surveillance industry in shady ways, and are frequently cleared by privacy-conscious users. Any why is a bank, for example, complicating the UI, to ask ordinary users whether to lower their authentication security on this device, and expecting much sense out of that at all. Keep it simpler, more secure, and more responsible or respectable.
7. If you must support 2FA, make TOTP an option. And not TOTP-incompatible codes that requires installing your app, or that depends on some oddball third-party proprietary authenticator app/fob that seemed like a good idea at the time but is not a reason not to support TOTP. (You can still grandparent in the legacy proprietary 2FA, for those long-time users who've been using it, and be clever about not complicating the UI for those those dwindling users, nor for the increasing users using the more current open standard.)
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.
I kinda like client certificates, and have made simple uses of them, for Web services and occasionally corporate-internal humans.
But with the current browser support, client certs haven't seemed viable for consumer sites. Unless the browser developers are inspired to offer better support for mass consumer users, but I couldn't make a strong case why they should.
(I'd rather most consumer sites resume making password authn work well, and then have them integrate 2FA judiciously and well. And stop with some of the counterproductive surveillance capitalism mechanisms.)
> (I'd rather most consumer sites resume making password authn work well, and then have them integrate 2FA judiciously and well. And stop with some of the counterproductive surveillance capitalism mechanisms.)
OK, I agree, stop with the counterproductive surveillance capitalism mechanisms.
Making password authn work well (using the ideas you mention about improving it) and integrating 2FA (also improving it in the ways you mention), would also be OK, although that should be an alternative choice, so that users who do want to use X.509 and are able to do so, can use that more secure mechanism and not requiring other mechanisms. The 2FA really shouldn't be required especially when it causes problems (such as the ones mentioned in the "SMS 2FA is not just insecure..." article, but also such things as the set-up for 2FA not working very well in GitHub, some mechanisms requiring JavaScripts, etc); those who want to and are able to use X.509 should use X.509 instead.
Another thing that I dislike is the "security questions" such as your date of birth or your mother's maiden name or whatever, which do not help with security at all, and those should not be used at all.
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 dont care so much about passwords as I care about how annoying the current implementations are.
Passwords do have some benefits. They dont require a phone, it being charged, and fetching it 5 times to go through a couple services. They can be used from any machine.
Yes theyre not as secure, but as user Id prefer to be able to choose for myself whether I want to opt in for additional security. For most sites I dont even give a shit if my account gets hacked, and I have to go through a ton of annoyance everyday for no reason
"This terrible idea could actually be worse" is about the level I've come to expect. Congratulations, passwords haven't managed to be worse in every way than every possible alternative, mostly, yet.
> Dont you hate that every service requires you to give them your identity?
I have Security Keys, which are entirely anonymous†, so actually I have much better security and do not "give them my identity" since I am, as I said, entirely anonymous.
In 1925 the understanding needed to do this did not exist. In 1975 the technology to implement it would have been prohibitive. In 2025 it's easily possible and indeed I use one every day - and yet here you are.
> Do you think HN for example would be better off if they decided everyone now has to do 2FA?
As so often it would depend on the implementation. I have absolutely no doubt that HN regulars would have strong opinions about what they should or should not use to achieve this.
† Obviously the choice to be named tialaramex everywhere is not "anonymous" - with a little effort you can even connect that to the name on legal paperwork, but on the other hand I also have accounts which aren't named tialaramex because they're intentionally not connected to this identity, and those use Security Keys too, by design it's not possible to connect the two.
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.)
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.
Homeless people get free smartphones and free service in the US. Living in very rural areas is in fact a lifestyle choice. Not all choices need to be subsidized.
This kind of performative "empathy" people talk about in online forums is not true empathy. It's frequently the case that prioritizing this fake "empathy" results in bad outcomes. It saddens me when people use "empathy" to justify policy with strongly negative overall consequences. It's how you end up with, for example, the disaster zone that large chunks of San Francisco were before Lurie started cleaning up a few months ago. Or the deplorable state of our healthcare system.
You're bringing in all sorts of unrelated things here. The simple reality is that expecting a 70-year old to leave their entire life behind and move to the city just because of a relatively simple issue like this, is deeply and profoundly unemphatic. As is the general principle of not accepting that some people may want to choose a slightly different life from what you might choose for yourself. No one is asking the world here. These are small accommodations at best.
Nobody's asking them to leave their life behind! Talk about bringing in unrelated things! I'm saying we should recognize that lifestyle choices have consequences and that's OK. Not every consequence needs mitigation by third parties. Having to use a TOTP app and/or make a 20 minute trip into town to use some web services is not an unacceptable price to pay for the lifestyle choice of living in a remote area, and we shouldn't be vilifying people or branding them "devoid of empathy" for not prioritizing support for that use case over other, higher impact things they could do to improve their products.
People choosing to live in rural areas aren't freeloaders. Until they demand the rest of us subsidize them. The demand for subsidies is what makes a freeloader, not the lifestyle choice.
My original message was simply here to remind people that technical decisions we make have consequences on who can use our services.
You were the one introducing this vocabulary (as well as claiming everyone living there does it by choice). Now you try to move the debate again with people "demanding" stuff. None of this vocabulary or framing exists in the original article, or in mine.
Let me clarify the question: why do you insist on framing this debate in a way that makes a moral claim about people's character?
> Homeless people get free smartphones and free service in the US
Recently former homeless person here. The Republicans in Congress refused to renew the Lifeline program in 2023 and the replacement is objectively worse in every single way.
> Not all choices need to be subsidized.
Ah yes, being homeless, a choice. I hope it never happens to you.
Food doesn't come from remote mountainous areas. Farm fields may not have cell service but living way out there isn't required even for farmers. I grew up on a farm so it's funny when people on the internet try to educate me about farms as if I've never heard of them.
I must be imagining the farms that I pass in the mountains in the middle of nowhere when I go backpacking. Surely your argument isn't, "My farm was here, so it's impossible for other farms to be in different locales"?
The large trucks being loaded with crops for delivery elsewhere should suggest that it contributes to the greater food supply, yes. Further...
>I once...
My phrasing did not suggest "one time" (the phrase was "I pass", suggesting regularity), and it's not just one single farm, it's a few, and I've passed them many times. I have to agree with someone else[1] about your using vocabulary that others haven't introduced - I question whether or not a good faith discussion can be had because of that. Have a good one!
We should still be supportive of people who want to live in the mountains. I'd like to think that we as a society enable people to live how they want to live. Given that technology has allowed us to deploy broadband internet access pretty much anywhere, there is no good reason to deny them of e.g. web-based banking just because of some stupid SMS confirmation. Hardware 2FA keys are cryptographically superior AND usable by people in the mountains.
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 isn't about them. Montana by and large is a lot less dense than Asheville NC, which is a small city surrounded by normal towns. Asheville would only seem eccentric if normal is San Francisco.
> other options available to her include
> port her cellphone number to a VOIP provider that does support receiving SMS from shortcodes over wifi
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.
> 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.
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.
> 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.
> carriers charge a lot more for commercial customers
I've been used to unlimited free SMS for so long now (though I remember the days when it was limited), I forgot that commercial customers get charged for these
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.
May vary by institution, but both banks I have accounts with also support having a robot call my phone where I can confirm the login. That should at least work with WiFi calling.
I absolutely cannot stand that no bank I have (US) supports generic TOTP, which is more secure and easier to recover from backup if my phone is broken or stolen.
It's inexcusable.
This is probably compliance-related. For me, TOTP isn’t “something I have”, it’s another thing I toss into my password manager and sync to all devices.
I really agree with it, but that’s probably their rationale.
Banks didn't support TOTP long before we were able to easily sync them across devices. It's likely more along the lines of banks generally have bad IT departments and outdated digital security policies.
The real problem is not having a (trusted) way of seeing what you are consenting to by entering a TOTP (which can be phished).
SMS-OTP, with all its downsides, allows attaching a message of who you're paying how much to the actual code.
That same rationale wouldn't support SMS as "something I have." iMessage and other solutions easily spread SMS into cloud and PC lands (ones that are more easily accessible than password managers.) More likely it's because of legacy and "good enough" reasons.
Personally I don't put TOTP tokens into my password manager and keep a dedicated app for it, just in case my password manager is pwned.
I'm not really defending it, I'm explaining the mentality. iMessage is probably closer to "something I have" but yeah, often not true for many American users.
I'd probably keep a TOTP app if I actually brought my cell with my everywhere but I really don't feel like it; if I'm heading to a cafe to work for a bit I might need to access something and can't be bothered to bring two devices.
Plus, people increasingly access stuff from cell phones, so it's not a guarantee of "something you have" anymore. And no shot we're convincing everyone to start carrying some kind of hardware token.
You have to remember that cybersecurity is driven by what is secure so much as what is compliant, and increasingly so.
I do the same, and it somewhat defeats the spirit of 2FA, but I still believe it's more secure. It's basically a second password where intercepting it in transit once isn't enough to be able to repeat the login in the future.
One time password.
Yes, a digital OTP generator is more susceptible in theory to theft or duplication than a hardware token.
Yes, the benefits of digital OTP are great compared to password only, more secure than SMS, and trivial to implement.
There are hardware TOTP tokens that don't allow export of the secret, that makes them something you have. For example:
https://en.wikipedia.org/wiki/Digipass
My bank sends me 2FA codes in their app, which I then have to type into... their app. No kidding. Both the key and the validation in the same place, really ridiculous. Even something as crap as SMS 2FA would be better. TOTP or FIDO2 would be miles better.
TOTP is alright for logins, but it's generally very phishable. For transaction confirmation, not being able to tie a code to a given recipient and amount is somewhat of a dealbreaker.
TOTP is only marginally more secure. It defends against sim swaps but it still loses to phishing, which is far more common than sim swaps.
But it is easier to backup and restore, is accessible without a phone, and can be used without cell service.
Those are usability benefits rather than security benefits and I really don't know if I'd use the word "inexcusable" for this difference.
And for the vast majority of people, sms is much easier to backup and restore than totp because there is an infrastructure to help them do so.
Fwiw, Symantec VIP is TOTP under the hood, and you can extract the seed with some hackery. There is at least one financial institution in the US that uses that.
Charles Schwab uses this. I was able to extract the TOTP secret during the set up process to use in my preferred auth app.
USAA. Better than nothing, but since it doesn't do push notifications it's a needlessly proprietary piece. It's probably a combination of legal and a slow IT infrastructure.
Although they don't offer TOTP, I've noticed growing support for Passkeys which is a step in the right direction.
By brokerage suports TOTP but not my bank. My bank does support Yubikey-type devices though.
Vanguard supports Yubikeys. I'm yet to use a bank (~8 of them so far) that supports anything other than SMS.
There is at least one major US bank that supports Yubikeys and a different major that one supports (with some convincing) phone notification-based second factor.
Copper State Credit Union supports passkey
I've been using Citi and Discover for years with a Google Voice number. Possibly I've been grandfathered in though?
I could not use my Google Voice number (that I've had since Grand Central) for most companies that only do SMS 2FA until it became my Google Fi number. Then I guess some flag got set in the database they check against.
>I could not use my Google Voice number (that I've had since Grand Central) for most companies that only do SMS 2FA until it became my Google Fi number. Then I guess some flag got set in the database they check against.
I was wondering about that, because I can't get google voice because I have google fi, so clearly it's using the same bank of numbers, but maybe once they are fi, they are ported to T-mobile instead of their own CLEC.
They removed that restriction. You can have Fi and Voice on the same account now.
Yeah, I think that restriction was due to that extremely strange way of using Hangouts (remember that?) as a possible backend for both Google Voice and Google Fi text messages.
Chase bank used to not work with Google voice. I would have to use email for code. Sometime in last year? it started working.
yeah, I use GV with all sorts of things that don't normally allow most likely as a result of being grandfathered in - i.e., I suspect they don't recheck old active numbers as being invalid per VOIP classifications/etc.
GV still works on BOA to an extent: general balance queries through their app or the web will go through but anything involving identity and real transactions via wire or zelle will ask for your real mobile number. Even if you do happen to visit one of their branches they will ask for confirmation through your real mobile number (landlines will obviously not work).
Works for me with GV, for anything involving identity. I might have been grandfathered in.
I think your experience is typical. I use my Google Voice number for everything and have rarely had any issues.
There are a few popular companies that blacklist VoIP numbers, but most don't. Even Chase, which historically blocked Google Voice, started allowing it a couple years ago.
Mine has worked as well but it used to be a landline when I first acquired it many moons ago.
Execs at those companies probably think "Google = good".
I don't think SMS senders can actually tell the difference between Google Voice and other VoIP providers.
Twilio has a lookup API, which returns the subscriber name and carrier.
Here's an example response (subscriber name redacted):
Ah, I always assumed Google uses Bandwidth.com completely transparently – I wasn't aware there's a separate level of "line provider" look-up available. Thank you!
Yet Facebook won’t let me sign into WhatsApp using my GV number alone.
There must be something unique about my GV number. It's even allowed on WhatsApp (knock on wood).
I registered it about 13 years ago. I didn't transfer it from a landline/cell phone, it was picked from a list of Google Voice numbers available in my area code. I've never had Fi.
We actually had it that way on accident in a few of our applications - we had a `#isTextable(e164)` function that would do a carrier lookup and voip carriers sometimes returned as landlines or as arbitrary values that didn't mean mobile. We eventually did some work to refine that function to be smarter and actually better represent if the number was textable. At least for us, it wasn't a conscious decision, it was a gate being aggressive in our SMS pipeline.
>>> 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
Anon SIM cards are still allowed in some EU countries: https://prepaid-data-sim-card.fandom.com/wiki/Registration_P...
Yes in the Netherlands they're still anonymous
> anon SIM are no longer allowed in the EU
Ah. That explains why they asked for my life history when I tried to buy a local SIM in Italy.
Ironically, this is only true for prepaid SIMs. As a result, in some EU countries it's easier to get a month-by-month postpaid plan – sometimes there's no KYC at all for these...
When did this change happen? I’ve done local SIM prepaid all over Europe over the past decade, but not so much recently
It didn't. It's still up to each country. There's still several without mandatory registration.
> anon SIM are no longer allowed in the EU
Surely Ireland still allows them? If not, they're trivial to source from NI.
Yes the problem with UK ones though is that they route all the traffic through a prude proxy if you don't register. Because the UK is getting back to the Victorian era.
I had a SIM from three Ireland that tried to apply this UK policy also on the republic of Ireland customers where this is not required. It was unusable, it blocked pretty much everything it didn't recognise like VPNs, even email servers. Luckily there's many sane providers there too. And no they don't require registration.
> SMS is the only 2FA method that can be easily deployed at scale
No, no, no, no, NO. No it's not. And you have zero proof of this. Its done this way because its the lowest effort to give security theater.
What's the theater with sms 2fa? That is more secure than not having it enabled no?
Possibly less secure, considering the existence of sim-cloning crime rings. SMS 2-factor potentially gives a hostile actor a way to 'prove' that they're you.
What's the actual method that can be easily deployed at scale then?
I'd argue that there isn't one: you have to offer multiple choices. Auth through any TOTP app, Yubi key, pre-generated codes, mailing a physical code generator, etc.
Email + SMS + generic time-based OTP seems quite enough for imho
> 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)
I don't think that's true. Is there even any way for banks to ask your mobile operator for your identity (or confirm it), in the way that US banks seem to be able to? That seems like it would run afoul EU privacy regulations.
And regarding the EU "anonymous SIM" regulation: That one ironically only seems to apply to prepaid cards. To my surprise, I was just able to register a postpaid line using no identity verification whatsoever a few days ago...
> 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.
The "thing you have" is actually the SIM card. That's supposedly why email OTP does not count – an account on some server is not, or at least not cleanly, "something you have". (A pretty poor decision, IMO, but that's a different story.)
> 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)
All demographics except for people that change phone numbers frequently. All locations except those that don't have cell signal (or for plans without roaming). All mobile devices except those without a SIM card slot. An authentication solution for absolutely everyone! /s
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
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.
>>> 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 was under the impression WiFi Calling was just regular phone service through WiFi. It seems to work that way for me, 2FA codes and all.
VoWiFi (as Wi-Fi calling is called in the 3GPP specs) is similar to VoLTE, but not all SMS go over VoLTE: Unlike for calls, where there's mandatory VoIP in 4G/LTE and beyond (there is no more circuit switching), there's still a fallback path for SMS that uses legacy signalling instead of IMS (which powers VoWiFi and VoLTE/VoNR).
Maybe there are some SMS gateways that are somehow incompatible with some IMS message gateways? (Theoretically, the IM-SM-GW should be transparent to external networks, I believe, but practically I wouldn't be surprised if some weird things lurked in there, requiring a fallback to the signalling path, which is not available on VoWiFi.)
WiFi calling seems to depend on your mobile service provider to provide the service. I guess different networks do it differently.
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.
Unfortunately there are a lot of "is this number voip" services that use various tricks to detect voip numbers, or simply buy this data from the voip provider or someone else in the path.
If nothing else, if a particular voip provider only does voip, you can just put them on a blacklist. You can get any number's provider from the number portability clearinghouse (this might be country dependent, where I live, there's only one, and anyone can query it).
"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.
> 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.
Exactly, and I simply refuse to do their work.
... and they have decided to ignore you as a customer, because the risk of allowing VoIP numbers is greater than you are valuable.
So, everybody wins. :(
> 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.
SMS itself is just fine, the problem is companies making me use it in ways I don't care for.
> SMS itself should be illegal, period.
Why ? I still send SMS. Wifi is not available overall. The Google SMS app is not able to retry sending when connectivity is back and the UI is enshitified, but this is norm in modern software.
She just needs a microcell/femtocell.
Talk to your provider, explain to them you get poor service at your home or place of work, and they'll send you a free Internet-in cellular-out radio AP. She doesn't need a tower-based booster if she's got fiber/cable/DSL, those only serve to amplify weak signals and she's too many miles and too many mountain ridges away from the nearest tower, she wants something with RJ-45 input, a little GPS antenna so the cell supports e911 location data, and it will broadcast LTE (or now 5g) cellular data.
I work at a shop with metal walls located in a river valley. It's a cellular data black hole. People used to climb the hill up the driveway to make and take calls, but various people called their ATT, Verizon, and T-Mobile providers and all three shipped us femtocells. Mow the users and the contractors/customers who come to visit can't even tell that their phones have switched to data over our ISP instead of a tower, it just works - including 2FA codes and MVNOs.
She may have to switch to first-party Verizon service instead of using an MVNO.
It seems t-Mobile no longer offers such hardware: https://www.t-mobile.com/support/coverage/4g-lte-cellspot-se...
Maybe T-Mobile doesn't need to. I've used their WiFi calling for, what, going on ten years probably. Works a treat, including getting short code SMS. Ergo, I don't know the use case for femtocell for T-Mobile. That's why I was surprised to learn via TFA that WiFi isn't the solution in all cases.
The use case is anywhere Wi-Fi and cell coverage is spotty or nonexistent. There are probably plenty of t-Mobile customers in that position.
We moved to a T-Mobile femtocell precisely because their wifi calling was absolute shit in our experience. Dropped calls, no group SMS, no SMS/RCS images, frequently no calling service at all. The femtocell fixed all of that for us, and it has remained fixed.
> 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.
They do not have to receive GPS, but it causes issues for e911 service if they do not. It has no impact on anything else, at least not the T-Mobile version.
The one I had, an AT&T Microcell, which was the only model offered by my cell provider, refused to work without a GPS signal.
The one I had, an AT&T Microcell, which was the only model offered by my cell provider, refused to work without a GPS signal.
Strange, because my AT&T Microcell didn't require a GPS signal. I kept it in the cabinet under the sink deep inside a large apartment building where there's no way it could get a GPS signal.
I haven't used since I moved a few years ago. Perhaps it's changed.
See:
https://paulstamatiou.com/review-att-3g-microcell
"After giving the MicroCell some power and ethernet, it will start blinking the 3G and GPS LEDs. Wait, what.. GPS? Yep. To limit the MicroCell from working outside of test markets (or out of the country too), it must get a GPS lock on your location. AT&T suggests this should take no longer than 90 minutes. It took me about 5 hours."
And this was the fundamental problem: there was absolutely no way to know if progress was being made or if it was going to run forever. It was literally a real-world Halting Problem.
Similar experience here a few years ago w/ a Verizon microcell device. It wouldn't service clients w/o a GPS fix.
Maybe https://av.tib.eu/media/36387 or https://www.eevblog.com/forum/rf-microwave/sdr-as-gps-emulat... is a possibility.
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.
>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.
A lot of office buildings have these in them. I think the personal ones are how they get around some of the issues with government requiring them to build networks to certain coverage. They just don't build it out and when someone complains they offer them one of these.
A lot of office buildings have these in them. I think the personal ones are how they get around some of the issues with government requiring them to build networks to certain coverage. They just don't build it out and when someone complains they offer them one of these.
Also because a lot of office and residential towers have people high above street level, and the buildings have radiation-minimizing windows so that no cell signal can penetrate. The cell companies put their sites 30 feet above the street, not 600+ feet up.
Femtocells are remotely controlled by the carrier, they require GPS location (and maybe spectrum sensing), and I assume the backhaul is over VPN. Obviously they can't guarantee any QoS but it's better than having no signal.
(Fun trivia: Our office paid $XX,000 for AT&T MicroCells which wouldn't activate because they couldn't get GPS signal.)
Eh, assuming it's 4G LTE (or above), it's literally the same thing as Wi-Fi calling. This is technically called IMS (IP Multimedia Subsystem, https://en.wikipedia.org/wiki/IP_Multimedia_Subsystem), and is powered by "magic" DNS (no kidding, everything points to 3gppnetwork.org) and literal IP + IPSEC. Even when your phone is connected to Wi-Fi, it enters a special mode called IWLAN which powers your Wi-Fi calling, SMS, and RCS. The only actual factor here is if the ISP that you have versus your mobile network has a good peering.
No, in this case the consumer femtocells on the market (AT&T Cell Booster, Verizon LTE Network Extender) are actual eNodeBs inside the carrier’s RAN. They will IPSEC tunnel back to a security gateway (SeGW), grab provisioning information, and then come up on the carrier’s commercial license as just another (fancy low powered) LTE radio on the network.
AT&T did try to add some additional tamper switches and protection inside their units so they’d brick if you opened them - that was known since the MicroCell era. I believe T-Mobile’s former CellSpots were also tamper-protected in the same manner (they both deployed Nokia LTE small cells).
AT&T also appears to now charge you for the privilege of deploying the newer Cell Booster Pros if you want 5G - I assume that cost ($30/mo per cell!) is basically covering licensing the backend for all of that.
Wi-Fi Calling uses a different SeGW endpoint and is pure IMS back to the carrier voice network, regardless if you shoot it over WiFi or back over a dedicated APN on the LTE network in the normal VoLTE fare.
Thanks for adding some information on this, I had almost forgot about these devices.
So would a cell booster / network extender using eNodeBS ( https://en.wikipedia.org/wiki/ENodeB ) actually help in the scenario in the original article?
Or would it end up as the same issue with wifi calling, where "messages from 5 digit shortcodes often aren't supported over wifi calling" ?
Thanks for injecting some hard facts into this. Too many folks don't understand the difference.
If the device is remotely managed and all IPSEC back to the carrier, who cares what network it's on? At worst you'd just get poor connectivity, I don't think there's any additional exposure here.
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.
Some of the comments pointed out that this is hostile behaviour for people roaming as well, and I completely agree. Here is my solution for this : 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 : https://f-droid.org/packages/tech.bogomolov.incomingsmsgatew.... Every time I receive a SMS I forward it to this API. The API in turn emails me the whole message.
I have been using this setup for a few years now without any issues. Even when I am not roaming, I still have this setup on my primary phone. So when I am on my computer and need a SMS OTP I don't need to go find my phone, I receive it in email :-).
(Note : This doesn't work with MMS but I don't need them anyway)
"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!
Looks like this might stop working soon unless this process works without logging into the phone: https://mashable.com/article/android-smartphones-automatical...
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 hate SMS 2FA because of roaming: I'm from one EU country that lives in another EU country. I still have my origin country sim, but it's a prepaid that I can top-up twice per year to keep alive (but because it's prepaid, I can't use roaming with it unless I buy the most expensive option and if I go back to origin country something like once every 2 months). Now I need SMS 2FA for certain services in origin country, and those services don't allow any other numbers outside of the country (why I still keep the number to use when I travel back to origin country) or any other type of 2FA. So basically phone 2FA is useless and a blocker.
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...
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?
Technically you are right, the SIM card isn't roaming, but I am physically roaming outside of my home network (internationally).
Some phone plans in my home network do not support international roaming, or if they support then it is ridiculously expensive that it doesn't make any sense to take the phone roaming.
A lot of US carriers charge per SMS when roaming (as if it were 2006).
Sure but with 2FA you only recieve SMS so so what?
Some plans in the US charge the recipient of an SMS.
That is unheard of in Europe, so makes no sense to you - hence the confusion.
It's also often the case that prepaid plans or smaller carriers in the USA don't offer international roaming.
Wait what?
So if I buy 10.000 SMS for cheap on Messagebird I can "denial of service" your phone bill?
What, lol?
Just trying to answer a question:
>> Some of the comments pointed out that this is hostile behaviour for people roaming as well
> I’m sorry how is this related to roaming?
Google Fi can receive all SMS 2 factor messages on Wi-Fi including short codes. It doesn't even require that your phone is on, you can get them in any web browser on any device even if your phone is destroyed. One of my favorite features.
You can get service starting at $20 per month. Fi used to have good service in some mountain areas too, with US Cellular. Not sure what's going on with US Cellular right now though. Some kind of half acquisition by T-Mobile.
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.
>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.
To be somewhat more specific: while I travel extensively and am in the US often, I am often outside of it for more than a month at a time, and it appears that Google will shut off data outside the US if you use data outside the US for too long. If you are using a different SIM for the primary data connection, it appears that they won't even if you have it enabled as a backup.
I just came back from 3 straight months in the UK with google fi and had mobile data for that entire time.
Perhaps it's country dependent? Or based on other metrics? I wasn't a heavy mobile data user, but didn't intentionally avoid it either...
My comparison here is actually that I've never had it shut off. I'm not quite sure what the criteria are. I do have a friend who had it cut off after a few months of using it for all his data in the EU.
compared to prices for the rest of the world, you wouldn't want to use Fi for data anyway... just get a local or even "travel" esim and run with dual sims.
I’ve found that it’s easy to data-only eSIM package through an app store app such as Saily, but it’s harder to find a service that gives you a “real” phone number when traveling internationally. Any recommendations?
I don’t have direct experience, but I’ve heard about or seen the following online (there may be many other MVNOs). All of them are activated with an eSIM and they have WiFi calling, which means it’s a real US phone number as any other and you can make/receive calls and send/receive SMS as long as you’re connected to the internet via WiFi or through a data connection on your second SIM on the phone. If you wish, you can buy real roaming too, but that tends to be expensive.
* Tello
* Red Pocket
* Good to Go Mobile
If you’re looking for a real local phone number in the location you’re traveling to, then eSIM providers like Airalo can handle that (Airalo has “global plans” that support voice and SMS). Getting such a connection for voice and SMS, as compared to a data SIM alone, would be expensive. So you could get a data eSIM that works locally and use that for “WiFi” calling/SMS with the providers mentioned above.
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).
Yeah no it still disables RCS which is super lame now that iPhones finally support it. I hope Google gets around to fixing it someday. I'm not holding my breath. I'm just happy they didn't kill the feature when hangouts died. The URL changed, it's now https://messages.google.com/web/
Google Fi charges $10 PER 1GB of data. US Mobile is cheaper and offers the top 3 providers in the US.
Something somewhere is always hostile to particular group. That's just facts of life. You do your best to minimize but can never eliminate it.
As someone who has dealt with 2FA support, all the methods suck.
SMS 2FA is least secure but has broadest support with quickest recovery method.
TOTP Applications (Google Auth, Authy, iOS Passwords) is more secure but people switch phones, lose phones and so forth and recovery is always a nightmare.
Yubikey and like have cost problem and you still have recovery problem.
A clear solution in my mind is having the Federal Government run some form of centralized hardware based system where hardware could be replaced by government office after verifying identity. Government does this already for DoD CaC cards. However, in the United States, Privacy Advocates would lose their minds, and funding would constantly be under attack.
So yea, I get SMS 2FA is hostile to mountain people but 2FA is hostile to login services and executive yachts.
> 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.
For banks an other cases that (1) need to know you true identity, and (2) provide no expectation of privacy regarding sharing the existence of accounts with the government, a government run authentication would be fine from a privacy point of view.
The issue is that every site has moved to using 2FA, and most of them have no legitimate need to know your true identity. So using a government ID based solution would unnecessarily conflate authentication and identification and would be a real privacy concern.
Can you offer an example of a situation when the second factor authentifies without identification?
Assume a service S wants a confirmation that user U is indeed legitimate. The centralized auth service A could receive from S a bunch of data S knows about U, like name, address, phone, SSN, whatever S needs to know about U. Then A should respond whether the fields match the data which A knows about U, without revealing to S any additional data that A may know about U.
The problem if a centralized service is that it's a SPOF, and the juiciest target for compromising.
I still think that TOTP and personal crypto tokens like yubikey are the most resilient, and technically the easiest, solution to that.
Any TOTP where the user enrolls it on account creation, without going through a third-party service. Or SMS on a burner phone. Both are pseudonymous, since using the same authentication at multiple sites could be linked, but neither have to be tied to a real-world identity.
Any system in which the government can re-establish account access on my behalf is a system in which the government can access my account without my knowledge. No thank you.
If you mean the government just replaces hardware and re-establishing access is up to me, that’s no different from Yubikey.
In most cases, they can just subpoena the system and get all your data that way. Probably get a judge to sign off on subpoena coming with hush clause.
> 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.
Yes though you have to do that manually on every site you used it on. Not great once it becomes more supported.
Yea, users never do that.
>Government run some form of centralized
Nah I am good thanks.
Much agreement with the others that there's too much expectation. I rented a lime scooter for the first time last year. But, I messed up my VPN settings so I had no Internet. There was no way to tell the scooter I'm done. Even though it was stopped, no button to end the ride. They refunded me the extra time (which was maybe 5 of the 10 minutes) because they could see it was just stopped at a bike rack on gps. Idk what I'd do if my phone died or any other reasonably possible things when you're out and about and on a scooter.
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.
Are you sure that the locker has an Internet connection?
Requiring Bluetooth and an Internet connection on your phone suggests that that's exactly what they removed on their side. Quite clever, if true – why pay for network connectivity if you can just piggy back on your customers'? (Nevermind those customers without a smart phone and data plan...)
> Are you sure that the locker has an Internet connection?
Let's put it like this: The old ones (with a display) definitely do, because they can send email notifications. I would be very much surprised if the new ones didn't. The main reason for requiring the app isn't connectivity to the outside world, it is that they can save money on the terminal screens, which get vandalized frequently in some areas. The internet connection is probably a fraction of the cost of replacing those touch screens every few months.
Reminds me of a cashless hotel laundromat that I had to use that didnt accept coins, tokens or had a credit card reader. So to wash my clothes I had to find a charger to charge my phone, download an app, being able to receive SMS 2FA while roaming which is a hit or miss depending on roaming agreements, having working internet connection, enabling Bluetooth and Bluetooth Nearby Devices, and then top it up with a foreign credit card. It took about 30 minutes to set it up.
I guess this would be easier in a beighbourhood laundromat with local clients, but in a hotel with many foreigners it becomes a pain with so many dependencies needed to use the washer and dryer.
1) It's possible they do not have an Internet connection. In fact, it doesn't seem necessary.
2) Bluetooth can ensure that you are in proximity of the locker, otherwise you could accidentally unlock a locker while standing at the wrong rack.
They always had internet access. Of course it is possible that they decided to rip out the internet connection in the new models together with the touch screen, but I heavily doubt that they want to trust the internet connection of a random stranger to do whatever important communication they have to do with their servers. The app only requires internet access because... well, it always needs internet access.
I'm currently developing firmware that supports both Bluetooth and cellular connection for a hardware device. With proper cryptography, you don't have to trust the random stranger (e.g. using TLS). In fact, you can get away with no connection at all. For example, when someone locks the locker, it sets a "password" via Bluetooth and when you open it, your phone simply transmits the "password" via Bluetooth.
I'm not just thinking of trust in terms of whether the device will tamper with the data, but also stuff like: What happens if you just put the parcel in the locker and in that exact moment the internet connection cuts out? Normally the parcel locker would send some data to DHL servers (as made evident by the fact that the lockers can send a confirmation mail), how do you get that information out now? Of course you could queue it up until the next person arrives, but all of that seems... suboptimal to me.
Cellular modems and data plans can be expensive and unreliable. If you can do without, at the cost of very rarely being out of sync (like in your scenario), it can be considered an interesting tradeoff. Plus, even if they were equipped with cellular modems, they probably have a business requirement that the locker should be usable even when the cellular connection goes offline, so you have to design your protocol to be Bluetooth-first.
TOTP, HOTP.
SMS needs your number, 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.
>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.
I don't understand how this post stacks up against the myriad of communications apps that not only require phone verification when creating a new profile (and maybe SMS2FA), but put great effort into blocking as many VoIP/burner/prepaid numbers as possible.
"Most"? maybe "a troubling few"?
Phone verification is absolutely a widely exploited data mining opportunity, I don't see how it's a red herring at all. It's one of the worst surveillance mechanisms we live with today, only partially waved away with the 2000's concept of burner numbers.
To single out Meta properties, I'd point to both Instagram and WhatsApp. It was an official policy early on that you could only create a WhatsApp account if it was connected to a "real" cellular number, I think the same has been true about Instagram for a while in that every time I tried to create an account without a cellular number it didn't work. Put in a cellular number and it worked just fine.
Last time I tried to create a throwaway account for facebook it didn't actually ask for my mobile number. Just automatically banned me for being suspicious and then demanded a video of my head with no assurance that would actually help. I generally avoid meta but it seems like most craiglist sales have moved to facebook marketplace.
yes marketer gets your name from bank etc, you can not lie there about your name. and everywhere else, your data is connected just your number.
same problem with signal messenger or facebook messenger building databases of numbers and contacts. neo4j clone from palantir.
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/
Yeah this is a big problem. I have been sent 2F messages via WhatsApp by some services (e.g. PayPal).
This isn't great, but better then SMS and having to have a separate app for each authenticating service though.
A vendor neutral service would be a lot nicer.
only system which does it securely is bitcoin cold wallet / offline computer signed transaction
or as you pointed out, signing it on smartcard with keypad reader.
but for login TOTP is better then anything else. i can put it on arduino with small oled board and have it in safe/vault offline.
and there is no way for attacker to MITM, and here lies the problem. companies can not blame you as easily as with currently deployed technologies... they hide breaches all the time, f... PCI
> but for login TOTP is better then anything else. i can put it on arduino with small oled board and have it in safe/vault offline. and there is no way for attacker to MITM
There totally is! How do you know you're entering the TOTP on a legitimate website?
WebAuthN prevents that, both by not letting you use a given key on the wrong website, and by including the origin in the signature generated using the key which the relying party can then check for plausibility.
1. Download the Google Voice app. This phone number works for some but not all 2FA services. Not all, because some explicitly forbid GV numbers because they're afraid of fraud. GV can receive SMS messages over wifi.
2. Ask the cell phone company for a femtocell. These used to be called "AT&T Microcells" and they were cheap. I used one before cell service improved because I live in the mountains. But apparently AT&T don't make them any more and now they cost $2500.
https://www.waveform.com/products/verizon-network-extender-f...
3. 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; I use it because I find it easier to use my laptop keyboard to type SMS messages than to use my thumbs on my phone.
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.
> Apple's satellite messaging service is the only solution I know of that can somehow hook into carriers' SMS home router
Are you sure it actually does this?
I thought it was a pseudo-carrier that could speak MAP / Diameter, and just pretended you were roaming with them when you used satellite connectivity, perhaps with the original carrier's knowledge and consent.
As far as I understand, that's how this kind of service usually gets implemented.
I assumed that that's how it works because I couldn't think of any other way to achieve the observed behavior, but pseudo roaming sounds plausible too, and presumably requires much less work on the carriers' side!
Would that approach also allow the extra functionality they seem to be offering, such as only recently messaged numbers and emergency contacts being able to send messages to satellite users, though? I suppose they could just reject all MT-Forward-SM with sender numbers they don't like?
> As far as I understand, that's how this kind of service usually gets implemented.
Do you have any other examples for solutions like this? Are you thinking of (pre-VoWifi) carrier apps or services that could receive texts, sometimes on multiple devices?
> Do you have any other examples for solutions like this
I have a vague recollection that Pebble had something like this to get texts on the Pebble watch.
> Would that approach also allow the extra functionality they seem to be offering, such as only recently messaged numbers and emergency contacts being able to send messages to satellite users, though?
Hmm, you could definitely do this with a "Stripe-like" approach, where the actual traffic goes over the usual protocols to ease implementation, but the carriers provide Apple an API to query messaging history in some way (which they probably already offer in their apps, and so have good integrations for anyway).
Stripe uses this pattern for fraud detection. Their card transactions still go over the antiquated ISO protocols from the 80's, because that's just what everybody integrates with and agrees on, but they can also speak a custom API directly with participating banks, mostly for better fraud detection and fraud-related information sharing.
Sms and signaling system 7 are incredibly insecure. It has to be so it can support scammers that call you from spoofed numbers.
Anyway, it’s probably possible to make a service like that. You might need to route through a country with permissive laws.
SS7 is very insecure, yes, but intercepting inbound SMS is still orders of magnitude more difficult than spoofing sender/caller numbers.
Allowing SMS interception without the home network's consent seems like a quick way to get offboarded as a roaming partner.
The real bonus to security here, access to your SMS is protected via MFA.
TOTP are okay for some things but often regulation means each code/challenge needs to be tied to a specific action. TOTP codes typically last for 30s and mulitple actions can happen within 30s, so it's not possible to use TOTP in many cases.
PUSH approval could be used instead but then you need to download an app for every service you use, which isn't very convenient.
PASSKEYS offer a solution which will work on both web and mobile and don't require you to download an app for every service. But it's a new concept that people need to learn so how fast they will be adopted is yet to be seen.
> 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.
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/
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.
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.
TOTP isn't phishing-resistant, which is the whole ballgame. I've had the job of working on authentication for highly-targeted mass-market systems, and code-generators basically don't work: they raise the bar on phishing attacks to a level phishers still easily meet.
TOTP and SMS 2FA prevent credential stuffing attacks, which is very valuable considering how bad people are with password reuse and how many breaches with plaintext or weakly hashed passwords there have been.
Yes, but other authentication factors also prevent credential stuffing, as well as phishing, which is probably the most important problem in authentication.
I hate email 2FA because I purposely don't have email on my phone. Unless I'm in front of my computer, I'm unable to log in to websites that use email 2FA.
Have you considered installing an email client on your phone, but not giving it the credentials it would need to fetch mail from the mailboxes you don't want to be tempted to look at when away from a keyboard?
It's basically all one mailbox, but lots of forwards, so that wouldn't work. But my reasoning is not so much because I'd be tempted to look at email when AFK, but more for security: I don't want email to be accessible from my phone.
Oh, this happens to me. I didn’t even realize that’s why I wasn’t receiving some sms codes, because sometimes it works and sometimes it doesn’t. I live in a rural area and have spectrum for both wifi and mobile (just like the woman in the article). I have some cell service, but depending on how strong it is in any given day am usually relying on wifi for calling and sms.
SMS codes have been hit or miss, and this explains it well.
This made me wonder whether it would be possible to build a Wi-Fi-only, roaming-only carrier for computers.
Your carrier is already capable of redirecting your SMS messages to other carriers, that's what they do when you're abroad and roaming with a foreign operator. You could make a fake carrier that speaks the right protocols on the roaming side, but communicates with the customer over the internet (using an API or a proprietary app) instead of LTE or GSM.
This would essentially work like an SS7 redirection attack, but with the full knowledge and consent of the "victim." You could alleviate the security impact here by requiring SIM card authentication, just like a normal carrier does, which could be performed through the internet and an USB reader just fine.
Carriers would probably hate this and might not be willing to sign roaming agreements with such a company. I wonder whether a gray-hat route would be possible here, especially if the company was outside US jurisdiction.
> 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.
> congress would have to pass a law forcing them to do it
Well, I'm not so sure about that. SS7 redirection attacks exist, so clearly shenanigans like these are very hard to stop for carriers. The question here is whether such "attacks" are legal if performed with the consent of the customer, but against the wishes of their carrier.
One could also do some "legal optimization" here, and ally themselves with a major carrier outside the US. There are plenty of those, and all of them have access to the networks (SS7 and IPX) on which roaming happens.
"SS7 redirection attacks" means, more concretely, "hacking into some phone company that's connected to the one you want to redirect, and using that system to send false data to the one you want to redirect".
It's BGP hijacking but for the phone system. If Comcast is connected to Verizon, and I want to hack your connection to Google, and you're on Verizon, one of my options is to hack Comcast and have Comcast tell Verizon that Comcast has a really fast connection to Google. It might let me intercept your traffic if circumstances are good; it's also fraudulent and illegal through and through. If caught, I will go straight to federal prison.
(Of course the analogy isn't 100%. The set of things you can do by hacking one side of a SS7 link is not identical to the set of things you can do by hacking one side of a BGP link - in particular, there's no BGP roaming. But it's a similar principle.)
I remember in 2014 going to play a Bitcoin poker game at some Google VP's house way up in the hills, Charlie Lee was there. We tried to buy-in at the beginning to a pot address but no one could get their Coinbase SMS 2FA to work because we had no reception so we ended up writing IOUs on scraps of paper.
Along the same lines, am I the only one who thinks it's weird that when logging in on a desktop PC the average bank requires a:
- username
- password
- one time generated 16 digit number
- SMS confirmation
- email confirmation
- phone call with an associate
- retinal scan
- DNA sample
Whereas to log in on mobile all you potentially need is a 4 digit pin which a passerby could easily observe, then yank the phone from your hand?
And keep in mind you have everything stored on your phone, too.
Where does the trend of not capitalizing the first word in a sentence in techie blog posts come from?
> you have to download an app to do it, it's not just a capability that a phone has by default
Luckily this is starting to change. Apple's Passwords app does TOTP out of the box.
Though I am mystified why Google Authenticator doesn't come pre-installed in Android.
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.
TIL! Thanks, I had no idea Passwords did this until now.
Doesn't this kind of defeat the purpose of MFA in that you now have both factors within the same application?
You don't actually need MFA. This whole thing came about because people reuse passwords between websites and websites have their databases hacked all the time so the same password can be used to log in on other sites.
2FA codes solve that because you can't reuse them between websites so one website getting hacked doesn't expose all of them.
You can easily reuse TOTP between websites, but not many websites let you set your own TOTP secret. They could easily do the same for passwords, but none do.
SMS 2fac isn't any better in this regard, since you typically receive the SMS on the same device that stores your passwords.
If cell service is available in at least one area of the property, you could have a dedicated sim for receiving SMS 2FA and use a 4G router to forward the SMS to an email, e.g. Teltonika have this functionality [1].
The 4G router also has the benefit of being able to use externally mounted antennas. Which might help in low signal areas.
Not ideal, but might at least be a solution for some people.
[1]: https://wiki.teltonika-networks.com/view/SMS_Forwarding_Conf...
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.
Yeah wont work for everyone, but a directional antenna mounted high up on house might have a better chance than a phone antenna.
The idea of mounting a directional antenna "high up" on a house (or paying someone to do it) for the purposes of receiving SMS 2FA seems wild.
You can also get antennas with suction cups. I have used this before to get 4G internet in a house with no access downstairs, by sticking the antenna on an upstairs window.
An outdoor antenna would be better, but yeah more of a pain. I guess it really depends on how badly someone wants SMS.
MOUNTAIN valleys, need to get WAY higher up than the top of the house.
The point of SMS 2FA is not security and never has been.
The point of SMS 2FA is tracking.
It's to force you to give them your phone number, for their own marketing, but also selling your customer profile to companies like Palantir.
This also makes the government happy, because they can scoop up your SMSs and they get a nice handy list of every service you use which makes warrants easier, but also gives them info about when you log in or do other actions on those accounts.
SMS 2FA costs these companies far more than TOTP would, but they still use SMS 2FA. That tells you everything you need to know...
I remember running in to this problem in university too where one of the basement lab rooms didn't have cell service, but we had to log in to the school computers with our university accounts that had mandatory 2fa
also was surprised to learn from the article that some carriers don’t support the 2fa 5 digit numbers over wifi calling/sms. when I travelled abroad recently that was such a life saver since my carrier supports it
This is a problem with her carrier or her specific account provisioning. SMS over WiFi calling works just fine, including from short codes.
I'm often traveling outside of the US, and my AT&T prepaid line most definitely does not roam outside of CAN/US/MEX. I spend the bulk of my time in WiFi calling mode. I have never had any issues receiving or sending SMS over WiFi, including to short codes.
TOTP might not be perfect, but they don't need networking. There's absolutely no reason a third-party or the server needs to maintain a source of secrets on demand needing to be sent over a network when the user can maintain an offline-capable 2FA generator themselves.
I'm not sold yet on non-portable, proprietary passkeys.
"it turns out messages from 5 digit shortcodes often aren't supported over wifi calling."
This does not seems plausible. I live in urban area but do not have good cellural connection at home and my mobile phones are usually route calls via home Wifi. All SMS come through. It is just a low-lever transport and I doubt it cares about message size or numbers.
Short code SMS goes through different providers than regular SMS, so the deliverability will differ.
I wonder what the companies requiring 2FA think about uncompleted 2FA bounces. Deterred fraudster? Short attention span? SMS sucks?
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.
There's really no reason to use SMS 2FA for GitHub though, you can literally pick anything else.
Anything else could be lost. I can always get new SIM card for this number. I don't need to backup it and I can't accidentally delete it. That's the biggest reason for me to link phone number everywhere. I'd hate to lose access to my GitHub account.
I don't see how I could simultaneously lose my three hardware keys (laptop, phone and Yubikey) and backup codes.
It's also not very hard for scammers to get a SIM card for your number, unless you're using a carrier that specializes in not allowing SIM swapping attacks.
That's why 2FA is called 2FA. It should require two factors. SMS + Password, for example. So scammers would need to steal both password and perform SIM swap, which hopefully is a bit harder.
I dislike SMS 2FA and services that use my phone number as a stable identifier, however SIM swapping is not really a thing in most countries.
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.
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.
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 did some digging, and it turns out messages from 5 digit shortcodes often aren't supported over wifi calling. sometimes they are, but in her case they're clearly not.
This seems like a rather specific problem that isn't related to mountain people as such but services blocking "shortcodes" apparently for a variety of reasons. It is true that text and call reliability is becoming a real problem generally where you have these authentication issues. I myself in the mountains and have dealt with reliability issues.
Here's a discussion of this specific problem with T-mobile: https://www.reddit.com/r/tmobile/comments/ardcnc/aargh_final...
She should switch cell phone providers. I’ve never had a problem receiving 2FA SMS from five digit numbers over WiFi, and heavily rely on it working. I know this for sure because I have an automation set to put my phone in airplane mode + wifi when I get home. (It eats battery when there’s a weak 5g signal.)
SMS 2FA is terrible though.
> and TOTP, the obvious alternative solution, is still pretty sorry. you have to download an app to do it, it's not just a capability that a phone has by default
iOS Passwords can serve as your TOTP authenticator app.
https://support.apple.com/guide/iphone/automatically-fill-in...
This is a really good point, "cell service will always be available" is a classic incorrect assumption that needs to be shattered. I do kinda wonder what the correct way forward is, I think it's silly that ISPs don't support this type of SMS over wifi but I have no clue why. Meanwhile TOTP apps are rightly pointed out to be too numerous with unclear trade offs, I'm surprised ios and android don't have native TOTP apps (afaik).
As an aside, I hate the nuance-less "SMS 2FA is insecure" line. It's the weakest 2FA form for sure, but it's still so much better than not having 2FA. Even if you support multiple options depending on your product it may very well make sense to stick with SMS as the default to reduce friction.
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.
Many of the big companies seem to really want you to use their app so there's this big game of smoke and mirrors to avoid saying it is TOTP or what they're actually doing. And of course they make it as big of a pain to export your codes as they can get away with. Then they hide behind it being complicated and that is why they have to do this to help grandma, but much of complexity is due to their obfuscation.
> 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.
Google Authenticator is a separate app that you need to download from Google Play. Native android solution is Google Password app which is pre-installed (at least on Pixel) and its functionality is extremely rudimentary even compared to Apple Passwords. No TOTP support there.
I think that Google does not care about security for their users, because their passwords app is clearly some intern work, not something really well thought. They just slapped it to mark a checkbox in their "Chrome password autofill" TODO list and moved on to a more pressing issues like implementing user tracking and extracting more ads revenue. Apple had similar issues for years, but I think that their recent releases significantly improved.
Until recently, Google Authenticator codes could not be backed up or transferred to a new phone. When I replaced my Android device, I had to re-register every TOTP code that I had in Google Authenticator. This led me to Authy, and later on to Yubikey since the code is removed from my phone completely.
I'm pretty sure you could always manually export a QR code for every one of your secret keys.
This was around 2016 and that was not an option at the time.
edit: the app used to be open source: https://github.com/google/google-authenticator-android/
"By design, there are no account backups in any of the apps."
My bad, that's too far in the past. I've changed Android phones several times between 2017 and 2020, and I remember using the QR codes exports.
It's not ideal but there's been some progress.
I'm not sure we can blame Google for not pushing their Authenticator more, most services have been dead set on SMS and are now slowly moving to Passkeys, probably for the best.
Passkeys are going to make these problems much worse.
What do you do if google/ms/apple won’t let you log in, or you lose a device, or you lose your phone?
If the answer is “there’s an account recovery path involving a password”, then just accept passwords!
If the answer is “recover the passkey provider account”, then that forces everyone to have a single password / security question / whatever that grants access to all their accounts.
I don't want Google to push their Authenticator, I want Google to retire their Authenticator, implement TOTP codes in their Passwords app (it's very trivial to implement) and implement passkeys on Google Chrome Linux (now those are not trivial, but if they push passkeys so hard, they could at least implement them). I also want to be able to store any items in Google Passwords manager, like ssh username/password, my bank cards, software serial codes and other sensitive information (again trivial to implement, just provide me multiline textedit with notes). I also want password generator in their app. I also want to configure multiple domains for entry, like microsoft.com + live.com. Are those big requests? I don't think so.
I have garbage cell signal in my house, was only an issue for sending/receiving large pictures/video's over iMessage, apparently those don't send over WiFi for some unknown reason as well... I called Verizon and they sent me a Fem2Cell, problem solved.
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.
1. 2FA over SMS is only $23 away from a compromised phone service
2. People love binding individual accounts to specific IP addresses, and large marketing firms especially like websites that use free DNS service to quietly track said users across the session
3. Much like DRM, the account auto constrains a single user to a single IP. Makes sense... unless you run a business account with a dozen people clearing a shared inbox
4. SMS inbox phone numbers are $2.75, and that requirement is bypassed if the company smartphone hardware/emulation is in use for account "recovery"
5. SIM hijacking and email server snooping is far more common than people like to admit
6. People feel safer, but it only increases the CVE difficulty level slightly above third world skill levels
This is why we can't have nice things =3
I had this problem a couple years back, when I was living in a small coastal town where cell service was spotty. Generally I could either be in a place where I could receive text messages, or a place where I could get access to wifi, but not both at the same time. When I wanted to get into my bank website, I would drive 20 minutes up the road to the next, slightly less small town, where I could get wifi and receive SMS, then drive back when I was done.
If I had stayed there longer, I might have found a better solution for my personal situation, but the experience as it was left me pretty uncomfortable with mandatory SMS 2FA as a general security tool. I'm sure there are many other people running into similar edge-cases.
I've read a fair number of cases where sim-swapping led to account hacks when the providers got talked into resetting passwords. It happened to a friend of mine. So I would say SMS 2FA is more hostile to people who are able to use it.
This is a niche article, where it reads as though the SMS 2FA messages started coming through right as the lady purchased a cell service. Well the lady would have needed to have activated 2FA first and walked away from the house to even enable it.
Then goes on to say that TOPT is also too difficult, firstly because you have to download an app to do it, yet she supposedly knows how to use her phone.
There will always be edge cases where something doesn't work perfectly the way it does for everyone else. The solution here seems to be help her choose a TOPT app, print out those backup codes and be done with it.
Great points.
> and TOTP, the obvious alternative solution, is still pretty sorry. you have to download an app to do it, it's not just a capability that a phone has by default. and then when trying to find an app to use for it, you're presented with a multitude of high-stakes choices, and often pretty technical explanations if you start internet searching about which app to use.
A reminder that mandatory iOS App Store / Android Play Store / (Xiaomi store ???) is even less acceptable than SMS 2FA unless maybe you're a USA(/Chinese) citizen living in USA(/China).
Sounds like discrimination of a broad group of people. Granted, it's not a designated protected group, like by national origin, but I still think they have a good chance in court.
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?
I'm not sure where "absolutely" comes from. I'm not an attorney to make assured statements, I can only guess.
I'm not talking about unreliable SMS delivery, I'm talking about banks not accepting other options like passkeys, software/hardware OTP keys which are more secure than SMS, thereby discriminating a whole class of people "living in the mountains".
You don't have to be an attorney to be absolutely sure only providing SMS is not discrimination.
> I'm not talking about unreliable SMS delivery
Why? That's what this is about. Everyone, including hill people, have the same problems with the same technology. Ergo, not discrimination.
> I'm talking about banks not accepting other options like passkeys, software/hardware OTP keys which are more secure than SMS
I'm going to sue Apple for not adding satellite to my iPhone. It's discrimination that when I go into the mountains, I don't have reliable coverage.
See how silly that is?
> I'm not an attorney
Then why are you confident about the outcome of court cases?
People love to eagerly advise litigation while remaining ignorant that a five-figure retainer is required to even get started on such a process.
And in the end, it's still a gamble that you may lose your case.
Yep, but in this case lawyer might try to make it a class-action lawsuit and work for a percentage. Up to the attorney, of course, if they are will to risk their time on that.
https://en.wikipedia.org/wiki/Regulatory_capture
> but I still think they have a good chance in court.
On what grounds?
Discrimination by making banking harder for a specific group of people (living in mountains).
They could accept other 2FA methods, like passkeys and OTP apps, which are more secure than SMS.
At this point it's pretty clear 2FA SMS is just a ploy to get PII customer data under the guise of security
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.
No, I think he's mostly right but it is a little more complicated. Most services demand a cell number verification on account creation for user tracking and identification under the guise of security for you. The SMS 2FA setup flow just helps push the user into coughing it up and helps sell the security cover story. Theoretically this helps prevent abuse, but there's no reason they have to abuse the data themselves after getting it for that. Its just that they will. They'll even lie to your face that they only use the number for security purposes and then use it for advertising anyway.
https://www.eff.org/deeplinks/2019/10/twitter-uninentionally...
https://techcrunch.com/2018/09/27/yes-facebook-is-using-your...
This has been my experience as well.
I implemented 2FA for my previous employer and we would have gladly skipped SMS 2FA if we could get away with it. It's more expensive for the company and the customer. And it sucks to implement because you have to integrate with a phone service. The whole phone system is unreliable or has unexpected problems (e.g. using specific words in a message can get your texts blocked). Problems with the SMS 2FA is a pain for customer service too.
"Wi-Fi calling" (LTE over IP over wifi) often allows you to get SMS messages over wifi only, on an ordinary cell plan: https://support.apple.com/en-us/108066 (Android supports it too)
The article mentions that they've encountered problems receiving messages from short codes via that.
The part that was interesting to me in this article was that companies could somehow detect that the lady had a cellphone when previously the 2FA thing hadn't been a problem for her. I wonder if this was just poor timing or if places like financial institutions actually get an alert.
SMS 2FA is also quite expensive. In the US it's $0.0083 per SMS, which at bulk is going to add up quickly. Even before the war started, it was $0.70 to send an SMS to Russia. And then there's the premium SMS line fraud that's led to massive bills for some companies.
Perhaps there’s a B2C offering to be made here. An SMS proxy, forwarding 2FA codes to people without SMS.
It would require a lot of trust.
Similar and related discussions on this post:
https://news.ycombinator.com/item?id=43976359
Daito does this:
https://www.daito.io/2fa-via-sms/
Isn't SMS 2FA immune to SIM swapping attacks when the SIM is an unregistered PAYG one?
i.e. there is no way to contact the carrier and get the number reassigned to a new SIM unless one first registers the SIM, and hence binds the number to a known identity.
It's not just people who live in the mountains that have this problem. People who do a lot of international travel see it too. There is absolutely no reliable way to predict the circumstances under which I will be able to receive an SMS.
Hey! I'm interested in that local AVL signal group. I've lived here for 6 years and I haven't met any friends because I'm a recluse with children. If you'd be willing to share, I would be greatly appreciative. :D
SMS 2FA was only invented so govt. can access all of your accounts without having to know your password.
Check your service password reset flow – is it a phone number input? It was 1FA all along.
Voip.ms is fairly inexpensive (a couple dollars per month) and if you get an SMS-capable line you can set it up to forward incoming SMS to email. Edit: I have not tested it with short codes
Sms 2fa is also really annoying for travellers that don't use roaming
I exclusively use wifi calling because my home doesn't have cellular coverage, and have never once had issues getting SMS codes delivered. Seems like a provider issue on her end.
Why does SMS need a cell tower booster but the internet router doesn't need a cell tower booster? SMS will be much less bandwidth so it should be easier to receive than a whole web page.
The article does not support the title in my opinion. This has little to do with living in a mountain but more having an ISP that doesn’t support a lot of default telco functionality.
Newer phones offer free satellite texting, so that should solve their problem.
In Israel some providers started to offer code in WhatsApp (for example credit card companies). This ensures that if you don’t have access to your phone number (for example: abroad) you won’t be locked out of your phone while implementing the same security mechanism
Trying removing consent to receive text messages on that number, or that it's only a land line and only phone calls are accepted.
You might even try to block incoming SMS. In fact, you might also try a forward with Twilio or free Google voice number, since a lot of SMS TOTP refuse to with with those numbers :)
I've even had success removing my phone number entirely from certain types of accounts, but sometimes I had to deliberately break the account (eBay) and then it tries to get you to confirm on each login which you can sometimes bypass by changing the URL or clicking the company logo.
Be sure to have strong security in other ways; strong, non repeated passwords.
But this is truly insane. Large banks don't even offer the option of TOTP but instead require far more insecure SMS. Maybe they'll offer RSA dongles, because they never bothered to remember when they all got completely leaked ten years ago or how they accepted $10M to completely compromise their constants.
What can you say, large enterprises are behind the security eight ball, as always! It's a tale as old as time.
https://www.wired.com/story/the-full-story-of-the-stunning-r...
https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-mill...
Wish I could upvote this 20 more times. Very true thank you for this.
How hard would it be for them(company) to use the Signal app for 2FA?
I travel constantly and this is a HUGE issue for me. It used to work with VOIP but now everyone wants to make sure they have maximum sellable data so they require mobile numbers. Also, clownworld security, which is totally bunk as an excuse on this.
Meh. SMS basically has the same problems as capability URLs for password resets. Sure, Mail is usually TLS encrypted these days, but they are still not regarded as secret.
That said, I still would prefer both over another shitty authenticator app that really gets on my nerves.
Additionally, I would like an option toggle with "Yes, I do have a safe and uncompromised password", where I can get rid of this crap.
Some 2FA systems do work if they don't ask more than once a month, but they are the exception.
Why can’t people take the time to use grammar correctly? This post is illegible.
Nice article, although I despise the "lowercase only" affectation that so many of us techies pass through. Capitalising the first letter in a sentence is a courtesy to the reader, not a stylistic choice you should impose to make yourself feel special.
Not only SMS 2FA, but in the past maybe couple years, many sites have been making their logins worse in many ways.
For example, I'm actually liking Walmart.com more than Amazon in some ways lately, but logging into Walmart.com takes minutes while I wait for the 2FA after I already password authenticate. So Amazon wins all the casual browsing and impulse sales, and by the time I do log in to Walmart.com, it's only because I know I want to order something from there specifically, and it's already feeling tedious.
Some off-the-cuff suggestions, since the worsening authentication experience really bugs me:
1. Present the email/username and password fields simultaneously, so the browsers like Firefox can fill out both fields. (A lot of site have started showing only the email/username to start, and also making that rely on non-login form field filling. And only after you type in your admin/email, because you don't form autofill in general, does it present
2. After user opts to authenticate with a password rather than SMS/email code, let them in, unless you're something like a bank or a medical provider. (Don't then make them do the SMS/email code anyway.)
3. If your mega online store handles HIPAA-sensitive data for some small percentage of visits, and you need 2FA for that, maybe only do the 2FA to upgrade the authentication confidence for session. (Or maybe the more sensitive data is on a different backend anyway, so as not to encumber all the developers implementing Wheaties logistics, with all the additional protections that are needed for medical records, nor to add additional weak links leading to leaks.)
4. When SMS/email 2FA is really necessary, send it immediately and reliably, and make it copy&pasteable. (Sometimes I wait minutes, and other times it doesn't come through at all. And I've even gotten email ones where competent-user text-selection picks up whitespace somehow, or even a weird unprintable Unicode character, which breaks the code entry when pasted.)
5. Those buttons to authenticate a variety of other sites are needlessly leaking information, and creating additional ways to compromise the account. (That's what you do if you want to reduce friction to first visits to your site, for which people aren't interested enough to create a password to use -- but not for logins from recurring customers.)
6. Don't prompt for "remember this browser?", and don't otherwise rely on the persistent tracking data deposited on the user's browser, across explicit authentication sessions, such as to decide whether to 2FA. For one reason, those persistent data mechanisms are overwhelmingly for shady abuse by the adtech/surveillance industry in shady ways, and are frequently cleared by privacy-conscious users. Any why is a bank, for example, complicating the UI, to ask ordinary users whether to lower their authentication security on this device, and expecting much sense out of that at all. Keep it simpler, more secure, and more responsible or respectable.
7. If you must support 2FA, make TOTP an option. And not TOTP-incompatible codes that requires installing your app, or that depends on some oddball third-party proprietary authenticator app/fob that seemed like a good idea at the time but is not a reason not to support TOTP. (You can still grandparent in the legacy proprietary 2FA, for those long-time users who've been using it, and be clever about not complicating the UI for those those dwindling users, nor for the increasing users using the more current open standard.)
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.
I kinda like client certificates, and have made simple uses of them, for Web services and occasionally corporate-internal humans.
But with the current browser support, client certs haven't seemed viable for consumer sites. Unless the browser developers are inspired to offer better support for mass consumer users, but I couldn't make a strong case why they should.
(I'd rather most consumer sites resume making password authn work well, and then have them integrate 2FA judiciously and well. And stop with some of the counterproductive surveillance capitalism mechanisms.)
> (I'd rather most consumer sites resume making password authn work well, and then have them integrate 2FA judiciously and well. And stop with some of the counterproductive surveillance capitalism mechanisms.)
OK, I agree, stop with the counterproductive surveillance capitalism mechanisms.
Making password authn work well (using the ideas you mention about improving it) and integrating 2FA (also improving it in the ways you mention), would also be OK, although that should be an alternative choice, so that users who do want to use X.509 and are able to do so, can use that more secure mechanism and not requiring other mechanisms. The 2FA really shouldn't be required especially when it causes problems (such as the ones mentioned in the "SMS 2FA is not just insecure..." article, but also such things as the set-up for 2FA not working very well in GitHub, some mechanisms requiring JavaScripts, etc); those who want to and are able to use X.509 should use X.509 instead.
Another thing that I dislike is the "security questions" such as your date of birth or your mother's maiden name or whatever, which do not help with security at all, and those should not be used at all.
Mountain people and anyone who goes abroad, where they use a different SIM card.
People who perpetrate SMS 2FA are pure scum.
Not only mountain people, try staying in Wales or inner parts of London, good luck receiving your 2FA code.
Can we just go back to having passwords please. I hate this state of authentication on the web.
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 dont care so much about passwords as I care about how annoying the current implementations are.
Passwords do have some benefits. They dont require a phone, it being charged, and fetching it 5 times to go through a couple services. They can be used from any machine.
Yes theyre not as secure, but as user Id prefer to be able to choose for myself whether I want to opt in for additional security. For most sites I dont even give a shit if my account gets hacked, and I have to go through a ton of annoyance everyday for no reason
Oh and passwords don't require you to link your identity to every single service you use online
"This terrible idea could actually be worse" is about the level I've come to expect. Congratulations, passwords haven't managed to be worse in every way than every possible alternative, mostly, yet.
Thats a huge benefit. Dont you hate that every service requires you to give them your identity?
As I said most sites I dont even give a shit if my account gets hacked.
Do you think HN for example would be better off if they decided everyone now has to do 2FA?
> Dont you hate that every service requires you to give them your identity?
I have Security Keys, which are entirely anonymous†, so actually I have much better security and do not "give them my identity" since I am, as I said, entirely anonymous.
In 1925 the understanding needed to do this did not exist. In 1975 the technology to implement it would have been prohibitive. In 2025 it's easily possible and indeed I use one every day - and yet here you are.
> Do you think HN for example would be better off if they decided everyone now has to do 2FA?
As so often it would depend on the implementation. I have absolutely no doubt that HN regulars would have strong opinions about what they should or should not use to achieve this.
† Obviously the choice to be named tialaramex everywhere is not "anonymous" - with a little effort you can even connect that to the name on legal paperwork, but on the other hand I also have accounts which aren't named tialaramex because they're intentionally not connected to this identity, and those use Security Keys too, by design it's not possible to connect the two.
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 you should accept the loss of certain features.
> 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.
Homeless people get free smartphones and free service in the US. Living in very rural areas is in fact a lifestyle choice. Not all choices need to be subsidized.
It just saddens me that you can be so devoid of empathy.
This kind of performative "empathy" people talk about in online forums is not true empathy. It's frequently the case that prioritizing this fake "empathy" results in bad outcomes. It saddens me when people use "empathy" to justify policy with strongly negative overall consequences. It's how you end up with, for example, the disaster zone that large chunks of San Francisco were before Lurie started cleaning up a few months ago. Or the deplorable state of our healthcare system.
You're bringing in all sorts of unrelated things here. The simple reality is that expecting a 70-year old to leave their entire life behind and move to the city just because of a relatively simple issue like this, is deeply and profoundly unemphatic. As is the general principle of not accepting that some people may want to choose a slightly different life from what you might choose for yourself. No one is asking the world here. These are small accommodations at best.
Nobody's asking them to leave their life behind! Talk about bringing in unrelated things! I'm saying we should recognize that lifestyle choices have consequences and that's OK. Not every consequence needs mitigation by third parties. Having to use a TOTP app and/or make a 20 minute trip into town to use some web services is not an unacceptable price to pay for the lifestyle choice of living in a remote area, and we shouldn't be vilifying people or branding them "devoid of empathy" for not prioritizing support for that use case over other, higher impact things they could do to improve their products.
> Not all choices need to be subsidized.
Interesting choice of vocabulary.
You could decide not to serve people without also describing them as freeloaders in order to feel morally righteous about your choice.
People choosing to live in rural areas aren't freeloaders. Until they demand the rest of us subsidize them. The demand for subsidies is what makes a freeloader, not the lifestyle choice.
>Until they demand the rest of us subsidize them.
I think the discussion is less around "subsidizing" them and more why requiring a cellphone with 2FA to exist and do basic things is kinda stupid.
My original message was simply here to remind people that technical decisions we make have consequences on who can use our services.
You were the one introducing this vocabulary (as well as claiming everyone living there does it by choice). Now you try to move the debate again with people "demanding" stuff. None of this vocabulary or framing exists in the original article, or in mine.
Let me clarify the question: why do you insist on framing this debate in a way that makes a moral claim about people's character?
> Homeless people get free smartphones and free service in the US
Recently former homeless person here. The Republicans in Congress refused to renew the Lifeline program in 2023 and the replacement is objectively worse in every single way.
> Not all choices need to be subsidized.
Ah yes, being homeless, a choice. I hope it never happens to you.
Hobo News
We should support the rural lifestyle choice. For one, the food you eat comes from there.
Food doesn't come from remote mountainous areas. Farm fields may not have cell service but living way out there isn't required even for farmers. I grew up on a farm so it's funny when people on the internet try to educate me about farms as if I've never heard of them.
>Food doesn't come from remote mountainous areas.
I must be imagining the farms that I pass in the mountains in the middle of nowhere when I go backpacking. Surely your argument isn't, "My farm was here, so it's impossible for other farms to be in different locales"?
Surely you aren't arguing "I once saw a farm in the mountains, therefore small remote mountain farms are critical to our food supply"?
The large trucks being loaded with crops for delivery elsewhere should suggest that it contributes to the greater food supply, yes. Further...
>I once...
My phrasing did not suggest "one time" (the phrase was "I pass", suggesting regularity), and it's not just one single farm, it's a few, and I've passed them many times. I have to agree with someone else[1] about your using vocabulary that others haven't introduced - I question whether or not a good faith discussion can be had because of that. Have a good one!
[1]https://news.ycombinator.com/item?id=43985331
It's rich for you to complain about me "using vocabulary" when your previous comment was trying to put words in my mouth that I did not say...
We should still be supportive of people who want to live in the mountains. I'd like to think that we as a society enable people to live how they want to live. Given that technology has allowed us to deploy broadband internet access pretty much anywhere, there is no good reason to deny them of e.g. web-based banking just because of some stupid SMS confirmation. Hardware 2FA keys are cryptographically superior AND usable by people in the mountains.
Exactly! Why should I subsidize sewers in town?
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
There's plenty of locations with houses in Montana that have no cell service too.
the article isn't about them. Montana by and large is a lot less dense than Asheville NC, which is a small city surrounded by normal towns. Asheville would only seem eccentric if normal is San Francisco.
There’s no cell service in many places that are 20 minutes from Silicon Valley or SF.
Heck, there are places that are a 20 minute walk from Apple and Google HQ without cell service.