Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Those all have difficulties. One is international: there are hundreds of formats of IDs in the US alone and you lose all the security features when they're imaged. People in many poorer countries may not even have government ID. What if somebody signed up to their account with a false name (for anonymity), a nickname, a maiden name?

Credit card charges are very insecure: they don't actually tell you whether the name is correct. The credit card company runs risk management and may deny a charge based on risk criteria. They may see just $1 and authorize it without question. Then add countries like China where citizens use PayPal-like services (Alipay). And countries where people don't have bank accounts period.

It's easy to dream up secure systems, but when you look into implementation details, especially to a public service, they rapidly fall apart. SMS is so prevalent because it's so universal.
So what - we accept a system with known and easily-exploitable vulnerabilities because it's universal and alternatives to it "have difficulties" in certain corner cases? No, F that.

Of all companies, Apple is in the best position to really move the ball forward for the reasons I described earlier. You're right that anything new will have some difficulties, and there is no solution that will work for 100% of earth's population overnight. But that doesn't mean we should just stick with the crappy system we've got forever.
 
  • Like
Reactions: vault
I still raise an eyebrow with those that send out these 1 time codes, this goes for both to iOS and Android, in that the message component of it before the code is way too short.

There are a significant number of people who show message previews, something which is on by default, and as such you don't have to unlock the phone to see the code. Exactly how is this a security measure given most people get security breached by someone they know. It is these people who are significantly more likely to be in the physical vicinity of the receiving device that we need defending against as opposed some arbitrary turd on the other side of the planet.

All they need to do is lengthen what they're sending a bit so that the actual code does not appear in a message preview.

This really isn't a major concern - people already can opt to hide their lock screen messages as it is.

Secondly, the person doing the hijacking would have already had to initiate the login attempt w/ correct password on the site/service before the code even gets there. Yes, many people keep their passwords saved on their devices. But just as many people keep their services logged in as well - meaning that if someone already has physical access to the device that initiated the log-in, it's most likely already authorized and not in need of a 2FA code.

Apple really should just switch to an Authenticator app. SMS 2FA has been proven to be significantly less secure than other methods.
 
So what - we accept a system with known and easily-exploitable vulnerabilities because it's universal and alternatives to it "have difficulties" in certain corner cases? No, F that.

Because I guarantee you that the permanent account lockouts from people not following instructions to keep a recovery key safe or have two security keys or whatever will exceed the risk of SMS hacking.

The threat equation changes for things like corporate systems and highly targeted individuals, so you have things like Google Advanced Protection Program and corporate security systems. But the costs, via the risk of permanent account loss, outweigh any security benefit for average consumer users.

Real security concept 1: One size does not fit all.

Real security concept 2: If you do not balance concepts of security, risks of data loss and inaccessibility, ease of use, and time and cost investment, your security will fail.
 
Because I guarantee you that the permanent account lockouts from people not following instructions to keep a recovery key safe or have two security keys or whatever will exceed the risk of SMS hacking.

The threat equation changes for things like corporate systems and highly targeted individuals, so you have things like Google Advanced Protection Program and corporate security systems. But the costs, via the risk of permanent account loss, outweigh any security benefit for average consumer users.

Real security concept 1: One size does not fit all.

Real security concept 2: If you do not balance concepts of security, risks of data loss and inaccessibility, ease of use, and time and cost investment, your security will fail.

You're making a false choice. The choice is not: SMS-based 2FA or permanent account lockouts.

It's a solvable engineering problem. That is my point.
 
You're making a false choice. The choice is not: SMS-based 2FA or permanent account lockouts.

It's a solvable engineering problem. That is my point.

Which is totally wrong. It's a human problem, and human problems are notoriously hard to solve.
 
Which is totally wrong. It's a human problem, and human problems are notoriously hard to solve.
And yet, somehow Apple manages to offer 2FA without SMS ...

The "lost my second factor" problem can be solved, e.g. by offering the option to register multiple devices, or, if all else fails, an account recovery procedure with wait times like the one Apple uses.
 
And yet, somehow Apple manages to offer 2FA without SMS ...

Nope, Apple forces you to provide a phone number for SMS/voice authentication.

A trusted phone number is a number that can be used to receive verification codes by text message or automated phone call. You must verify at least one trusted phone number to enroll in two-factor authentication.

You should also consider verifying an additional phone number you can access, such as a home phone, or a number used by a family member or close friend. You can use this number if you temporarily can't access your primary number or your own devices.
 
Nope, Apple forces you to provide a phone number for SMS/voice authentication.
Hm, you're right. Forgot about that. Tip: use a Google Voice number, since human engineering doesn't work on Google (since they have no real human support).

In any case, they also offer an alternative recovery procedure through support:

 
Am I missing something here? I don't get random OTP messages. The only ones I get are ones that I requested. Plus, I would think it is easy enough, the websites you are logging on to that send these out tell you they are, and typically ask for either the last 4 digits of your number, or the full number for verification. Then they send you a message, so you should be expecting it. Your phone dings/buzzes, you know code came from them. But, if for some reason it did not, when you try to enter that code on the site you are trying to get in to, you will get an authentication fail. So, I am hard pressed to see the need for this. Please, help me out if I am missing something.
 
Apple’s current 2FA implementation is just bizarre. If I log in on my phone — I get a 2FA token sent ... to my phone? Uh yeah, that’s great. Or it goes to every device in my account which is just annoying.
[automerge]1580566858[/automerge]
The problem is when you build a site for the public, you realize that you can't replace SMS. SMS is identity-based, specifically, you get access to your phone number based on (hopefully) the carrier checking your government-issued ID. That doesn't hold for a token or authenticator.
(quote edited just to address one specific point)

That’s a great reason why you should never use your own phone number for SMS based 2FA. When the site is breached, they’ll spill your actual phone number, which is a de facto globally unique ID these days.

instead use a VOIP nUmber which you can actually access if say, you are traveling and don’t want to flog yourself with exorbitant roaming charges.

And if the service uses short codes that don’t work on your VOIP provider? Delete the service!
 
Last edited:
Everyone here is missing the point. This is about message format *FAR* more than it is about transport method. If a more secure alternative to universally sending messages come along, this standard will benefit from that effort as well...they are two separate issues and problems to tackle.

It is the difference between HTML (the markup language) and HTTP/HTTPS. Improvements in the security of the transport (moving from HTTP to HTTPS) just makes the underlying message (HTML document) more secure. No one would have argued 10 years ago that changes shouldn’t be made to improve the HTML spec because the underlying transport was insecure.

They are two different levels, with different problems and goals they are trying to address.
 
Apple’s current 2FA implementation is just bizarre. If I log in on my phone — I get a 2FA token sent ... to my phone? Uh yeah, that’s great. Or it goes to every device in my account which is just annoying.

It's actually more secure than the Google/Microsoft/Duo-style click yes system.

No 2FA token is actually sent over the Internet in the push notification. All the push notification does is to trigger the system to bring up the already provisioned local TOTP token generator. That way, no sensitive information is exchanged after the initial provisioning.

You can see this by manually generating a 2-factor code in Settings, then immediately triggering a push notification. Both codes will be the same.

Anyway, the latest iOS and macOS versions support FIDO2/Webauthn which is used instead.
 
  • Like
Reactions: riverfreak
I don’t know, I’m not that technical in this front, but something that isn’t sent over SMS as there’s loads of stories out there of mobile networks swapping sims with hackers so they intercept codes.

Perhaps USB keys could work somehow? If there was a way for for the key to communicate through to the browser with a code or confirmation to allow access.

True, SMS is insecure, but many fill that gap by making it "one time" limited. Anything is better than not using SMS.

It may not be secure, but that doesn't mean we should just not improve on things in how we send important info. Particually, when its the default than any mobile device can use... WHile others llike iCloud can be limited.
 
I’m not really sure why we need the code in there twice. Feels a bit too technical to me. We have self-driving cars in 2020, is it so hard to parse a message?
 
But, if we are pushing people to unsafe options, then we are doing them a disservice. The fact that this still uses SMS as a delivery mechanism makes it less safe than other methods.

To me, I always want to use the safest option. In order:

1) Hardware Key (which is rare)
2) Soft/Hardware Key - Approval requests are sent to an app on my phone and I have to approve them there. (Best apps are ones that allow approval directly from the notification after I authenticate.)
3) TOTP - 1 Password makes using TOTP so much easier.
4) SMS - Better than nothing, but becoming less safe these days.
5) Nothing.
how about NFC technology which is already built in to iPhones and requires no external over air hackable transaction ???
 
how about NFC technology which is already built in to iPhones and requires no external over air hackable transaction ???
NFC is just a means of communication (literally Near Field Communication), basically like WiFi, Bluetooth, LTE... NFC itself doesn't provide authenticity. It can only be used to connect some kind authentication device or e.g. push OTP to another device.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.