Why is using SMS bad for 2FA?
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.
(
26 comments
| 17 points
| on HN
)
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.
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.
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.
>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.
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?
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.
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.
Email?
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.
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.
> 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".)
What are these problems? It will be great if you can list some of them, I'd like to read more in detail.
- 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
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
[0] https://news.ycombinator.com/item?id=29254051
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.
> 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.
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?
Better alternative: hmac based totp