Why is using SMS bad for 2FA? | Hacker News Reader

Why is using SMS bad for 2FA?

17 pointsPranavBerry26 comments

I have read in a few places that using SMS is really insecure for 2FA. A few people on this thread (https://news.ycombinator.com/item?id=29004930) also said that SMS should be avoided as the 2nd factor.

What are the security vulnerabilities with SMS? How common are these vulnerabilities? Have there been any security breaches due to these vulnerabilities?

PS - I am ideating on creating a 2FA method using public-key cryptography. To login, you just scan the QR code from my authenticator and enter your phone's pin or use Face/Touch ID. This uses two factors so, first it ensures that the users posses the phone and second it ensures that the user knows the passcode or has Touch/Face ID. Please let me know if you have any feedback on this idea and if this solves the problems with SMS.

View on HN

SMS has poor end to end security. It's not end to end encrypted, and there's no guarantee of effective transport encryption, and the parties involved may not be trusted.

In the common case, the sender will submit an SMS to an aggregator. The aggregator may send it on to the carrier's gateway, or another aggregator or a 'grey route'. Grey routes are usually things like gsm modems or automated phones with consumer oriented service plans. The carrier's gateway may be operated by a third party, and is hooked up to the internal messaging system.

Generally speaking, all of these points log message content for a significant amount of time, and often logs are available in near real time. That's potentially a lot of people who have legitimate access to view the messages in real time; if any of the points in the message flow have a security issue, your messages are vulnerable. And the message flow is opaque.

Sometimes, the over the air part of the messaging isn't well encrypted either, so being in the right place with the right equipment gives you access to the codes, without any insider access.

With respect to your idea... If I'm a common person with one phone and no other computing devices, how do I scan the QR code on the screen from the app I want to login to with the app you've provided. Also, when I lose/drop/etc that single device, how do I get my account back? Account recovery that relies on users to take proactive steps tends to be low success. This is the hard part, and where SMS as 2FA tends to do well; account recovery is outsourced to the phone companies of the world.

>If I'm a common person with one phone

I had not thought about that but I think I can add push notifications if this is a problem. So on your phone you just tap the login with my authenticator button and approve the push notification in my authenticator app.

>how do I get my account back?

You can optionally add a recovery email.

SMS is not a great form of MFA but in many cases it is the only option and better than nothing assuming it was implemented correctly, being one of multiple factors and is not a stand-alone factor. Someone will suggest U2F, but most financial institutions don't even know what that is much less have any plans to support it. This will sound negative, but sadly my login to a video game is more secure than my login to a bank and I do not see that changing in my lifetime. I would love to be proven wrong. For now I have set most of my bank accounts to read-only meaning I have to go into a branch office, show ID to do anything.

As for QR codes, those can be copied or replaced. Maybe if my bank had a QR code behind secured glass that could be used to locally on site import and pin their public certs if applications widely supported it. I will never use digital face/touch ID for anything. There are no companies or governments competent or qualified to hold that information and use it for authentication and authorization.

>As for QR codes, those can be copied The QR code are unique for every login attempt. After you scan the QR code and enter your phone's pin, my authenticator will send a request to my server. If everything is ok you will be logged in. Sorry I did not get what you mean by this? Do you mean that someone could copy and use the same QR again?

>I will never use digital face/touch ID for anything I do not save any biometrics on my server. They are stored locally on your phone, my app just uses the native system used to unlock your phone. That being said, you can just use your phone's pin if you don't like to use biomterics.

Do you mean that someone could copy and use the same QR again?

A person intercepting traffic or spoofing a site can copy/tamper/replace the QR code just as they can plain text or binary blobs. QR is just a presentation structure that makes it easier for a camera to translate something into data. For this to be useful there would have to be a boot-strapped chain of custody and chain of trust already installed on the device scanning the QR code meaning you know where that trust came from and you can verify it against a trusted source. If this is not what you meant then where is the end user getting the certs used in this QR code from? Are you embedding the certs in the application? How do people know the application has not been copied/tampered with?

>intercepting traffic or spoofing a site can copy/tamper/replace the QR code

Will this be a problem with HTTPS?

When you open a page, a request will be made to my server to generate a unique login attempt, the id of this unique login attempt will be shown in the QR code. When you scan it and enter your phone's pin, my authenticator generates a signature of the login attempt id, your username on that website and the current time. My server verifies the signature and logs you in if everything is ok.

Have you logged in to the Discord/Reddit/Whatsapp websites by scanning the QR code shown there from their mobile app? My concept is the same but using my authenticator app, websites which do not have a native app can also offer a QR code login.

I've seen people use QR with those sites and it doesn't make sense to me. So using a bank as example, I barely trust them to get this right. Now I am inserting your company into the chain of trust? Why am I trusting one more party to get all of this right? Or is this a solution you are selling to each vendor and they are implementing your service on prem? Is your service going to be audited by independent third parties that vendors choose? How do people verify that your application is the legitimate version? How does the bank know if someone has tampered with your application? Why is my bank trusting your application?

>Is your service going to be audited by independent third parties that vendors choose?

Yes I am planning to do that.

>How do people verify that your application is the legitimate version? How does the bank know if someone has tampered with your application?

I will use SafetyNet to check that the device is not rooted/jailbroken and that the signature is being made from my app.

> SMS is not a great form of MFA but in many cases it is the only option…

Email?

Valve and a few other gaming companies will use email. I have seen one financial institution use email as well. SMS seems to be more widely adopted. I should clarify and mention when I say only option, I mean for the end-user. Companies could in theory implement anything if they prioritized it.

In my personal experience, email is often accepted. But that wasn’t my point. You said SMS is often the only option, but I don’t see why companies couldn’t support email as well.

Edit: I guess my point is that since this post is essentially asking what should be prioritized, I think that companies should prioritize providing email as an option if they provide SMS.

Agreed. I can add TLS checks on my mail server to validate where mail is coming from for specific domains. I would love to see more companies support this option.

There are many ways to intercept SMS such as having a corrupt person who works for your carrier. This place got hacked too:

https://urgentcomm.com/2021/10/07/syniverse-quietly-admits-i...

Also what fraction of people are going to let their phone number lapse over the next 20 years? If my goal is not "target somebody in particular" but "cultivate false identities" the range for mischief is greater.

Thespian2 in that thread commented at https://news.ycombinator.com/item?id=29005345 :

> SMS - it's just too easy for SIM swap attacks, and good social engineering to phish SMS codes. "Hi, this is $BANKNAME - we saw some suspicious activity on your account, so we are going to send a one-time code to you now. Please enter it back to us here to verify your identity" (scammer then uses your stolen password, tries to log in, real bank sends you real code, which you now are tricked into sending to scammer to complete their login as you).

First three DDG hits for "SIM swap attack" are https://www.consumer.ftc.gov/blog/2019/10/sim-swap-scams-how... and https://us.norton.com/internetsecurity-mobile-sim-swap-fraud... and https://privacypros.io/u2f/sim-swapping/ .

Here's a recent news piece on the topic: https://www.lightreading.com/security/heres-how-atandt-veriz... ("The FCC has received numerous complaints from consumers who have suffered significant distress, inconvenience and financial harm as a result of SIM swapping and port-out fraud".)

SIM swap is not a problem in other developed nations where everyone is using a government ID. Still SMS based 2fa has many other problems.

> SMS based 2fa has many other problems

What are these problems? It will be great if you can list some of them, I'd like to read more in detail.

SMS generally requires a cellular phone. Some people don't have one. Me, for example.

Problems with SMS:

- it's best effort: message may (or may not) be delivered; they may (or may not) come in order; they may (or may not) be timely

- SIM stealing/swapping is not hard

- it's all plain-text

- if you fatfinger the phone number, your auth code goes to the wrong place

>To login, you just scan the QR code from my authenticator and enter your phone's pin or use Face/Touch ID

Others see the problem with having to scan your QR code while using the device that, presumably, needs the QR code scanned ... you've just mandated multiple devices

You might look at SQRL (https://www.grc.com/sqrl/sqrl.htm)

Or just use "normal" TOTP systems like the myriad authenticator tools already out there

This is exactly why: [0]

[0] https://news.ycombinator.com/item?id=29254051

You might want to look into what the FIDO Alliance is doing with WebAuthn. The problem is already being solved.

> FIDO Alliance is doing with WebAuthn

Yes I looked into it, but it looks like WebAuthn does not support multiple devices (let me know if I am wrong).

What if I want to login from two different devices? I don't think that is possible with WebAuthn, but using my authenticator you can login to multiple devices. You will also be able to add a recovery email address to my authenticator to recover your accounts if you phone gets damaged/lost.

Yes it is. I can plug my Yubikey into as many laptops as I would like.

> You will also be able to add a recovery email address to my authenticator to recover your accounts if you phone gets damaged/lost.

This worries me. That means I have to trust you to not leak my 2FA. Authy does this already and so I don’t use Authy. All my 2FA is on my Yubikey.

> plug my Yubikey into as many laptops as I would like.

What if you don't own a physical key?

> I have to trust you to not leak my 2FA. Authy does this already and so I don’t use Authy

This is optional. You can choose not to have a recovery email. Just curious though, what do you do if your Yubikey gets stolen/damaged/lost?

I have a backup Yubikey as well as backup codes stored in an encrypted file and backed up to several different devices.

Why is it bad: prone to mitm attacks in many ways.

Better alternative: hmac based totp

Reply on news.ycombinator.com