It’s time to ditch SMS-based 2 Factor Auth
dennisdel.com
dennisdel.com
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).
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.
[1] https://en.wikipedia.org/wiki/Risk_compensation
[2] I propose that SMS-based password reset be called “Half-Factor Auth” (HFA or ½FA), to distinguish it from 2FA.
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
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.
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.
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.
Other than social engineering, there's also SS7 abuse:
https://arstechnica.com/information-technology/2017/05/thiev...
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.
The problem is 2FA is used to protect my email!
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.
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.
"The Time-based One-Time Password algorithm (TOTP) is an algorithm that computes a one-time password from a shared secret key and the current time."
https://en.wikipedia.org/wiki/Time-based_One-time_Password_A...
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?
Ideally I'd love to have a hardware token that I can use for TOTP authentication regardless of the computer I'm working 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.
http://about.att.com/story/att_sprint_tmobile_and_verizon_un...
So if that's more your cup of tea for security, then you'll be well covered.
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.
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.
Though I've recently switched over to simply putting all the 2FA secrets in my keepass database, that's good enough for me in terms of security.
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 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.
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?
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.
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.
These are things that have actually happened.
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.
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.
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.
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.
Alternatively there are a number of desktop based 2FA clients:
- Authy - GAuth - JAuth - WinAuth
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.
It's not a free lunch.
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.
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.
> store them in a password manager
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.
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.
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.
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.
I think the problem with SS7 is that there's no authentication between providers. At least as far as I know.
[1] https://en.wikipedia.org/wiki/Local_number_portability#Porta...
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.
I wonder what they would do about it.
Apple please listen.
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.
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.
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.
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).
This means it’s impossible for an imposter web site to man in the middle the U2F token.
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.
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.
SMS is the only way, so far, to make 2fa adoption fast amongst everyone.
For places where your SMS is relatively safe, SMS 2FA is the current best for average home user.
Email and SMS based 2FA shouldn't be the only choices.
Until my phone gets stolen :(