Millions of people imperiled through sign-in links sent by SMS
- Thread starter JournalBot
- Start date
Am I missing something here, or does the issue highlighted in the article have nothing to do with SMS and is basically just about poorly managed self-authenticating links?
Not saying SMS is a legitimate flow for second factors or anything related to security, but AFAICT, the article is not about SMS at all. It’s about insecure authentication links — regardless of how they are communicated (could be SMS, email, snail mail, or any other messaging service).
EDIT: checking the link to the paper, they do clearly call out SMS. But unless I’ve misunderstood the issue, links sent via email are equally at risk. It’s concerning to me that the paper could lead people to believe that moving these links to email would protect them in any way.
Not saying SMS is a legitimate flow for second factors or anything related to security, but AFAICT, the article is not about SMS at all. It’s about insecure authentication links — regardless of how they are communicated (could be SMS, email, snail mail, or any other messaging service).
EDIT: checking the link to the paper, they do clearly call out SMS. But unless I’ve misunderstood the issue, links sent via email are equally at risk. It’s concerning to me that the paper could lead people to believe that moving these links to email would protect them in any way.
Last edited:
Upvote
91
(94
/
-3)
The entire telephone ecosystem is built on trust and poor security. relying on them is bad
Upvote
43
(45
/
-2)
I think the emphasis on SMS is that it’s easier to obtain the magic link via SMS than one sent to email, because in theory, email is better protected and more difficult to obtain. I think they got these messages for research off of poorly secured SMS gateway providers who send the links, if I’m understanding correctly.
Upvote
48
(48
/
0)
I think this probably is why they're calling out SMS:
Granted, this CAN be done with e-mail links. But those are harder to get and verify than phone numbers are. So by my read, the issue is more about accessibility to dupe someone than it is about the method used to dupe them.
Upvote
26
(26
/
0)
- Add bookmark
- Featured
- #7
There are more risks associated with SMS than emails, and the SMS data was publicly and ethically available for research compared to a similar amount of email data. However, the issue highlighted is that these tokens are not short-lived, one-time use, or cryptographically secure.
The SMS gateways are only used as a lens into the overall SMS ecosystem as service providers send similar emails to real phone numbers that are used to register for these services.
Upvote
30
(30
/
0)
I think this is the part that matters. SMS, email, smoke signals, whatever - if you fail the short-lived/one-time/lack of entropy, you're dead in the water regardless of method.
Hell, that's something that should be required for session tokens like cookies too, and if you need them longer lived you silently renew them (that's what I do with my reverse proxy - sessions last as long as configured but default to 20 hours, but the session cookie is only valid for very limited time - while its valid, it can be renewed unless you've exceeded the session limit...)
Edit: I can understand the lack of "one-time" though - you can implement short-lived and plenty of entropy with stateless management (just encode it and sign it appropriately - that's what JWTs are for though you can use any method you like), but one-time requires keeping state to track its use, and depending on the volume that can be pretty ugly. If the short-lived is low and robust enough I'd have to think about the trade-off of true one-time.
Upvote
24
(24
/
0)
I'm a subscriber to that same list (Hi Ed Zitron, I'm a huge fan!), & I find it annoying that every time I go to his site, I have to do the dance of inputting my email address, then going to gmail to collect the link. His blog is good enough that I'm willing to do that, but I certainly count that as friction.
Upvote
47
(47
/
0)
This is my thought as well around “magic” links. I understand what they are trying to do with them, but for those who are using a password manager properly (unique password per account, some kind of OTP, passkey, etc), magic links are incredibly annoying. It really just feels like sites are trying to offload their risk to another service (email), at the cost of a streamlined login process. I’ll take decent 2FA over a magic link any day.
Upvote
68
(68
/
0)
Upvote
5
(5
/
0)
Jesus.. It's called a cryptographic nonce you idiot programmers. Generate a random one and store it in a table with an expiration date.
Upvote
20
(22
/
-2)
I have to say, it’s almost physically painful when I see sites which refuse to implement passkey support and force SMS auth instead. Amtrak recently cancelled some trains for a big construction project and they use only SMS auth with a short session timeout, where each message takes 1-2 minutes to arrive and so the total time I needed to visit the site and rebook was roughly half authentication.
Upvote
14
(15
/
-1)
As someone without a mobile number, 2FA is very unpleasant. If I've signed out of iCloud on all my iOS devices / haven't a logged-in one on me, then I need to rush home to my landline. (Yes, I know January 2027...)
Ah, found it!
https://meincmagazine.com/ai/2025/10/ars-live-recap-is-the-ai-bubble-about-to-pop-ed-zitron-weighs-in/
I've seen that name before...
Ah, found it!
https://meincmagazine.com/ai/2025/10/ars-live-recap-is-the-ai-bubble-about-to-pop-ed-zitron-weighs-in/
That's rather strong language there. o_o
Upvote
-9
(2
/
-11)
For sites the use magic links, the benefit is not having to store a ton of data that hackers are just dying to steal. That's a huge boon that partially helps you, despite the extra friction.
Upvote
-7
(2
/
-9)
I dont accept text links at all. I only do email links with the greatest of caution. Id rather they send me a notification to go to their website to log in.
Upvote
5
(5
/
0)
It's been clear for a long time that SMS is an unsafe MFA mechanism. I mean, Notable Fan of 2FA Dan Goodin has written about that many times since I became an Ars reader.
I'm in the minority, I guess, because I hate all 2FA. But I hate SMS most of all, since it assumes that I am my cell phone.
Email 2FA is also crap, with its many many assumptions about how hard it is for someone to access another's email in realistic terms.
The only 2FA I can stand is with a physical key. I'm not that key, true, but at least it's a single-purpose device that is small like a door key.
I'm in the minority, I guess, because I hate all 2FA. But I hate SMS most of all, since it assumes that I am my cell phone.
Email 2FA is also crap, with its many many assumptions about how hard it is for someone to access another's email in realistic terms.
The only 2FA I can stand is with a physical key. I'm not that key, true, but at least it's a single-purpose device that is small like a door key.
Upvote
10
(11
/
-1)
Among other frustrations with it, when I want to log into a site, I usually want to do it right now, and not eventually, maybe, once the text or email finally shows up
Upvote
26
(27
/
-1)
I hate "magic links" with a passion.
Reading article
Hit paywall
Click here to login
Type email
Switch to email client
No email
Wait
Still no email
Hmm maybe I typed in the wrong address
Try again
Wait
Great! An email
Click link
Invalid. That was the first email
Okay, wait longer
Finally the second mail (why not let the first one work?)
Click link
Opens site in a totally different browser window
Go back to the original window, find tab
Refresh
Read article
Cry
Upvote
73
(73
/
0)
Not to mention that if I’m reading on desktop for the reason of a larger screen and they send the link by SMS to my mobile, I have to open the site on my mobile.
How TF do I open it on desktop?
With robust functionality of generating and saving passwords using built-in password managers you’d have thought the issue of password reuse has been solved.
But it looks like the real issue is companies not willing to do the hard work and inserted offload auth security to email providers and plunge companies.
How TF do I open it on desktop?
With robust functionality of generating and saving passwords using built-in password managers you’d have thought the issue of password reuse has been solved.
But it looks like the real issue is companies not willing to do the hard work and inserted offload auth security to email providers and plunge companies.
Upvote
21
(21
/
0)
You don't even need that. Store the ID of the user logging in, the time you created the token, then a proper signature (HMAC-xxx will do fine, even a truncated one), and you're done - completely stateless. Validate it and you're golden. It's not one-time, but if you're rotating the key you're using for the HMAC regularly and the expiry of it is short enough, you're still well ahead. If you're wanting one time, log the successful ones only - that way you can generate an infinite number of tokens and only have to worry about the ones used for the short expiry time.
Upvote
1
(1
/
0)
Phone link SMS to desktop is already a thing. It's standard for all Apple ecosystem stuff, and Windows is trying its best.
Edit: Hell, Safari MacOS automatically pulls SMS tokens out of Messages for you if you let it.
Upvote
-6
(2
/
-8)
As someone with a password manager it's a huge annoyance. I get it's trying to help people who are bad with passwords and reset every time they log in, but leaving two options would be pretty nice.
Upvote
22
(22
/
0)
- Add bookmark
- Featured
- #25
Exactly! The paper mentions all links were not one time and at least 1 year old and some even from 2019. Also, the majority of services had lower than required entropy.
It doesn't make sense for a newsletter but the paper mentioned financial services among top 3 industries.
The paper not only mentions enumerable but also weak random characters. For example a 5 character alhpanumeric token for a service with large userbase like Everquote. That's why it got a hit even within 10 manual attempts of changing the token.
Upvote
4
(4
/
0)
5 character? Holy hell, even with base 64 that's only 30 bits. I get twitchy at less than 128. SMS is tight, but not that tight.
Edit: SMS uses a weird restricted character set, not allowing complete ASCII, so have to be really careful. I think base64-URL is ok, and maybe standard base64 is ok too. When I'm not sure, I just use base32 because there's virtually no place it's not safe and it can be case insensitive.
Edit 2: https://en.wikipedia.org/wiki/GSM_03.38 for SMS. Notice "_" is not in the standard ASCII place just to show how odd it gets.
Last edited:
Upvote
4
(4
/
0)
- Add bookmark
- Featured
- #28
One thing I run into fairly often are sites that refuse to send a 2FA SMS message to a VOIP address. This usually shows up when they ask for a "cell phone", but then reject a VOIP phone number. Most VOIP providers have a way to send/read SMS messages from a VOIP phone number via a web browser. I will admit that the SMS message is subject to attack on the VOIP provider's servers (also true on the servers of the sites with these policies), but in terms of remote access, that is over https, and should be as secure as the over the air encryption used by SMS to transmit to a user's phone. So I really don't understand why these sites discriminate against this type of SMS.
Upvote
8
(8
/
0)
Honestly, passwords are a bad idea too. They should be migrating to Passkey and use the SMS/email link as a recovery mechanism. I've switched my own IDP to that though I still have a link to "legacy login" which is username/password/TOTP as a fallback because I'm paranoid right now. I think sooner or later I'm just going to turn it off (passkey only, passkey + legacy fallback and legacy with optional passkey support are the options I have - passkey is always available, its just a question of what the priority is for legacy)
Upvote
-5
(3
/
-8)
Two of the big one mentioned in paper having millions of active users, iHire and Everquote, both have 5 character tokens. More than 72% of the service providers had less than 64 bit entropy.
That's a mistake in the writing. The paper mentions 322,949 URLs.
Upvote
2
(2
/
0)
~60 bits (10 character base64 or 12 base32) I can almost see if its for a random token that's very short lived - it's a large enough space that brute forcing it should hopefully be impractical. But you're back to making sure all the factors like short live are actually there.
30 isn't even close though. That's about a billion, and sending a billion requests to a large service from a botnet? Well, they'll notice it, but probably too late.
Upvote
2
(2
/
0)
True, service providers with small user base might get away with a little lower entropy but those with millions of users should certainly be near the 64 bit mark. The paper notes this 64 bit is actually based on OWASP recommendation in "Insufficient Session ID Length"
Upvote
3
(3
/
0)
That 64 bit length is probably a bit due for revision. Anything I write would scream blue murder if you set a key used for internal derivation to anything less than 128 bits. It'll accept it, but it'll scale it's internal use up with 256/384/512 bits (and unfortunately truncate at 512 bits, because it's deriving keys using SHA functions or similar)
Edit: I worded that wrong. It won't accept <128 bit, and at 128+ it scales up the longer the key.
Upvote
2
(2
/
0)
Shout out for KDE Connect too.
I use it on Linux and Windows , to connect both Android and iPhone. Bloody magical.
Does all sorts of sharing (clipboard, files, remote input, presentation remote) between devices, is open source, is rock-solid, and gives a standardised experience between all platforms. All software should be like that.
Looks like there's a MacOS port in the pipeline too.
Upvote
8
(8
/
0)
- Add bookmark
- Featured
- #35
I agree, but they don't even meet 64 bit entropy requirements. There are also cases where they have long strong tokens in the final redirected URL but the initial URL sent to user has been shortened with a short token which makes the final stronger URL useless. It's pretty dumb but it's still true in real world applications.
Upvote
5
(5
/
0)
Honestly, I think 60 bits is "close enough" if 64 fits their use case. But they're very much having to make a decent argument that it's good enough at 64 bits in the first place, which can be done if they know their use case well enough. 96? Yeah, wouldn't really care. More than 64 and plenty enough for most token lengths I think - it's the nonce size typically used in GCM for example. The only reason I set my limits at 128/256/512 bits is because I don't write standards for things I use, and sometimes I'm stuck dealing with those exact figures in places, so I have to make sure nothing stupid gets used by mistake. When I actually set my keys when configured, I just randomly generate something long enough and stick it in the config and forget about it after that.
Upvote
2
(2
/
0)
I agree, its good to be on the safer side, especially when the cost of doing so is negligible, considering how rapidly things are evolving in the tech space.
Upvote
0
(0
/
0)
And longer key lengths crunched down to reasonable text isn't hard. That's what the base-X stuff is for. When I see long hex strings and just want to face plant the desk - computers don't care. For my own uses, I just use base-32 and make it lowercase mostly because I find it easier to stare at in logs and debugging - aesthetics basically. Again, the computers don't care....
Edit: tokens, not keys. Tokens can end up exposed to people, but keys are internal and all binary objects.
Last edited:
Upvote
1
(1
/
0)
MilanKraft
Ars Tribunus Angusticlavius
Not fully understanding the implication of this story, but I know someone here can clear this up, so here goes.
Based on info from this article / study, is it correct to say that any legit services site, which:
A) Requires you to generate an account ID, but specifically does NOT allow passwords, and
B) When logging in, instead sends you a code via email or SMS, which you then copy-paste into the supplied field...
... is by definition a security flaw that easily allows anyone to gain access to your account and the info in it, without actually having access to your phone or email (essentially because it's easy to guess or force-generate the right code)?
If so, it seems to me the solution is for everyone to find the legitimate services they use which have this flawed approach, leave the service if you can with an email to their customer service that you're leaving because their login method is one giant security flaw and that strong password + 2FA is a bare minimum to get by in this world.
Additionally, is it correct the implications in this article do NOT impact the many legitimate sites that require BOTH an ID and a strong password, and THEN, both having been supplied by the user, requires them to retrieve and paste a numeric 2FA code from their phone / email to complete the login? (Assuming all certificates, server setups, etc are solid.)
Based on info from this article / study, is it correct to say that any legit services site, which:
A) Requires you to generate an account ID, but specifically does NOT allow passwords, and
B) When logging in, instead sends you a code via email or SMS, which you then copy-paste into the supplied field...
... is by definition a security flaw that easily allows anyone to gain access to your account and the info in it, without actually having access to your phone or email (essentially because it's easy to guess or force-generate the right code)?
If so, it seems to me the solution is for everyone to find the legitimate services they use which have this flawed approach, leave the service if you can with an email to their customer service that you're leaving because their login method is one giant security flaw and that strong password + 2FA is a bare minimum to get by in this world.
Additionally, is it correct the implications in this article do NOT impact the many legitimate sites that require BOTH an ID and a strong password, and THEN, both having been supplied by the user, requires them to retrieve and paste a numeric 2FA code from their phone / email to complete the login? (Assuming all certificates, server setups, etc are solid.)
Last edited:
Upvote
0
(0
/
0)
It's applicable to all services which otherwise does or does not require a password, but the issue is when they send a magic link and that magic link has no or weak authentication before showing user PII or giving escalated privileges. The guessing part is only true when the token in the URL or the authentication parameters do not have rate limiting or timeouts.
Also, the links this study covers are not only 2FA otps. They are sometimes links to continue your incomplete insurance quotes or a link from a friend to RSVP for their wedding.
If the service you used only rely on these magic links to give access to your info or profile and these links are neither temporary nor have strong tokens, then you should leave the service and report.
I hope this clears it up. If you have time, go through the paper along with the article to understand it in detail.
Upvote
6
(6
/
0)