Security is relative; there is no absolute security.
SMS 2FA is not perfect, but it's MUCH better than what it replaced (nothing). ANY system with a human component will be at risk to social engineering attacks; not just SMS-based methods.
And shifting the attack surface to depend on social engineering (SE) adds important rate limiting; it's difficult to automate SE attacks.
Friction is also a critical factor: a low-friction B+ security solution may be better than a high-friction A+ solution. Consider total risk, not just point risk.
SMS 2FA is like a CFL lightbulb. It's 10x better than what it replaced, it's what we have now, but we know it's not the endgame (LED lighting).
What you say is true of actual 2FA, which only adds security. (Unless, maybe, you take into account risk compensation[1], which is probably magnified when SMS 2FA is less secure than users think.)
However, SMS “2FA” is often used to mean SMS-based password reset, where SMS can be used instead of the password. With SMS-based password reset, SMS subtracts a factor (EDIT: or divides by two[2]?), instead of adding a factor as in 2FA.
This is the case with the OP article. The text of the article is unclear about whether it means 2FA or password reset, and the title does include the term “SMS-based 2 Factor Auth”. However, the example issues that the article links to are all cases of password reset, not 2FA.
You are right, it's mostly password reset 2FA (often times it ties into auth SMS 2FA, so not necessarily mutually exclusive) - I will update the article and clarify that.
Rightly said... Here in india, the central bank had managed sms based otp validation for all online card transactions... Turns out that just doing that has kept card fraud down. It also helps in our country to inspire confidence with older generation that isn't super comfy with online transactions.
Now there have been cases of sim cloning etc to try and get around the otp, but all in all its a small percentage. Now I get support nervous when I do any international transaction and it just goes through without an otp SMS
Fwiw: if your card scheme is MasterCard or visa , regardless of (your) acquirer bank or merchant bank , you will be protected against fraud by something called chargebacks. If anyone ever uses your card to fraudulently order something , you have (a few months’) time to contact your bank and issue a “chargeback.” They will, through the MasterCard or visa (or similar) network contact the merchant’s bank, which will then take the money back out of the merchant’s account and give it back to you. E.g. if someone orders an Uber , your bank would ask Uber’s bank for the money back, and they would take it out of Uber’s account, and they have to pay a penalty to MasterCard (a “chargeback fee”). And if it happens often enough, MasterCard will bump Uber’s commission for payments. It’s tragicomic how shamelessly the banks are winning at fraud.
Side note: for low margin operations like Uber, this is hell: they can’t ask the money back from drivers, so they lose a lot of money on fraud vs their profit on regular transactions. The driver fee, the original payment, and the chargeback fee, and the potential payment commission bump.
The onus is on the merchant to avoid accepting fraudulent transactions, and if you want to contest a chargeback you better have some CSI level proof.
This is why most online shops will offer a money-back-no-questions-asked policy: they know you can get the money back one way or another, and it’s cheaper to just give it to you.
An insidious consequence of this is the price for this protection is amortised over all customers, in the end. Fraud is BIG business, and the money has to come from somewhere. Customers get angry when a merchant adds a CC surcharge, but they end up paying that surcharge anyway, it’s just not explicitly listed. And if you pay cash, you pay it too, without any of the protections. Cash payers subsidise CC holders.†
Long story short: don’t be nervous. Your card is safe. (Unless you’re on a different scheme with different rules, of course)
(This assumes regular payments without extra auth, like e.g. PIN or 3D Secure. Those rules differ slightly.)
†: to be completely fair: there are costs associated with cash, too.
SMS 2FA does more than provide extra security for your account. Perhaps more importantly to companies like Facebook and Google it also makes it much harder for spammers and bots to register accounts. At the very least it adds the expense of buying a SIM so you can use the number just once.
Risky if you're planning to use that SIM to prove that you're a legitimate person to a data mining company like Facebook or Google. That SIM gets reported stolen and your account could go up in flames, which is a big problem if you've been spending weeks grooming it to look real.
Ditching SMS 2FA normally means replacing it with some other 2FA mechanism (e.g. TOTP and/or U2F). Which is a good idea. I don't think anyone (except for some possible edge cases) are removing SMS 2FA leaving no 2FA options at all.
Also, it all depends on threat model. Rarely, but sometimes, when user's anonymity/pseudonimity is at stake - SMS can be a security risk. I think there was at least one service that had only SMS 2FA for which I've decided to not opt in just because I didn't want to provide that service with my contact information beyond what I already gave them. Not like that was a security issue - more like a privacy/spam one in my case, but I can imagine cases where user's identity is actually a security issue.
You use a company laptop and they have disabled usb or set off an alarm when you plug something in.
It should be based on phone however, since thats the one thing everybody cant live without and usually have on them.
It would be nice to see goog and msft make their authenticator apps interoperable, or a global standard all svcs can use, as authenticator apps seem to be the best thing going.
U2F does NOT require a hardware key - only a secure cryptographic processor. It could be built into your laptop. There were some rumours floating around that Chromebooks would receive fingerprint scanner that would enable this. It would make sense since U2F originated from Google.
The W3C is working on the Web Authentication spec: https://www.w3.org/TR/webauthn/ with (among others) Google and Microsoft contributing. Wide support for this would be the endgame OP mentioned.
How is that "not hardware"? If you meant a separate physical key, I think that's actually a Good Thing: you can have it on you and it's tiny in features - reducing the likelihood it would get tampered with, unnoticed; one integrated into a laptop is a part of a huge blackbox that you just need to blindly trust.
If you want me to swap from SMS two-factor you need to come up with something that’s as easy to use and restore when I drop my phone in the toilet, change my email and what other silly user mistakes I’ve lost my f2as to.
I eventually switched away from Google Authenticator to Authy because I found it incredibly frustrating that Google wouldn't let you migrate 2FA codes between devices (then, to add insult to injury, they let you migrate your Google token, and only your Google token). Authy has worked well for me so far, having migrated phones twice since then. I've also got it on a backup tablet just to make sure I'm never completely locked out if something goes wrong.
But for the security-paranoid, I understand that letting a cloud service store your 2FA tokens is suspect, even if it's password-protected. Steve Gibson suggests the alternative: when the site generates the QR code, take a picture of it, print the picture out, keep it in your safety deposit box. When you change phones, pull the QR codes out and re-scan them.
I have been researching how to dump the database of google authenticator (currently over 20 entries, some non recoverable), but the solution involves rooting my android phone and accessing a protected sqlite file, with a propietary (and version dependent) schema. I am not going to do that.
Does authy have the same workflow a google authenticator? Can I add entries with QR code? With ID? Can I dump the database in plaintext? (the IDs) Can it generate QRs for scanning with other 2fa tools?
Edit: ah, it's an online service. That kills it for me.
1Password captures and stores TOTPs, even copies the current OTP into your clipboard momentarily when you log in to a site. You don’t have to use their online service; you can keep the password vault in a file. You can sync your devices over LAN and WiFi.
Your passwords and two-factor keys should not be accessible through the same service. If 1Password is hacked, both forms of authentication are compromised.
So, if your phone using any password manager of your choice, Plus Google Authenticator for TOTPs is compromised, same level of risk, right? Because GA has no challenge nor authentication to dump your TOTPs.
> Because GA has no challenge nor authentication to dump your TOTPs.
Define "dump". GA won't challenge you to display the one-time TOTP code, no. It would be incumbent upon you to lock your device. But as far as dumping those codes out into a state such that a malicious actor could then take them and import them onto another device, no, that is not easily doable. As the distant parent noted, Google Authenticator stores the stuff in an encrypted sqlite database that is not extractable without root access. I don't think even run-of-the-mill adb debug commands can get it out.
Recently I had to send my phone away for repairs, and as instructed, they told me to reset the phone to factory defaults before mailing them the device.
I forgot about Google Authenticator during this process so ended up having to reset everything/go through recovery procedures across all my accounts.
With SMS it almost seems stateless, the only thing you need is access to a signal. That's the biggest advantage in my opinion, but given the risks I'd be open to ideas that are not just "download an app onto your phone"
That's, counterintuitively, security working well and as designed. It's not as convenient, you mean? Indeed - and it would be far more inconvenient to an attacker, which is the entire point.
I know it's not easy for grandmas/etc, but I personally love classic TOTP solution. It's stupidly simple to backup[1], works on all my devices - even my desktop if I want, and is completely secure[2].
It's a shame so many people have no clue you can (and should, imo!) backup your TOTP key.
[1]: just copy the string and store it however you want.
[2]: as far as I'm aware. I'm not a security professional, of course.
Yea sorry, I should have included a explanation - I used it instead of Google Auth to remove any implied involvement with Google. Appreciate your annotation!
Whenever a 2FA or TOTP article comes out, I ask if anyone knows of a hardware dongle/token/card that can store several TOTP keys so that I can stop using my phone for 2FA (e.g. Google Authenticator).
I've only found the Protectimus Slim NFC [0], which would be my ideal solution except it only holds 1 key.
If it could save say, 100 keys (or even 50 maybe?), I would buy 3 or 4 in a heartbeat. It would be great to have stronger 2FA than SMS, but with the peace of mind of not having to worry about the phone.
I'm definitely not a hardware guy, but I can't believe such a solution doesn't exist yet. It doesn't seem like it would be hard to build, right? I mean, you just need a very simple processor, a real-time clock, a display and an NFC module for reprogramming (or maybe micro-usb?).
Does anyone know of any products like the Protectimus but supporting multiple keys?
You're ignoring that the main TOTP app for most people, Google Authenticator, doesn't allow the keys to be exported. The current solution if you buy a new phone is to manually remove and re-add 2FA on every site you use it with.
> You're ignoring that the main TOTP app for most people, Google Authenticator, doesn't allow the keys to be exported. The current solution if you buy a new phone is to manually remove and re-add 2FA on every site you use it with.
I'm not ignoring that at all. Google Authenticator is the only one I use, even with the described workflow.
I back the key up immediately, when they're asking you to save the TOTP. They usually (not always!) give you multiple methods to input the TOTP, such as scanning an image or typing in a string. That string can be backed up, and is what I usually use.
I never renew my TOTP, and all I use is Google Authenticator. Anytime I get a new phone (nearly every year, heh), I just add my TOTPs back.
This of course doesn't work for non-tech people, it's a bit too manual. I acknowledged that in my first post, though.
I always save the key & qr code when setting up 2fa, in a seperate not-frequently-accessed keepass db. that way, when/if I change phone, I can re-set up the 2fa same as before,vfrom same qr codes and/or keys.
I’m a bit different in that I only save the backup code to the separate KeePass DB. I hadn’t even considered saving the key/QR code to it, which seems just as secure as what I do now.
Is it not that by each backup code, you can enter into account only once, whereas by key and/or qr code, you can essentially setup a new device to provide TOTP?
Well the backup code is for emergency situations (ie. to set up your replacement device and get a new backup code)! Sometimes they give you more than 1, E.g. Google gives 10. I have had the worry though, imagine using it and your PC crashing immediately..
KeePassXC supports TOTP, so you can store the seed with the rest of your password database (whether you think this is a good idea depends on what your threat model is for 2FA).
As an aside, Keepass is what I use for TOTP backups. I keep them in an offline backup(s), since they have no real need to be kept online at all times (like normal passwords/etc).
Well I have a few account myself and one with my wife. My wife also has two accounts and one of them she created after we got married with my last name.
I can keep my 2fa straight but I know she can’t. I’d bet there are similar people out there. The solution needs to be elegant enough to support all degrees of tech knowledge and even people who are forgetful, accident prone, etc.
No to worry, the US carriers are here to save (or destroy) the day and replace SMS 2FA with another NSA and hacker-friendly solution that's even easier to use than SMS 2FA:
That said, I think there's some tendency here to view security as binary: secure or not secure. In fact, SMS 2FA is far more secure than single-factor authentication with only a password for most users. I generate strong, unique passwords[1] for every site and store them in a password manager[2], so I have fairly strong guarantees that my passwords aren't likely to be broken. But how many users do this? I'd guess that the average user still makes at least one of the following mistakes:
1. Using the same password for their social media account, their bank, and Joe's totally-not-a-password-collection-scheme website.
2. A password containing a combination of names, birthdays, favorite quotes, or something similar which is easily broken through social engineering.
3. Short passwords with low entropy that are easy to brute force.
4. Back up authentication methods such as security questions or personal information which are basically passwords, but unchangeable and used by many sites (best friend in high school, mother's maiden name, SSN).
Passwords, as they are used by average people, are extremely, extremely insecure, and the fact that SMS 2FA is insecure for completely different reasons means that the combination of the two provides a real improvement in security over simply continuing to use single factor auth methods.
I'm not saying that we should keep rolling out SMS 2FA as if it's the best solution. But if a company rolls out SMS as a second authentication factor in addition to passwords, we should at least thank them for improving security before asking for better secondary factors. If all we do when we see SMS 2FA is complain to the company without recognizing that SMS 2FA is better than what was there previously, it sends the wrong message: that security-conscious consumers will never be happy and it's not worth catering to them.
As a user I find SMS-based 2FA much easier to use. It's a tough challenge to make authentication both secure and user friendly.
I've recently appreciated the Google and Facebook iOS apps just letting you tap 'Yes' to confirm identity. It still requires me to go and find the relevant app on my phone, but it's relatively low friction. Much better than Google's own Authenticator app. How secure is that method?
Any ‘push’ method to an app will end up being more secure than pure SMS 2FA, because it’s relatvely hard to MITM/hijack it, unlike social engineering your way into porting a cell number.
Well, security is only useful when it protects you when you're actually attacked.
Social engineering has shown that it's just about effortless to take down someone once they are targeted. It's about as hard to target someone as it is to read their whois address to a customer support rep.
I used to agree, but those attacks are pretty easy to do and have been reported on this site many times. Whereas the other solutions described in the post don't have that attack vector.
Well it however come with a big con, you become dependent of a third party implementation with dependencies and specifics rules whereas sms is amongst the most used and understood communication standard.
This blog post publicise Microsoft implementation but it’s the same problematic for every possible GAFAM specific solution.
Apple approach to include a secure and synced password manager in all their product is far more standard friendly approach imho.
TOTP codes like Google's and Microsoft's apps can use, as well as the U2F security keys, are standardized with multiple implementations in existence. No lock-in with those solutions.
A push method that contains a code, or a push method where you just tap "yes"? Because just tapping yes is much easier to MITM/hijack. The attacker just has to log in at the same time as you're trying to log in, and you will tap accept and let the attacker in.
I know I recently got something from T-Mobile asking if I wanted to set up a password that I had to give in order to port my number out. I called up T-Mobile and set it up.
Agreed with the easier comment. Any replacement has to be at least as easy as SMS. I honestly don't think that a replacement which requires an individual app on the phone is going to reach the same levels of use as SMS.
Google Auth style rolling OTPs get frustrating anytime there's a poor server implementation - where time drift is not well accounted for. I've had my company VPN reject valid tokens too frequently. 30 seconds, plus any drift in time (insert general rant about setting up VMs without ntpd), is just not always enough time.
IMO, 1Password with TOTP integration is even easier. When I pop 1Password to log in to a site, it copies the TOTP to the clipboard so I can paste it at the next prompt.
The problem that I have with Authenticator Apps, is that they are a usability pain... In order to get the code, I need to abandon my current context, open the app, copy the code, go back and then paste the code.
With an SMS I just need to wait a couple of seconds and the notification comes up. I don't have to abandon the app or switch context.
That's why I always choose SMS over the other 2FA options. It could be less secure but in the bigger context is still adding a second layer of authentication and is far more convenient than using the authenticator apps.
Bitwarden (password manager) automatically copies the one time pin into the clipboard when you use the password autofill function. It's great for keeping context. Use autofill, then tap/click the OTP text box and paste in the code.
With that said, I'm not sure it's the best idea to store 2FA and passwords in the same system, but it is pretty convenient.
As someone that is expat / travels a lot, can you please make this stuff optional or give me options other than SMS? I keep getting locked out of everything. I despise SMS 2FA.
You could use https://jmp.chat/ for your phone number - with JMP your phone number is accessible whenever you have Internet, regardless of which wifi/carrier you're using. That probably gives it a few other advantages for a frequent traveller like yourself, aside from avoiding the account lockouts you mentioned.
The problem with moving away from SMS authentication is that not everyone in the world has a smartphone or is able to use something like a Yubikey. SMS is the lowest common denominator that allows most people in the world to use 2FA. If you require 2FA and don't allow SMS, you cut off access for a lot people, including the poor and likely the elderly.
SMS doesn't have to be the lowest common denominator, it's not a binary option between SMS or everybody having U2F devices.
In Denmark there's something called NemID [1], which is basically just a credit-card sized piece of plastic with a bunch of 6-digit one-time passwords on it. It's very accessible, maybe not as secure as U2F, but definitely more secure than SMS.
It ought to be possible for the tech community at large to come up with solutions like this that are better than SMS, but still accessible, just as the push-to-approve 2FA mentioned in the OP.
If official websites (tax, banks, etc...) start to use app 2FA, people with only a mobile phone will have to use, what, physical mail ? Or will they have to go to buildings in person ?
I agree that the more secure the better, but we mustn’t stop thinking of a big part of population that can not afford smartphones (or key or whatever).
Same problem for non technical persons.
Why worry about people affording it? TOTP hardware keys are super cheap, just give them out to people without phones at the local BMV. There are some that are credit card sized and one battery lasts 5+ years.
Alternatively there are a number of desktop based 2FA clients:
The thing you're missing is that you're still at the mercy of the establishment with which you're authenticating. Just like how my 1024-character banking login password doesn't stop my bank from giving someone else my debit card.
To suddenly arm a bunch of people with a new authentication paradigm like hardware keys would just result in a lot of people losing them and then having to go through the establishment's reauthentication channels anyways, which are the weakest link in these systems. And the influx of people needing account resets further degrades the security of the channel the same way you stop asking to see IDs when customers are paying with credit during the lunch rush.
Approaching this a different way, this is the same problem as with passwords. If you use the same password for every site or the same phone number for every 2FA SMS, then only one password/phone number has to be compromised for a massive escalation in privilege.
This problem is much easier to solve with passwords: you simply generate different passwords for everything and store them in a password manager. However, you can't (easily) generate a new phone number for every service that requires SMS 2FA, and if you could, all the phone numbers available would be used up quickly.
> If you use the same password for every site or the same phone number for every 2FA SMS, then only one password/phone number has to be compromised for a massive escalation in privilege.
> store them in a password manager
using your logic, only one (master) password has to be compromised for a massive escalation in privilege.
> using your logic, only one (master) password has to be compromised for a massive escalation in privilege.
No, if you got my master password somehow, you'd also have to gain access to my thumb drive or backup hard drive where I have the password database.
That can definitely be done; I have no illusions about the impenetrability of my personal security. But there's a very large incentive for hackers to compromise large databases of passwords from popular websites, and very little incentive for them to compromise my personal password DB.
Additionally, my master password is the strongest of my passwords, with about 124 bits of entropy, so this narrow point of failure is strong relative to my other passwords. The strength of security at the various websites I use is unknown, and if I use the same password for all of them, only one has to fail for my password to be exposed. Obviously it's still possible that my password could be collected by a keylogger or some such, but that's a lot less likely than that one of the 100+ websites I've ever put a password into gets compromised.
This has been fairly thoroughly discussed ad nauseum elsewhere--the argument you're making has been made and debunked many times, so let's not rehash tired arguments.
This. For ordinary people, the key to security is avoiding centralized data stores for sensitive information. If someone hacks a website I use, they will only get that one random password. If they want to get my master password, they need to break into my home computer, in which case they'll only get access to a single person's digital life, which is probably not worth the effort.
If Mossad or the NSA wants to steal my passwords, they will get them, but I'm just some random nobody, so that's not my threat model.
A hack against your password manager isn't going to be targeted at you as an individual. It will happen to one of the major companies who develop the software. The security of the product is only as good as the weakest link at the company.
Where is their source control stored - GitHub? How strong are the passwords of the developers (and managers, etc.) who have access? Do they use two-factor auth? How easy is it to social engineer one's way in, and add a commit to the app so that the next release decrypts all credentials and sends them to the hacker's remote endpoint? It's probably 3-5 lines of code to sneak in. The possibility of a "disgruntled/ambitious employee" exists, too.
There's also the browser extensions. I know web extensions are sandboxed, but does that include preventing a malicious extension from capturing the keystrokes from your password manager's master password text box? Each of these companies also has a website UI where you can view/manage your passwords; they load data into local storage - thus not being decrypted on the server side - but these are still vulnerable to cross-site scripting attacks, etc.
I think it's inevitable that one of the major password managers will wind up being compromised. Such an event would be catastrophic.
Sure, it's possible to use a badly-designed password manager, such as using a centralized or closed-source password manager. I'd say this is still more secure than using the same password everywhere, because it only involves trusting one entity with the keys to everything, rather than trusting multiple entities with the keys to everything. But it's definitely a bad security practice.
The password manager I use is KeePassX. In both the KeePass and KeePassX varieties it stores the passwords locally, so the only vulnerability you mentioned that it's vulnerable to is that malicious code would get into the source. One would hope that this would be caught by auditing, but of course it's always possible it wouldn't be. However, this is a only a possibility: it's guaranteed that one of the sites I log into with a password will leak that password at some point. So using KeePassX is definitely safer than using the same password everywhere.
> I think it's inevitable that one of the major password managers will wind up being compromised. Such an event would eclipse the Equifax breach.
Sure, if it's one of the password stores that stores its passwords centrally. But that idea is so backward that I barely consider such systems to be password managers--I'd file those under the "Joe's totally-not-a-password-collection-scheme website". The simple answer is don't use those.
If it's one of the password stores that stores passwords locally, then it will only leak passwords of users who update their password store software between the breach and when the breach is discovered.
You can come up with scenarios where any password scheme will be broken if a user does completely the wrong thing, like posting their password publicly. That doesn't mean password managers are a bad idea, it just means there's no such thing as an idiot-proof security system.
My 401k provider recently rolled out 2FA for all accounts. It's mandatory and SMS-only. From the user-side, is there anything I can do short of complaining? Anyway to "convert" to a non-SMS version?
Strong password & rotate it. If you're worried about 1 of the 2 factors being less secure than the other, and you can only control 1/2 factors, focus on the 1 you can control ;-).
The nice thing is that 2FA over SMS should, at least, degrade to being a possible notification channel that something is amiss. Keep your password strong and at least it will become a ping message that someone has compromised your password.
use a third party service for sms like google voice, or jmp.chat. yes, it just shifts the problem from your telecom company to a third party, but at least those providers have stronger authentication (google has totp/u2f, and jmp.chat has whatever your xmpp server provides) than what telecoms have.
specifically what? i already stated google voice and jmp.chat both have better authentication and 2 factor options than most cell carriers, are they're probably harder to social engineer. since they're internet based, they aren't vulnerable to SS7 exploits. I'm sure if you tried hard enough, you could hack them as well, but at least it raises the difficulty from anyone who read a social engineering guide to nation state or an APT.
afaik the ss7 exploits essentially involve a rogue carrier saying "hey verizon, your client 212-555-1234 is roaming on my network, plz send all his calls/texts to me". i don't think this attack applies to non-mobile providers because there's no roaming. and unlike the internet, there's no bgp-like system[1] for "announcing" phone numbers. it's all centralized, which should reduce your attack surface from every telecom in the world, to the originating telecom, whoever's in charge of the numbering database, and your carrier.
Even the largest companies are not thinking through this carefully enough. When Google wants to verify a login, my android phone comes up with a special proprietary Google prompt. Seems nice, but let's look at the flip side. Apple does this too, and about 5 years ago I had an iPhone. Recently I tried to download apps on my mac - and it suddenly required a password - so I tried a bunch of different things I probably had. Nothing was working. I got to a screen to reset the password, and they have a correct working email address for me. Except instead of offering reset via email, there is a prompt for my security questions. I checked my keepass entry for my security questions - SHIT I forgot to record them :( (my mother's maiden name is something like SDFDS$%FE#23 to Apple). So now it leaves me with one more option - authenticate via "..."'s iPhone! I'm thinking great! I will get a text message on my android in a few minutes (since the number is the same). No luck - suddenly I realized that "reset via iphone" means that a special app on my (smashed with a rock-hammer) iPhone will never ever be able to run.
Security questions are a generation of security behind TFA. Everybody was born in the big city closest to their Facebook hometown and your teachers' names are all in the online version of the yearbook.
Apple is a hardware company. Google is a consumer cloud services drvien advertising company. It's no surprise that Google's cloud security is decent and Apple terrible.
Phone-number-based two-factor authentication almost locked me out of my PayPal account. The account was registered to my home phone in Canada, but I was traveling in Asia. When I tried to log in from my seemingly suspicious new location, PayPal required a confirmation by calling my number and announcing some digits. Very fortunately my home phone used Voip.ms, so I was able to log on to that account and redirect the call to the physical phone I had on hand. Ideally I would decline phone 2FA because my home phone or cell phone number could become unusable and lock me out of accounts.
That's a true problem, and one that needs solving even if SMS isn't used for 2FA.
It's worth noting that this is one more case of a USA-specific problem caused by inability of commercial providers to securely verify identities of people; the same thing is much more difficult (though still possible) and thus very rare elsewhere.
Just throwing in a argument against hardware keys like Yubikey compared to SMS: Phones are good in that that their owners depend on them and will notice that their phone is missing in a relatively short period of time. Whereas lots of people will have no qualms lending out a hardware token indefinitely in order to help a colleague.
It might not tip the balance all the way back so that hardware tokens end up being worse for security - it just goes to show that security is complicated.
Security is always based on some secret that the user need to understand it's vital to not reveal or share. So, if people using 2fa or password reset by sms do not understand that the secret sent by sms is not to be shared there is nothing that people who implement security can do.
On the other side from technology point of you phone number spoofing is more or less hard to achieve depending on the operator you subscribe with. Some have specific anti spoofing features in there sms platform other don't. Anti spoofing include verifying the source cell, IP (in case of sms over IP)...
A company which requires your phone number for 2FA can also use it for monetization, if it's in their T&C (that you read before accepting, of course). Like selling it to advertisers, using it for targeted promotions and whatnot. Another reason to ditch this transport system.
2FA is about combining a thing you know (password) with a thing you have (physical device like a card reader for banks, but usually phone because easier to access). But you can also use something you are (fingerprint/face recognition), although that comes with another entire set of issues (like sending your biometrics to a server).
Well, that's a cheap shot. It's a very sophisticated attack and assumes the user is dumb enough to click a dialog allowing direct access to their USB device. Many users are indeed that dumb.
So my second come back is to say that the Chrome team is working on a fix for this and that only certain U2F keys are vulnerable.
I would agree that SMS 2-factor isn't as secure as we would like, but the OTP and app-based alternatives have their own problems. They're much harder to remotely exploit, but the procedure for how to recover your account in case of sudden loss of your phone is a big hole. It's too common for phones to be stolen, lost, damaged, or corrupted with no warning, and then you need a recovery procedure that isn't just as vulnerable to malicious exploitation as any of the others.
I was the victim of a relatively sophisticated attack that took advantage of the weakness of SMS-based 2FA.
The attacker cracked the relatively weak password on my Verizon web login and enabled a "feature" that synced all my SMS to desktop, which they then used to break into a 2FA protected Yahoo email account. I saw the tokens come across and ultimately no financial damage was done, but suffice to say I moved as much of my 2FA over to authenticator apps as I could.
This is a really bad article. I agree SMS-based 2FA should go, but this article does next to nothing to explain the pros, cons, alternatives, and how reasonable each is.
Good feedback, will take that into consideration when writing the next article. I tried to keep it short and to the point, but likely there is some room for more detailed breakdowns.
No. No it's not.
If you're making software for the wider-public you can't demand people download a special app for it. Or even understand what a 2FA code is.
SMS is the only way, so far, to make 2fa adoption fast amongst everyone.
Not quite true - smartphone market penetration is quite large, so it is possible to reliably offer a universal app (see: MS Authenticator, Google Authenticator, Authy) for code auth. Now, sure, you can argue that SMS should be kept as an _option_ but it should never be the only one.
As a replacement you can send your users a One-time pad, like a scratching lottery ticket. Or a digital "dumb" device loaded with an encrypted private key. You can also use a browser client certificate.
The US is particularly bad but there is no nation in the world where the telecom system is entirely secure against all threats. SMS adds an unnecessary trusted third party to 2FA, something that really should be a two-party system.
It's time to ditch sms completely. If its important the network can use OTA to get emergency messages to you. But receiving anything with your number should be removed.
Why? That's dumb. SMS and MMS messages work perfectly fine and are a super easy option to communicate that works almost always, no matter where someone is located. My mum almost exclusively uses SMS to send me messages, because she can't figure out email on her phone(and I've tried to teach her for the last 10 years, with zero success). So I keep using SMS with my mum - and you'd want to remove it? Why?
That’s far removed from he real world - many many consumer facing companies are just now rolling out 2FA, and many of them are SMA based. Think banks, credit unions, utility billing, etc...
SMS 2FA is not perfect, but it's MUCH better than what it replaced (nothing). ANY system with a human component will be at risk to social engineering attacks; not just SMS-based methods.
And shifting the attack surface to depend on social engineering (SE) adds important rate limiting; it's difficult to automate SE attacks.
Friction is also a critical factor: a low-friction B+ security solution may be better than a high-friction A+ solution. Consider total risk, not just point risk.
SMS 2FA is like a CFL lightbulb. It's 10x better than what it replaced, it's what we have now, but we know it's not the endgame (LED lighting).