Bottom line up front: When sending tokens via SMS, you must include a "do not share this token with anyone besides X.com" text. Otherwise account takeovers become trivial.
The article's attack is relatively benign - the user simply goes to a website. Sure they may end up putting info in that website, but probably not. Plus existing systems for malicious website filtering can kick in to prevent this.
The more concerning attack is the social engineering one where a third party says something like "let me 'verify' your identity, I'll send you a number tell me what it is" then triggers an identity verification request on the domain (this can be done either manually or part of a sign up flow for some honeypot service). Now the target needs only relay 6 digits to someone they already "trust" and are in a conversation with, versus in the article's example they needed to put their full account info into an unknown website.
There are valid use cases to ignore the text message security advice. When I set up an account with my bank, I got an SMS security code that I had to read out to my banker to proceed with the account. The SMS did say not to share the code with anyone, I knew he was signing into the banks system, and I deduced that the system bankers use must be the same system normal users use, so this made sense to me. But an unsophisticated user would not know this, and would become to trusting of the helpful stranger asking for the SMS code despite the message text.
There are institutions out there that are training your users to ignore your security advice.
They phish users with horribly made emails with no formatting, then they send the same sort of emails for legitimate things. They give security advice and then break their own security advice.
Unless you’re a government (or contractor) your threat model isn’t some side channel timing attack on your CPU, its users complacent with security created by you. Legitimate emails should look legitimate the first time, security advice applies always and everywhere. It’s not that hard.
I did exactly this with Fidelity's customer service, and I was impressed to see that the text message I received did NOT say "don't share this with anyone", like their normal login messages do. Instead, it said "give this code to the customer service representative". I was so pleasantly surprised I actually had to commend them on it.
Even better would be: ask your rep what his or her favorite animal is. If he or she answers giraffe, then share this code. Otherwise hang up and dial the number on the back of your card.
If the warning not to are is not worded carefully enough then a second message could be sent by an attacker before or after instructing the user to disregard the warning.
Hello, this is Fidelity customer service, and to confirm this, we will send a text message with a code to the phone number you registered with us. For security, please confirm you are our customer by responding with the code.
Narrator: No, it was not Fidelity, but a scammer who needed the code to drain the customer's Fidelity account.
> We are training a large group of users to automatically click "agree" on a random box that appears on the bottom of the page (sites violating GDPR). Absurd.
I think a lot of people on this thread are forgetting just how easy it is to spoof SMS.
- SMS has a field called sender ID, which is set by the sender, requires no identity verification, and can be any arbitrary short string.
- This allows anyone to send messages to any number, identifying themselves as whoever they want to impersonate.
- And since there’s no sender phone number in the message, your phone can’t tell real and fake messages apart.
- And so it groups them into the same conversation
I’ve noticed multiple companies abuse this system by having customer support verify your identity with an SMS code that also includes the “don’t share this with anyone” snippet.
Even my former bank did this. Companies can include the warning all they want, but they’re already teaching consumers to ignore it and break the rules.
The article's attack is relatively benign - the user simply goes to a website. Sure they may end up putting info in that website, but probably not. Plus existing systems for malicious website filtering can kick in to prevent this.
The more concerning attack is the social engineering one where a third party says something like "let me 'verify' your identity, I'll send you a number tell me what it is" then triggers an identity verification request on the domain (this can be done either manually or part of a sign up flow for some honeypot service). Now the target needs only relay 6 digits to someone they already "trust" and are in a conversation with, versus in the article's example they needed to put their full account info into an unknown website.