The big weak point in the authors argument is credential stuffing. They argue fairly convincingly that 2FA is vulnerable to phishing, but concede it prevents credential stuffing. Then they try to argue that credential stuffing doesn’t matter because it can be prevented by using unique passwords, which is the one thing users have been shown to rarely do. 2FA stops credential stuffing cold, that’s important.
Also 2FA can stop phishing attacks cold as well, simply by using links instead of codes. So really the author should be using their time to advocate for that.
> When a service enables SMS-2FA, an attacker can simply move to a different service. This means that a new attack isn’t necessary, just a new service.
If you implement 2FA you do it to protect the user account on your service, not all services.
Yes, that was a weak argument. How is that not analogous to:
"Password hashing and salting is useless. When a service enables password hashing and salting, an attacker can simply move to a different service that stores passwords in plain text. This means that a new attack isn’t necessary, just a new service."
The largest benefit of 2FA is that if your computer gets compromised it does not automatically to lead comprising of the online bank accounts and such. There still needs to be user interaction and a bot cannot read SMSes itself. Often this time window before a user is fooled is enough to neutralise the attack. It prevents massive user account compromise in scale.
That's not true for SMS-2FA, since text messages are often delivered to the device with the browser. Safari on both macOS and iOS will offer to automatically fill in the code received from SMS.
I am curious as to how Safari connects the 2FA code to the web page. It would seem whatever they are doing could easily implement a database that maps 2FA SMS messages to domains, not only refusing to auto enter them on phishing sites; but warning the user they may be on one.
It doesn't; it offers to autofill a received code into a field on the page for a short time, but only actually fills it upon user interaction (so the page can't be sniffing for it via JS the moment it arrives).
If attacking my X account requires also attacking my SMS provider account, it doesn't make it impossible to attack my account.
However, telecom hacks are often more involved, and take more effort to pull off. If I'm a high value target, it's not a big hurdle. If I'm a low value target, I might not be worth it.
While telcos may eventually fix the broken protocols, it's likely to be decades before that has rolled out widely.
In the meantime attackers are going to automate telecom hacks.. why not?
That said, for simple services sending a single use password by email or SMS is quite easy :)
My hairdresser does so for reservations, and it's working out fine.. Nobody cares of that account is hacked anyways.
> In the meantime attackers are going to automate telecom hacks.. why not?
A lot of telecom hacks are social engineering, which often leaves an audit trail, and is hard to automate (if they're using the same text to speech engine that makes spam calls, good luck!)
Stealing SMS messages, maybe less so.. but from what I hear the protocol is largely trust based, so it's unclear that it couldn't be.
That said, eventually telcoms will be forced to fix this. I'm just guessing it'll take another decade or two.. it's not like robocalls were trivially fixed when they became annoying.
Two-factor authentication is the "Are you sure you want to X?" pattern applied to logins. While the world has been moving away from that interaction pattern elsewhere, it was simultaneously introducing it in a high-friction way somewhere new.
The takeaway from the attempts to eradicate "Are you sure[...]?" has been to just do the thing the user said to do, but make it easy to undo rather than double checking. It would be interesting to see how that philosophy could be applied as an alternative to 2FA.
EDIT: Boy, the replies that this comment spawned sure say something about HN. I count one (muxl's) that has any sense of self-awareness. Do you really believe that I don't understand the "purpose of 2FA"? Come on. Be more charitable.
2FA isn't double checking to make sure you meant to log in. It's verifying that you are the person logging in. Alert fatigue is a real issue as you point out and we need to make sure to not overwhelm users which is one major benefit of federated authentication.
The problem with taking an "undo" philosophy here is that it's very hard (impossible?) to undo the transfer of information which is what attackers are after in many breaches.
It's one thing if I accidentally delete a file without a warning, but can easily undo it.
But if someone logs in to access my files without authorisation... they've got them now. I can't click undo on them having read my private emails, or whatever the 2FA/other security was protecting.
Right, how does GP suggest we undo the act of giving out information? Deploy an ICBM to the geolocated IP that we just accidentally handed out private information to?
> Do you really believe that I don't understand the "purpose of 2FA"? Come on.
Yes. Nothing you wrote leads me to believe you do understand the purpose of 2fa. You can complain all you like, but to me, and apparently others, it seems that you don't from what you wrote. If what you write is misleading to so many people then perhaps rather than complaining about people mis-interpreting what you wrote you might re-visit the thing you wrote.
A: The colour black is white.
B: That's ridiculous.
A: I entirely understand the difference between the colour black and white, "Be more charitable".
Perhaps, but you're missing the entire purpose of 2FA: the "Are you sure you want to X?" is out of band by definition. The first factor is the things you know: username and password. The second factor is something you have.
If a specific 2FA implementation is not out-of-band, that would make it useless as a 2FA and it would be as you describe.
I can't think of a way to "undo" in this scenario without some settlement pattern. You can do whatever you want, but it doesn't "commit" until some settlement clears. In this case, still leading back to some kind of "Are you sure[...]" question, except to review in batch, like someone reviewing a bank statement.
Some people like reviewing in batch, some progressively, depending upon their individual perception of the cognitive load involved for them.
Tough to economically prevent spoofing though, when you start dropping aspects of authentication, integrity and non-repudiation. I suspect we can't substantially move that "Are you sure[...]" question's boundary until wearables become implants like a neural lace-grade implant.
(Congratulations on having been the only respondent here to actually have said anything worthwhile. Too late to be able to edit in another addendum to my comment, though.)
Wait, are you arguing that 2FA is a waste of time/not actually effective? What alternative do you propose then to provide additional security to accounts?
Or are you arguing purely in the sense of SMS and Email based 2FA?
^ Posted yesterday, with more comments. To sum it up:
"jasonpeacock 1 day ago [–]
He's arguing not just against SMS-2FA, but against 2FA itself, and his simple solution is to "just use a strong password".
The author completely misses the point about the value of 2FA itself. I agree SMS-2FA is not good, but that doesn't mean 2FA is worthless.
Yeah, "strong password" is necessary but not sufficient. The knowledge of your password can be leaked but your physical device can't.
There are legit arguments against SMS (the cell phone provider's customer support and the SS7 are weak points) and badly implemented 2FA, but 2FA definitely has security value add.
Not just a string password, but also a unique password.
I once ran IT for a small startup (As part of a large portfolio as Ops director), none of the employees put any thought into password security, or cared, no matter whether I set them up with 1password, gave them training sessions, etc.
I actually thought that SMS as 2nd factor for Banking is not allowed in EU anymore.
All the serious banks that I know of offer asynchronous password tokens (like Digipass), since not everyone trusts those mobile apps, or they simply don't own a smartphone. They don't advertise it too much, since it is easier for the bank to get everyone to use an app, but most of them offer it. If they don't, you should consider changing your bank.
"Instead, why not simply randomly generate a good password for them, and instruct them to write it down or save it in their web browser? If they lose it, they can use your existing password reset procedure."
Heh. You might as well drop the password and have a 'send the login link to my email" button then.
Why is saving the password in your web browser or any application on your machine - that can also be hacked - considered secure? You're just offering an attacker one single attack point that will yield all your passwords if compromised...
What about people using multiple machines? Should we sync our password store across all our devices, so there is just one server storing them that can be attacked?
And last question, for the SMS-2FA crowd: why would I want my login to depend on my phone number working?
> Why is saving the password in your web browser or any application on your machine - that can also be hacked - considered secure?
So you consider SSH (which normally relies on a private key stored locally) insecure?
(Sure, the SSH key can be further protected with a passphrase, but so can the browser database of passwords. On a modern Mac, it requires unlocking with touch ID.)
So we have complex secrets that you have to store digitally because you can't memorize. Where? In a secure store. That has access to it protected by a secret you have to store. Digitally because you can't memorize it. And the store where you store the secret for your secure store for your secrets...
A touch id protected secret store may be secure, and you lose access to your secrets if your laptop/phone gets stolen or breaks down? Or do you back it up to another store protected by different authentication that you have to store?
Looks like you cannot win to me.
The only advantage of generated complex passwords is that they'd be harder to brute force if the server has their password database stolen.
One point missed by the article is visibility: even with SMS-2FA, I at least know when my password is being used by someone else (modulo sim-based attacks). For example, if my password manager gets hacked, and a password leaks. I think the overall conclusion is still right: it's a rather minor concern and let's come up with a proper solution and not waste the developers' good will on this one.
This completely ignores the defence in depth principle. Yes it is good that users use strong, unique passwords, but we know the password store can get compromised. A second factor provides additional protection, but it is not foolproof. The network analogy of this post: why use a network firewall, we just need to keep our devices patched and up to date!!
>Yes it is good that users use strong, unique passwords, but we know the password store can get compromised.
The point of the article was that there is no downside if your password is unique. They will have your data on that particular site. The rest of the sites are just as secure as they were.
Organizations like to identify you by phone number, because it is the easiest way to prevent duplicate identities (Most users have one and only one number to receive SMS messages). Of course it also makes it easier to purchase and sell customer data.
For this reason I'd guess that many companies use SMS-2FA as an excuse to collect and confirm your mobile number.
One of the issues ignored here is the nature of cascading failures that happen during a breach due to password reuse. If a user is compromised through an active credential forwarding attack like the one described the user's account could be compromised on that service. Afterward, however, when the user's credentials are re-used by the attacker to access other accounts that attack is made significantly nosier and ineffective as the user would get an SMS for other services using 2FA.
TL;DR getting a text message every time someone logs in as you is going mean you're much more aware of what's happening with your accounts. Having that text message contain credentials means if it wasn't you logging in (and hence you weren't expecting an SMS) then the login fails.
EDIT: Password managers are great and I'm all for promoting them probably more than 2FA even. The difference between a password manager and 2FA is that a password manager does literally nothing given that your password is known. In that same situation 2FA still does do something and so this appears to be a false dichotomy.
Many valid points, but I would say 2fa does help if malware has your creds buy can't be leveraged by an attacker without also successfully phishing the victim with an identical site.
Also 2FA can stop phishing attacks cold as well, simply by using links instead of codes. So really the author should be using their time to advocate for that.