Google (who isn’t at fault) is named like 5 times in the Twitter thread. At a glance it as though they are to blame even though further reading shows they aren’t. Despite this, the carrier is kept anonymous? Strange.
Yep.. naming and shaming the carried should be the first thing in the article. They'll probably disable this feature, apologize, and act as if they did nothing wrong.
>Google is investigating and looking into responsible (Australian) carrier. We’ve also reached out to the company for more details and to confirm that it’s not adding “SMS ADs” into the verification code process.
Gmail tells its users to use sms. So if it’s true what you say, sms is not secure, and it’s true that Gmail pushes users to use it, then it’s must therefore be true that Gmail isn’t secure.
I don’t think carrier would do this, otherwise guy reported this would see this a lot in other service sms’s too.
Usually when you send bulk sms, it is changing many hands on the way. From your provider, to some aggregator, then to carrier in target country or some illegal termination with sim cards.
> I don’t think carrier would do this, otherwise guy reported this would see this a lot in other service sms’s too.
That would depend on the size of the original texts. If Google's verication messages are shorter than most, they might have room for ads where some other service doesn't.
I agree that an intermediary adding something is likely. Maybe Google has enough scale to self-manage 100% direct routes, but in general it's hard to avoid aggregators, and it's hard to track message delivery. And if you need worldwide delivery, it's hard to avoid grey routes.
As I used to tell people who wondered why I built a system to pick from multiple aggregators: All the aggregators will tell you they've got worldwide coverage and that they're the best; but they're all full of bs.
I should also add that they'll tell you that they all say they have 100% direct routes and that they don't use aggregators. One of the most amusing things I remember was when aggregator X had a big outage, several hours of not accepting messages (let alone delivering them), aggregator Y's success dropped by about half. It was clear they were using that aggregator for a significant amount of traffic. But sometimes it costs less to pay Y to submit messages to X than to pay X directly. shrug
Yeah I totally agree, but on Google scale and for OTP codes, using middleman is not good practice. Especially with MNO blacklists etc, as they are actively fighting grey routes.
Also with direct carrier connections you have options like one-shot SMS. If it is not delivered it is not retried. (which is useful for delays)
Delay is a big problem when you have many middleman, imagine you are sending OTP code, let's say route is delayed somehow, user didn't get the message, he requested another one, then first one is delivering, but you've already invalidated that, user enters wrong code, requests again, until he locks out :)
Injecting your own vs someone else's is big liability difference. Especially on Twitter it was mentioned that link is pretty shady. Also why only on google SMS, I am sure he is also getting a lot of SMS from other companies.
Could it technically be possible that a malicious app is reading the content of the original SMS, then deleting this original SMS, and then creating a new one with the modified content? Like SMS backup/restore apps could do?
Effective regulators can deliver such limits. For example, Americans are used to obnoxious TV adverts for medicines they don't need and financial investments that are a bad idea, because their regulator says that is OK. In many countries neither of these would be allowed, the TV channel and the advertiser might be fined so they wouldn't even try.
This needn't be too expensive if done right. The ASA in the UK (which regulates print advertising, billboards, that sort of thing) is not the government, it's funded by the advertising industry itself under the threat that the government might find it easier to just outlaw whole swathes of their industry if they get out of hand. So ASA "rulings" are like a slap on the wrist from your mother in two senses. They seem like a big deal if you didn't realise what you were doing is naughty, but also, if you're intentionally naughty enough because you know there aren't real consequences just a slap on the wrist, the next step may be you're off to jail instead. Some advertisers will deliberately do something that gets negative attention, knowing they'll get free secondary advertising from press coverage of a "ban" and the ASA is no big deal, but even if they stray over the lines it's pretty clear where those lines are.
I don’t know. It is maybe not as secure as possible but it is certainly more secure than a password.
I think it’s a baby step. I see other threads under the parent comment recommend banning SMS 2FA altogether. Surely this would be a step back. I suspect most people and companies would think, “well, I guess we won’t do 2FA anymore” rather than, “I guess we will use a proper Authenticator instead”.
I disagree. I can safely store a long, complex, and unique password. I cannot prevent anyone from social engineering my cell phone service provider and doing a SIM swap.
You're just thinking of security -- and there are many valid concerns around using SMS-based cleartext messages as a 2nd factor.
But additionally, a big issue is reliability of the 2FA mechanism. Especially when your service provider is overseas, or you're roaming, the SMSes may simply not arrive in time.
There is a real risk to giving a company your phone-number for SMS 2FA. That is that the company might, at some point, use the SMS as a single factor. This has happened a few times, sometimes it requires social engineering. In general, the risk is there.
Combine this with the time Facebook started using the mobile phone number for more than just 2FA (suggesting friends IIRC), and there is a decent argument for preferring plain password over enabling SMS 2FA.
It is not better than just a password (in fact, it is worse). Providers have been known to reset accounts with just SMS 2FA, and passwords are harder to steal than SIMjacking.
> Providers have been known to reset accounts with just SMS 2FA
But this turns the 2FA into 1FA, and that "1" is just an SMS.
Using SMS as a second factor is great, using it as an only one, is not.
If someone hacks eg linkedin (again), and gets all the passwords, they can just hack literally millions of accounts on other services just because of password reuse. SMS 2FA prevents that very effectively.
But I agree that companies use things made to deal with "issue A" to deal with "issue B", even if the thing is totally inappropriate for "issue B". I've heard from people that some places in USA use SSN, date of birth, mothers maiden name, etc. to authenticate and verify the user (instead of doing stuff in person with an ID card)... most of those things are (almost) impossible to change, and once someone knows them, you're fscked. Same with fingerprints as means of authentication... once someone makes a mould, you're done, because they can use them, and you can't change them.
> But this turns the 2FA into 1FA, and that "1" is just an SMS.
Sure, but the fact that an explanation exists is unlikely to be of help if you get your account compromised by this.
> If someone hacks eg linkedin (again), and gets all the passwords, they can just hack literally millions of accounts on other services just because of password reuse. SMS 2FA prevents that very effectively.
Hacking a specific service is much harder than simjacking. Use an alternate method of 2FA (a FIDO2 USB key would be best).
Immediately? You need to find some other way to prove you're still you. Many sites which enable WebAuthn have a pile of single use random text codes you can use to do this, write at least a few down somewhere safe.
The specification for WebAuthn (and presumably U2F but that's legacy and shouldn't be used for green field deployments) explicitly tells Relying Parties (that'd be the web site you're enrolling with) to allow multiple authenticators to be enrolled†
They are keys after all, so it probably feels reasonable to have a key you're carrying and one spare at home. Maybe if you lose your keys a lot, buy three just in case.
Unless you've got a FIDO2 device (not just FIDO) enrolled for usernameless authentication, the device doesn't even know who you are. So if you lost it on the train, or at a crowded event, relax, even if somebody found it intact and is curious the device can't help them log in as you since it doesn't even tell its new owner who you are. In fact it actually works perfectly well for them too, to secure their Facebook or whatever, in this way it's more like if you lose a quarter than if you lose your car keys.
† Now somebody will point out that AWS doesn't do this, and somehow this fact will be a justification for why an entire technology is bad, rather than yet another shortcoming of AWS...
But how often does that happen? Who's going to try that for a service that doesn't offer access to banking accounts or secrets? For those, SMS can be perfectly viable (IMO).
SMS 2FA is equally as resistant as TOTP to phishing (basically not at all). It is also considerably more accessible. Phishing is a much much much bigger concern than SIM-swapping, since it scales easily. Using SMS 2FA instead of TOTP does not change your risk that much.
I'd buy these complaints much more easily if people actually mentioned this stuff when TOTP comes up. But they don't.
The only meaningful jump in security is when moving to a yubikey or equivalent.
NIST attempted to indicate SMS was not usable for 2FA sometime in 2016. Since other methods were not common yet (and maybe because banks had just barely gotten SMS 2FA deployed?) they were pressured to "soften" their recommendation.
5.1.3.3 Authentication using the Public Switched Telephone Network
Use of the PSTN for out-of-band verification is RESTRICTED as described in this section and in Section 5.2.10. If out-of-band verification is to be made using the PSTN, the verifier SHALL verify that the pre-registered telephone number being used is associated with a specific physical device. Changing the pre-registered telephone number is considered to be the binding of a new authenticator and SHALL only occur as described in Section 6.1.2.
Verifiers SHOULD consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior before using the PSTN to deliver an out-of-band authentication secret.
"I'm electing not to state the carrier for privacy reasons"
Cool, so this entire brouhaha was for nothing? You just wanted to pistol-whip Google for something they had nothing to do with, and then you're refusing the publicly persecute the real bad actor?
The purpose of most 2FA schemes is not to secure things, but to get a unique identifier of the user.
The 2FA craze is overblown, for most applications a random password with length 16 would be completely fine. Of course, since cloud providers constantly have security holes and leak databases, perhaps 2FA is for covering up their bad practices, too.
2FA is more to protect users from phishing attempts than for securing a database, at least in my view. If you fall for a phishing attempt, it means your attacker will need to take the extra step of breaching/replicating your 2FA setup, and the service provider can note the login attempts and notify you (giving you a chance to change your password, rendering the result of the initial attack unusable).
2FA is not for securing a database -- salted+hashed passwords do that.
2FA only prevents phishing if you are using something like a yubikey. The phisher can just ask for your SMS code or your TOTP code. You can go buy tools that completely automate this on the black market.
> 2FA is more to protect users from phishing attempts
Usually, 2FA enables phishing. People generally know not to share their passwords. But scammers are now triggering the password reset mechanism and phishing people for the 2FA code. People are not as careful with that code as they are with their password.
My grandmother almost told her SMS 2FA to some scammer on the phone claiming to be from her bank. If they asked her password she would have immediately understood the scam.
So I feel 2FA is worse than useless for preventing phishing attempts.
- 2FA one-time passwords shouldn't be used for anything but verifying a normal login attempt, not a password reset. Independent of a login, they should be totally useless.
- If someone is phishing via a phone call, I'd expect that they already have the password in-hand, either because the bank themselves have been breached or because your grandmother was re-using the username/password combination on another website that got breached (a situation that should be taken into account as a common case when designing login systems nowadays).
Again, 2FA isn't to _prevent_ a phishing attempt, it's to throw up additional barriers to someone attempting to phish. 2FA is also great for situations where someone else has been breached, since an attacker can't then immediately take a re-used password and shove it into a third-party system to get access.
> My grandmother almost told her SMS 2FA to some scammer on the phone claiming to be from her bank. If they asked her password she would have immediately understood the scam.
For a second factor to be useful, they would already have to have her password.
> Usually, 2FA enables phishing. People generally know not to share their passwords. But scammers are now triggering the password reset mechanism and phishing people for the 2FA code. People are not as careful with that code as they are with their password.
But this makes the SMS a single factor of authentication, which is bad. Combined with a password, it's still a good method, a lot better then just a password.
If I forget my bank password, I have to go to my bank with my ID and reset the password there. I think they added a videocall + id option because of the plague, but going there in person was the only option back when i signed my contract.
> The 2FA craze is overblown, for most applications a random password with length 16 would be completely fine.
There isn't a 2FA craze. There is a slow and painful acceptance from companies that 2FA is one of the more effective things they can implement. It is slow and painful because the login logic is threaded throughout most organizations. Moreover, it requires changing how all users work, and that always meets a lot of resistance.
Despite all that, it is still growing. That is because password stuffing and password stealing are rather effective, and the number 2 cause of most infections (with the leading issue being phishing mails). 2FA, in one stroke, protects against these measures. It means password re-use by your users (which is inevitable) is a much lower risk. It means shoulder-surfing and keylogging are much lower risk.
2FA is one of the most effective security controls.
Most people recycle passwords. You can say they are doing the wrong thing but it's the reality. When that recycled password inevitably gets pwned, 2FA makes the account more secure.
> for most applications a random password with length 16 would be completely fine
Yes. If we could figure out how to actually get people to do this universally we'd be in good shape. But nobody knows how to make this happen at scale.
