Millions of people imperiled through sign-in links sent by SMS

Even well-known services with millions of users are exposing sensitive data.

See full article...

 

[huckl]

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.

 

[radulov]

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).

The entire telephone ecosystem is built on trust and poor security. relying on them is bad

 

[Num Lock]

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.

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.

 

[Fatesrider]

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.

I think this probably is why they're calling out SMS:

Easy to execute at scale​

A paper published last week has found more than 700 endpoints delivering such texts on behalf of more than 175 services that put user security and privacy at risk.

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.

 

[cs-maestro]

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.

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.

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.

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.

 

[SeanJW]

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.

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.

 

[Nop666]

The absolute most user friendly login system I have ever used is the one for members on https://www.wheresyoured.at/
There is no password at all, no SSO, no 2FA logging in simply requires inputting an email address then either clicking a link 1 time link in the email or entering a 1 time code. The code is 6 digit numerical and the link seems to contain plenty of entropy.

You might think that failing to require a password is a security issue, but, if someone has access to your email, they can just change your password, so for most typical uses a password doesn't add any meaningful amount of security.

Sure 2FA makes sense for more important sites, but for access to a premium newsletter it's perfectly cromulent.

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.

 

[Resistance]

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.

It doesn't leave you signed in?

 

[nondescriptusername]

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.

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.

 

[Nop666]

It doesn't leave you signed in?

Nope. :|

 

[mrkite77]

By incrementing the token—for instance, by first changing 123 to 124 or ABC to ABD and so on—the researchers were able to access accounts belonging to other users.

Jesus.. It's called a cryptographic nonce you idiot programmers. Generate a random one and store it in a table with an expiration date.

 

[adamsc]

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.

 

[Fred Duck]

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...)

(Hi Ed Zitron, I'm a huge fan!)

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/

Jesus.. It's called a cryptographic nonce you idiot programmers.

That's rather strong language there. o_o

 

[dangoodin]

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.

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.

 

[Derecho Imminent]

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.

 

[silverboy]

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.

 

[ghostwalrus]

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

 

[starglider]

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.

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

 

[wicker_man]

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.

 

[SeanJW]

Jesus.. It's called a cryptographic nonce you idiot programmers. Generate a random one and store it in a table with an expiration date.

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.

 

[SeanJW]

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.

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.

 

[Eldorito]

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.

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.

 

[cs-maestro]

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.

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.

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.

It doesn't make sense for a newsletter but the paper mentioned financial services among top 3 industries.

Jesus.. It's called a cryptographic nonce you idiot programmers. Generate a random one and store it in a table with an expiration date.

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.

 

[SeanJW]

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.

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.

 

[kurama101]

The researchers collected 322,949,000 unique SMS-delivered URLs extracted from over 33 million texts

Average SMS contains 10 URL links factoid actualy just statistical error. 2FA Georg, who authenticates 315 million login attempts every year, is an outlier adn should not be counted

 

[whobeme]

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.

 

[SeanJW]

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.

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)

 

[cs-maestro]

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.

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.

Average SMS contains 10 URL links factoid actualy just statistical error. 2FA Georg, who authenticates 315 million login attempts every year, is an outlier adn should not be counted

That's a mistake in the writing. The paper mentions 322,949 URLs.

 

[SeanJW]

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.

~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.

 

[cs-maestro]

~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.

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"

 

[SeanJW]

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"

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.

 

[agt499]

Phone link SMS to desktop is already a thing. It's standard for all Apple ecosystem stuff, and Windows is trying its best.

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.

 

[cs-maestro]

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.

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.

 

[SeanJW]

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.

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.

 

[cs-maestro]

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.

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.

 

[SeanJW]

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.

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.

 

[MilanKraft]

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.)

 

[cs-maestro]

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.)

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.