Apple Wants To Standardize the Format of SMS OTPs (One-Time Passcodes) (zdnet.com) 125
Apple engineers have put forward a proposal today to standardize the format of the SMS messages containing one-time passcodes (OTP) that users receive during the two-factor authentication (2FA) login process. From a report: The proposal comes from Apple engineers working on WebKit, the core component of the Safari web browser. The proposal has two goals. The first is to introduce a way that OTP SMS messages can be associated with an URL. This is done by adding the login URL inside the SMS itself. The second goal is to standardize the format of 2FA/OTP SMS messages, so browsers and other mobile apps can easily detect the incoming SMS, recognize web domain inside the message, and then automatically extract the OTP code and complete the login operation without further user interaction. By doing this, the process of receiving and entering a one-time passcode could be automated, eliminating the risk of a user falling for a scam and entering an OTP code on a phishing site, with the wrong URL.
STOP USING SMS FOR OTP (Score:5, Insightful)
Subject says it all. SMS is not secure enough for this purpose.
Re: (Score:1)
Subject says it all. SMS is not secure enough for this purpose.
Common sense says people aren't going to shell out for dedicated hardware, and if your damn phone is compromised, then the "secure" MFA app running on it is too.
People are cheap and lazy, and this is better than nothing. And let's stop pretending that SIM swaps are fucking commonplace already.
Re: STOP USING SMS FOR OTP (Score:2, Insightful)
"let's stop pretending that SIM swaps are fucking commonplace already"
Yeah totally. Let's bury our heads in the sand and hum "nah nah nah". That's what real security looks like!
Re:STOP USING SMS FOR OTP (Score:5, Informative)
The problems with SMS have nothing to do with the security of the phone, and everything to do with the complete lack of security between the sender's server and your phone. As I understand it, here's what happens (approximately — I'm probably missing a bunch of interesting details here) when one of those OTPs is sent out:
So let's go over how each of those steps can be compromised:
So as you can see, when we say that SMS is insecure, we don't mean that it is insecure if someone cracks your device. We mean that it is so insecure that they might as well post the OTP on one of those giant electronic signs in the middle of Times Square.
Re: STOP USING SMS FOR OTP (Score:3)
Re: (Score:2)
If I understand your question correctly, you're misunderstanding how the SMS attack ties in to the attack as a whole. The part I left ou
Re: (Score:2)
Well yeah, you certainly could, but the contents of the SMS message aren't contributing meaningfully to the verifiability of the authentication process at that point:
Re: (Score:2)
Agreed. Not sure whether creating a false sense of security is a good or a bad thing. On the one hand, you could argue that it is good in that it at least ostensibly increases trust in our financial system, but on the other hand, it is bad in that it discourages adoption of technology that would actually increase security in a meaningful way, while adding extra hoops to jump through, all without a commensurate improvement in security.
*shrugs*
Typically true, should be false (Score:2)
> The correct way to use OTP tokens is you generate them yourself on your own device
Yes and that's what the two standard OTP protocols do, the OTP that works with almost any OTP app. Not sending tjem from the server.
> OTP's are used to establish a session, there are no session cookies yet to worry about.
If sent from the server, there SHOULD be a pre-login session ID. There often isn't, there should be one. A new session ID should be generated upon login. The old session ID must NOT be re-used and
Re: (Score:3)
The delivery to the handset is encrypted from 3G onwards. It was an unencrypted control channel frame in GSM, but we've moved on from that. SIM cloning attacks should be more difficult than they used to be as well. I agree that SMS is not secure by design, but it's not quite as easy to casually steal SMS as it used to be.
Re: (Score:2)
Common enough up here.
https://www.cbc.ca/news/canada... [www.cbc.ca]
https://www.cbc.ca/news/canada... [www.cbc.ca]
Re:STOP USING SMS FOR OTP (Score:4, Funny)
The problem is not so much that SMS is insecure, so much as that authentication is so fundamentally broken that people need a secure channel in the first place. This is like sending the key to the storm door outside someone's main front door by mail and being concerned that someone might break into the house by stealing the mail because the main front door is usually left unlocked.
Right now, we have this bizarre world where people use passwords instead of private keys for authentication. As a result of having to remember passwords and, on many websites, being repeatedly asked to enter them, people use weak passwords that are also typically easily guessable.
We should be using 4096-bit (or larger) private keys instead of passwords, and using some more complex proof of identity than passwords (possibly requiring access to an existing device in addition to that proof, and/or an in-person visit to a notary) when adding a new device to an account.
The entire notion of having to sign in using an inherently weak scheme like passwords is flawed, and adding a second factor as weak as SMS doesn't improve the situation in any meaningful way, but even adding a strong second factor (such as an external crypto device) with a weak first factor like passwords won't give you a security story that's as good as a strong second factor with a strong first factor.
Re: STOP USING SMS FOR OTP (Score:1)
Re: STOP USING SMS FOR OTP (Score:2)
So basically, you get access to a person's phone, and you get access to everything. Riiiiiiight. Super secure!!
Re: STOP USING SMS FOR OTP (Score:2)
Re: STOP USING SMS FOR OTP (Score:2)
Re: (Score:2)
eSIM does not affect SIM swapping at all. SIM swapping is just reprovioning a SIM card with your account information. Basically transferring service from one SIM card to another. All eSIM does is make it so you don't have to physically move a chip between phones (which can require a new SIM card because they accept different sizes).
Re: (Score:2)
SIM swapping will soon be left out in the dust as eSIM takes hold.
eSIM does nothing about SIM Swapping. SIM Swapping is not: moving a SIM card to a new phone - its contacting the phone company pretending to be the customer and moving the phone number to a new SIM card to replace the old one
The phone companies are still going to have a procedure where people can replace their Cell phone and keep their number on their new phone; as long as that exists, and as long as number porting still exists on
Re: (Score:2)
Well, using a password manager fixes this to some degree, but most people are not really able to do this either. Passwords are not the problem though. The problem is that this whole "Internet" thing is pretty new and things need to stabilize for a few decades yet before they can be considered mature technology. In the end, everybody will carry some kind of dedicated authenticator that has interactive capabilities (tells you what you are authenticating to), because that is the only thing that works. No, it w
Re: (Score:2)
No, it will not be the mobile phone, although it may be in there as a separate device that only shares power and maybe some very small attack surface interface with the main one. But it will have its own display and own y/n button and also some dedicated unlock mechanism and it will be _hard_ to attack with physical contact and almost impossible remotely.
I don't see why they can't be the device itself or multiple devices. Provided that the key is stored in some sort of secure enclave, and the device can be "de-trusted" easily from another authenticated session/device. Everyone thought cameras would remain separate devices, but it's simply not convenient.
Re: (Score:2)
We should be using 4096-bit (or larger) private keys instead of passwords, and using some more complex proof of identity than passwords (possibly requiring access to an existing device in addition to that proof, and/or an in-person visit to a notary) when adding a new device to an account.
Devices can be lost or stolen. Biometrics can be faked (or worse), so locking said device with biometrics is a bad idea. That leaves locking the device with a password, but that leaves just one password to crack. 2 factor authentication - device plus site password - is more secure. Kind of like accessing a safe deposit box; you need 2 keys: Your key and the bank's (or other service provider's) key.
Real world example: A cousin of mine used a password vault app on his phone to store all his passwords. One day
Re: (Score:2)
And that password vault had no password system in place or did your cousin use 12345, you know, the one on your luggage?
Re: STOP USING SMS FOR OTP (Score:2)
Re: (Score:2)
Too many use cases that don't work with it. For one, temporarily using a computer that's not yours. It's much easier to run a private browsing window (or even a livecd/usb) and provide an OTP to get in once.
Re: (Score:2)
>"I donÃ(TM)t understand why we all donÃ(TM)t just use client certificates. Login to browser once to unlock client cert. Client cert used to authenticate on any https to any server. No need to login to anything in the internet ever again."
A certificate or private key is not authentication of the PERSON. It isn't in that person's mind. So anyone with access to that physical device can now do whatever they want. Passwords have a very valid place in security, when used correctly. Now, password
Use SRP, not Private keys (Score:3)
They are complex and difficult to use in practice, which is why nobody does. They could be encrypted by a password, but still need to be carried around and installed on computers.
The underlying problem is that every web site insists on you sending your password in clear text to them. Sure it is over TLS, but there is no way for a user to verify the URL. Not even slashdot users can tell that sIashdot.org is a forgery (siashdot).
A better solution is an old one, Digest based authentication. So you never ac
Re: (Score:2)
>"Secure Remote Password (SRP) is an old algorithm that addresses these issues. [wikipedia.org]"
+1 informative
That is very interesting, and a good idea. Of course, if the browser is filling the password in automatically, because it conveniently "remembers" it (and sends a hash), it still short-circuits the important "what you know" concept of security. But it solves the problem of server hacks and MITM.
Brute force is easy to mitigate, just throw in failure delays and long number-of-attempt (from any so
Re: (Score:2)
Brute force is actually not easy to mitigate in this sense.
If you yous a normal Digest then a Phisher will send the nonce and get the digest that corresponds. The phisher can now do an OFF LINE attack until a match is found. Might even use a rainbow table if there is no client nonce.
SRP and PAKE generally involves much cleverness to avoid this.
Re: (Score:2)
Your solution isn't. All computer security should require two things. Something you know and something you have. Getting both is very difficult. Getting one is much much easier. OTP operates as something you have, Sure the SSH key is also something you have and probably a better protection, but throwing away the something you know only makes it less secure overall.
Re: (Score:2)
Typically, the passcode on the device is the "something you know". Having a second "something you know" might make it more secure for accessing it on that device, but it tends to make your account less secure for accessing it from other devices, because you have to know it, so it's kind of a tradeoff.
But treating each device a permanently signed in has other advantages that, IMO, mostly outweigh those concerns — specifically the ability to see when a new device signs on, kick an unauthorized or stol
Re: (Score:2)
Having two "something you knows" does not increase security. Usually, if you can compromise one factor you can immediately also compromise all factors from the same category. "Something you know" is either stored in a password safe, meaning that if you compromise one you also compromised the other, you create two near identical systems because that's how people simply are, or the system is coded in a way that if you compromise one you also compromise the other. There are very few scenarios where you actuall
Re: (Score:2)
You're correct to within the margin of error, but it isn't strictly true.
For example, two "things you have" can make a system more secure if they are not typically possessed simultaneously. Someone stealing one device is unlikely to steal all of your devices, and if, in the time that it takes for them to crack your device, you can use
Re: (Score:2)
>"The entire notion of having to sign in using an inherently weak scheme like passwords is flawed, and adding a second factor as weak as SMS doesn't improve the situation in any meaningful way,"
That is absolutely untrue. First, using a "private key" is only something you have, not something you know. Anything that depends only on a "key" can be stolen or lost (physical or not, it isn't something in your brain). Second, even if SMS, itself, is weak, using it as a second factor does improve security IM
Re: (Score:2)
Subject says it all. SMS is not secure enough for this purpose.
Ok, so "nothing" is a better idea?
You've got the floor: Suggest a better (and practical) alternative. We'll wait.
Re: (Score:2)
TOTP. Apple can even come up with its own app with an API that lets the authenticator auto-fill the codes when requested by the app. Bonus points if the key to the TOTP is stored in the secure enclave.
Re: (Score:3)
To rephrase what an earlier poster (modded to 0 for whatever reason) said, SMS is used because secure alternatives are viewed as unworkable by both ends of the transaction chain. I would much prefer to use a private key, either software or hardware (Yubikey-like) for verification, but most institutions don't make that option available for mere raggedy-assed-masses customers. They don't make it available because most of their users won't want to (or can't) use it. Whether secure enough of not, SMS is easy
Re: (Score:3)
Re: (Score:3)
Re: (Score:2)
Until I ring up the mobile firm and persuade them to port your number to a different SIM. That's the problem with SMS for OTP, and it's a real problem. The other year when the TSB bank in the UK was having IT problems a number of customers where hit with SIM swapping fraud that drained their bank accounts because the TSB was using SMS for OTP.
Re: (Score:3)
You can communicate secret data over insecure channels. That's what the Internet is built on and apparently what Apple wants to do. If you send a cryptographic message over SMS where both sender and receiver can agree on session state, it's a secure method of exchanging data through another pathway than the actual session.
I'd love to have a 2FA that works with my finger print and some systems already have that, but the infrastructure isn't standardized and it requires a typically closed-source app. SMS is o
Re: (Score:2)
By establishing a secure channel over SMS, you've just done the same work that would've been needed to set up a real 2FA app like Authy [authy.com]. Except in Authy's case, the crytographic synchron
Re: (Score:2)
Not everybody wants a closed source solution that costs 10c per authentication attempt.
Re: (Score:2)
The reason for SMS OTP being required everywhere is actually not much to do with improving security. Most of the time the real reason is an excuse to harvest phone numbers (a relatively solid personal identifier) so that the product I mean users can be reliably de-anonymised.
Riiiight.
Because Apple is so well-known for harvesting phone numbers and other personal information.
Re: (Score:2)
Apple isn't doing it but the companies using SMS for OTP (the ones who would be sending those SMSs in Apple's new format) are doing it.
What, _now_? (Score:3)
There are attacks on this in the wild. SS7 basically has only its incredible complexity as security and it is _old_.
Stop using SMS for OTPs unless you have really low security requirements.
How about Don't use SMS OTPs? (Score:5, Interesting)
Re: (Score:2)
Depends on who you are. I'm just an average schmoe so SMS 2FA is fine for me. Nobody's going to randomly pick me out and go through the hassle of hacking my SIM card.
If I'm Justin Kardashian or some Youtube griefer edgelord "influencer" then sure, I'd want a bit more security because people are after me. Just like the famous tend to have bodyguards fairly often and I've never needed one in my life.
Re: (Score:3)
And if that's true, then it is also true that choosing a good, strong password will ensure that nobody will get as far as needing the second factor. So:
Re: (Score:2)
Re: (Score:2)
Fine. My password is 895 characters long. Happy cracking. :-)
Yes, in theory, you are correct, but in practice there's the pesky little problem of the heat death of the universe happening first. Cracking a password, absent a compromise of the database itself, requires that the server not be configured to do any of the following:
Re: (Score:2)
It doesn't take millions of compute hours to crack a password that is poorly encrypted or not encrypted in transit and captured.
Easy scenario would be using a public computer. I don't, of course, but let's say I use a buddy's computer and he is infected with something. 2FA would protect me pretty well.
Another would be a company not using good password handling hygiene. Suddenly a huge list with my password gets out on the (dramatic music, I'm being sarcastic here) "DARK WEB". Again, 2FA helps.
Re: (Score:2)
Any website not using HTTPS is not secure by its nature, so we can ignore that. And if you can compromise the password database, you can also probably add your own session key or whatever, and skip the sign in entirely, so that's also moot.
Re: (Score:2)
A SIM swap will just send the OTP to another phone rather than yours. The attacker can still log in as you.
The big problem here is you receive an SMS and automatically confirm the log-in on your phone. That means when an attacker logs in as you, your phone automatically confirms the log-in, and your 2FA does nothing. The check is reduced to "is your phone on?"
We already have a problem with 2FA where an app on your phone asks if you're authorizing a log-in and users, sitting in front of their e-mail,
Re: (Score:2)
The point is that the SMS has embedded in it information that only your phone and the other party knows but cannot be snooped without breaking SSL or your phone, eg. a public key to a particular session. If you receive a message on your phone that is faked, the session ID's won't match up and you break the connection, if another phone receives the message, it will be useless without knowing the private key that's on your phone.
Re: (Score:2)
An attacker goes to www.yourbank.com and logs in with your user ID and password.
The bank sends 2FA to your phone.
Your phone automatically sends 2FA to your bank.
The attacker is greeted and given access to your accounts, as your phone has input the 2FA token the bank has sent.
Re: (Score:2)
That's not what this is for (at least my understanding). This is for handing the 2FA code directly to the app without having the app have permission to read all text messages. If the app isn't what requested it, this won't do anything.
Nevermind the fact that they could help push the use of anything but SMS 2FA.
Re: (Score:2)
I don’t think you understand what’s actually being proposed... an attacker could only “log in as you” in this manner if they already have access to your phone.
Re: (Score:2)
My phone sends me OTP each time I log into something, and I enter the OTP into the machine from which I logged on. Sometimes I have to get up and go to a window to get signal.
The point of the proposal is to eliminate the action taken with OTP: it immediately sends the OTP to the challenger.
Re: (Score:2)
Another good reason for TOTP instead of SMS OTP.
Re: (Score:2)
Re: (Score:2)
We already have a problem with 2FA where an app on your phone asks if you're authorizing a log-in and users, sitting in front of their e-mail, think they're about to get logged off and tap "approve".
So, name me one "authorization" scheme that cannot be "defeated" by jaded click-happy Users?
In the real world... (Score:2, Insightful)
...a.k.a the "Non-Slashdot" world (planet Earth), everyone uses SMS OTP. Maybe when we populate Mars we will ban the use of SMS OTP, but until then this sounds like a decent proposal.
Re: (Score:2)
...a.k.a the "Non-Slashdot" world (planet Earth), everyone uses SMS OTP. Maybe when we populate Mars we will ban the use of SMS OTP, but until then this sounds like a decent proposal.
Exactly.
I note that not one of the naysayers and Haters have proposed a workable alternative.
Pretty telling.
A workable alternative already exists (Score:3)
Re: (Score:3)
On the one hand, SMS OTP is currently the most practical scheme.
On the other hand, including the website URL in the message is a BAD idea. Just like you should never store your user ID with your password.
In the real world, no matter how many sites a user is logging into, it's happening one login at a time. Including an URL with the message just isn't necessary. if a user is too confused to know which site (or app) gets the OTP, they are going to be making worse mistakes than that.
Re: (Score:2)
And yet TOTP stored with an identifier to associate it with an app would give them the control to solve this problem themselves. At least for services/apps that have TOTP as an option. This might be a great way to get greater adoption.
I'm less concerned about the security of SMS and more concerned that every online account wants my cell number.
Re: (Score:2)
On Mars, nobody will need OTP codes (Score:1, Offtopic)
Re: (Score:2)
If it is His will, then it will be so. But here on Planet Earth, the dirty masses use SMS OTP.
Re: (Score:1)
Re: (Score:2)
What "prankster"? Literally 1 million people on Mars (and lots of jobs too!). My supporting evidence: https://www.businessinsider.co... [businessinsider.com]
Re: (Score:1)
Re: (Score:2)
Elon Musk accomplishes more in His week than you do in a lifetime. Starlink, Tesla, Paypal, Hyperloop, eventually Mars.
Re: (Score:2)
Wrong. Guess what? Opinions change. Remember everyone used to hate Reagan, now we all love him? Same thing.
Re: (Score:2)
I just meant the voices were similar, not that they were frauds!
Re: (Score:2)
Oh, but He [Elon], would wash their dirty feet and free them from the oppression of SMS OTP
Re: (Score:2)
By that time, we will all own Tesla phones with a million hours of battery life running TempleOS.
Horrible idea (Score:2)
Given that SMS is insecure the lack of ability to link a OTP directly with a specific request from the message itself IS A SECURITY FEATURE.
Apple's proposal would allow automation of breaking OTP, not by luck, not by direct targeted action, but in a remote and widely automated way.
Re: (Score:2)
Given that SMS is insecure the lack of ability to link a OTP directly with a specific request from the message itself IS A SECURITY FEATURE.
Apple's proposal would allow automation of breaking OTP, not by luck, not by direct targeted action, but in a remote and widely automated way.
Except in most cases, the codes for a SMS token come from the same number for a given company/service/site, so it would be trivial to figure out who is sending the code. And quick if you are a bad actor and setup a contact for that number. Additionally, the kind of attack you are talking about is vastly outnumbered by simjacking attacks anyway, which allow the bad guys to login at their leisure.
What Apple is proposing is a way to ensure the site you type the code into is the legitimate site that should be
Re: (Score:2)
Except in most cases, the codes for a SMS token come from the same number for a given company/service/site, so it would be trivial to figure out who is sending the code.
The point isn't who is sending the code. The point is linking the code to an instance. It doesn't help you if Mastercard is sending a code if you can't link the the code to the specific transaction. Apple is talking about being able to identify the transaction. That opens you up to using the codes in conjunction with attacks on the authentication system.
It's bad enough that Citibank gives you the last 4 digits of the credit card in the OTP SMS. That alone is already too much linking. It would be sufficient
Seems like a dumb idea (Score:1)
Android Already Does This (Score:2)
Android already does this. Messages that come in that are SMS 2FAcodes it extracts and notes the code separately. Smarter apps -- like Bank of America -- finally figured out that a 2FA SMS to the device you're using to log in with in the first place is just an annoyance, not a security issue. They auto-detect the SMS code and fill in the blank for you.
Re: (Score:2)
Apple already does this as well. The proposal seems to be to make it universal instead of requiring some intelligent parsing - Apple sometimes isn’t able to see the code in my experience.
SMS messages are OK for 2FA... except like this (Score:3)
The use of SMS messages as part of a 2FA mechanism is OK: while SIM swapping is a thing, SMS messages complement the other security mechanism (typically, a password) and the combination of the two mechanisms is safer than each of them individually.
SMS messages are NOT OK as a single-factor authentication mechanism, such as a backup mechanism to recover your email password (hint: never give your phone number to your email provider).
However, increasing the information contained in the SMS to define the originator of the request seems... weird.
Re: (Score:2)
Not weird, dangerous!
If an SMS is linkable to a specific instance then it provides you an attack on the auth system itself. If it's just some number from Citibank whizzing through the SMS world then it's not tracable to a current auth attempt.
Re: (Score:3)
Example: Losing my key in the park is not an issue. Losing my key in the park with a tag on it that lists my home address and the word "front door" is a BIG problem.
Crafted messages turning into WebKit exploits (Score:2)
I can imagine someone sending SMS in bulk to get people to open Web pages containing WebKit exploits. At least make it a "Would you like to authenticate to example.com?" rather than adding to all those text-rendering-based crafted message attacks.
No, just no. (Score:2)
Ease of use is no excuse (Score:2)
Just don't do it automatically. (Score:2)
The part which bugs me about SMS auth codes (other than the insecure part) is that I have to type them in. BUT, I would hate to have it just work with no user interaction. Then what happens if someone manages to subvert a site's auth, and it just goes on through because I'm sitting right there using some other site?
Personally, I'd prefer either a way for my devices to see each other with bluetooth, and then on one device click "This one's the code, go", and have it all work out. Or a QR code would be fin
Apple & standards? (Score:2)
Re: (Score:3)
Apple can do whatever it wants.
I do not use (and will not use) Apple stuff, nor do I use SMS OTP (which is inherently insecure).
Then politely excuse yourself from this conversation.
Re: (Score:2)
Apple $tandardizing thing$? Idk if I can afford that.
I thought we moved past spelling CompuServe and Microsoft with Dollar-Signs.
Grow the fuck up.
Re: (Score:2)
Re: (Score:2)
We have moved past Micro$oft and Compu$erve, obviously. It took some gymnastics, but he managed to use $ when referring to Apple. He just hasn't moved too far past...
He should have used Dollar Signs for $M$, that would at least have been consistent with the thread's Topic.
Re: (Score:2)
When you could just write App£€...
Re: (Score:3)
Apple historically has supported the open source movement and has always shied away from oppressive licenses (whether it's Oracle's CDDL or GPLv3). Plenty of their stuff is BSD licensed and has the potential to be a standard (eg. WebKit which is now the de-facto Internet standard, HomeKit is open source, they supported BSD, Samba and CUPS for a very long time etc).
Re: (Score:2)
Apple historically has supported the open source movement and has always shied away from oppressive licenses (whether it's Oracle's CDDL or GPLv3).
I'm looking for a sarcasm tag. It has to somewhere around here...
Plenty of their stuff is BSD licensed and has the potential to be a standard (eg. WebKit which is now the de-facto Internet standard, .
Bad example. WebKit is a fork of KHTML and thus Apple had to keep it open sourced.
Re: (Score:2)
Apple historically has supported the open source movement and has always shied away from oppressive licenses (whether it's Oracle's CDDL or GPLv3). Plenty of their stuff is BSD licensed and has the potential to be a standard (eg. WebKit which is now the de-facto Internet standard, HomeKit is open source, they supported BSD, Samba and CUPS for a very long time etc).
Shhhh!
Apple Haters have a lot in common with Republican Senators: They don't want to be confused by the Facts.
Re: (Score:2)
Not if the SMS contain cryptographic messages. You can share secrets in public as long as you have strong private keys, exchanging public keys over SMS shouldn't be a big problem and will detect tampering while being useless without knowing the private key.