7 ms·
I believe the arguments that SMS-2FA is not effective against phishing. (Or, at the least, I can't provide a compelling counter-argument.) But I had always thou
by scott_s 6y ago
I believe the arguments that SMS-2FA is not effective against phishing. (Or, at the least, I can't provide a compelling counter-argument.) But I had always thought of SMS-2FA against a more banal problem:
1. You have a unique, long password with Foo.
2. Oh no! They store your password in plaintext, and their security is terrible, so your username and password are part of a giant data breach from Foo.
3. Before you know about it and can change your password, someone that is not you, who does not have access to your phone, tries to log into the account.
4. While out living your life (or in, these days), you receive an SMS from Foo, and then ignore it.
5. There is no step 5, as no one else is getting in.
6. Okay, fine, you caught on, and now you log in and change your password with Foo, or maybe just drop the account, because really.
It seems to me that SMS-2FA helps in this scenario. Am I missing something obvious?
- UncleMeat 6y agoTavis discusses this explicitly in the article. His claim is that there will be some other service that doesn’t do this so the user is still vulnerable to credential stuffing - just not on your service. I don’t fully buy the argument, but he didn’t just ignore this. More valuable, I think, is the claim that we only get so much bandwidth to educate users and that spending time educating people on unique passwords is more effective than working on sms 2fa.
- toomuchtodo 6y agoUsers are lazy. You can educate all you want, they will still use the same passwords everywhere, or weak passwords. You have to bake the security into your workflows, processes, and code if you want it to matter. This is from infosec/opsec awareness training experience I get paid to provide. Not all users are lazy, mind you, but enough to be emotionally depleting. Incentives matter.
- UncleMeat 6y ago> You have to bake the security into your workflows, processes, and code if you want it to matter. There's a suggestion here in the article: don't let users pick their passwords. Just generate one for them and say "use your browser's password manager or write it down".
- wolco 6y agoAll that does is increase the locked account support tickets and drive people away. A sticky note password attached to the screen creates another password sharing problem. The last company I trust with my secret password is my browser. One hack away from exposing everything. That's like bring all of your important documentation with you wherever you go. If you are robbed it is better you don't have your bank code attached to the card.
- deleted 6y ago[deleted]
- tialaramex 6y agoThis is my biggest reason for optimism about WebAuthn. Using cheap FIDO USB dongles is "I forgot it was there" easy, you have to tap the button or touch the metal contact surface or whatever on your dongle when you sign in, it becomes a reflex, you stop thinking about it yet now you're authenticated and bad guys aren't. The touch ID style behaviour in a newer Pixel or iPhone likewise, that's probably already how you unlock your phone without really thinking about it, and now it can unlock a web site. Even the OpenSSH FIDO integration feels lazier, yet more secure than having to use a local password for your keys. Some non-trivial number of people have no password or set it to something easy because it was annoying, the resulting risk (malware exfiltrates their unsecured private key) vanishes instantly if you give them all FIDO dongles and require that login method.
- 33Backpack33 6y agoNothing more lazy than doing something like generate a password for the user. The way most browsers work you have to go out of your way to not let it save and fill passwords. If you create the password for the user they can't reuse it and thus no credential stuffing problems.
- scott_s 6y agoBut I'm already immune to credential stuffing because I have long, unique passwords, no? And credential stuffing would be taking my username and password from Foo and using it with Bar, right? But I'm talking about the username and password from Foo being used with Foo.
- UncleMeat 6y ago> But I'm already immune to credential stuffing because I have long, unique passwords, no? You are. Tavis discusses this clearly and offers two suggestions for making this more common (educating people about password managers or having services generate all passwords for their users rather than letting users pick them). If you believe that "everybody uses unique passwords" is achievable then Tavis is 100% correct and SMS-2FA achieves nothing.
- scott_s 6y agoI proposed a scenario where it seems to me that SMS-2FA does achieve something. What is wrong with my understanding with how it helps with that scenario? To be clear, I'm not talking about credential stuffing. I'm talking about my credentials from Foo being used with Foo.
- UncleMeat 6y agoI think this is a somewhat questionable threat model. Some people would say it is reasonable. Other people would say that the service has already been pwned so relying on that breach being exclusively contained to the password database and nothing else, requiring the hackers to actually use the ordinary authentication flow to do anything bad, is a fairy tale. I personally don't feel like I have enough information to decide whether this is a reasonable threat model or not.
- quinndiggity 6y agoDefence in depth - too often I hear "whelp, we had a tiny crack in one of our measures, so it's game over, why even try?". Imagine the scenario where service A has read-only access to the authentication db/table, whereas service B (which could be maintained/operated by an entirely different person/team that leverages a more stringent code review process, or simply one performed by better eyes) has write access to that same db/table - the credential database could be leaked but due to a variety of measures in place further compromise through that specific avenue is mitigated. One of the primary goals of "security" is to stop an attacker from accessing things or being able to perform actions that they "shouldn't" be able to access/perform. When dealing with humans it is incredibly difficult to decisively achieve that goal. It could be a zero day, a vulnerability in a code dependency, or otherwise some service dependency or other such software (say an internal analytics system with its own entirely separate models and storage of data) that leads to a breach - the bigger the team/company, the more people involved, the higher the chances that someone makes an inadvertent (or intentional) mistake somewhere. I do not agree that a compromise of any form should be considered a reason to not attempt to build a secure system resilient to layers and layers of human failure.
- OrderlyTiamat 6y ago> there will be some other service that doesn’t do this so the user is still vulnerable to credential stuffing - just not on your service. "If they don't practice good security, why should we?" The other points would have been stronger if he'd just admit that there is this small advantage to sms2fa. As is, he's making a ridiculous argument in an attempt to make the issue wholly black and white.
- jedimastert 6y ago> It seems to me that SMS-2FA helps in this scenario. Am I missing something obvious? It's not necessarily scalable, but sim-swapping[0] is still an unfortunately serious issue. Phone numbers are not proof of identity [0]: https://en.wikipedia.org/wiki/SIM_swap_scam https://en.wikipedia.org/wiki/SIM_swap_scam
- RcouF1uZ4gsC 6y agoBut sim swapping is more a targeted attack. There are probably several orders of magnitude more opportunistic attacks than targeted attacks. If you can make opportunistic attacks fail and require targeted attacks, you still have a big advantage.
- ldiracdelta 6y agoSecurity is an economic effort. They have to have two things now, which at least doubles the difficulty if not even more. We dont drive tanks and wear helmets and use a 5-point harness while driving at 15 mph to get around, because we have to actually get things done with our tools and systems without going bankrupt or starving to death.
- wolco 6y agoWhat I see happening in real life is.. Hacker has access to Foo that's how they got your creds. If they want more access they will use the admin account to gather all info Foo knows. Hacker picks a global service. Paypal, gmail, appleid, godaddy and tries all usernames/passwords. When they hit 2fa they attempt a code. 99% of times it fails. You get a warning/change the password and get scared. User receives an email saying that you have beenhacked. They have proof you did something illegal or something illegal has been planted. Send bitcoin here or this video will be sent to all of your friends/work/family. ---- 2fa usually locks you when you need it the most (no battery/texts not going through/paid bill latertexting is turned off can cause this)
- basch 6y agoMy problem with SMS-2FA is when it becomes a single factor back into the account. It should never be the only factor required to reset a password. It should always be an option to disable. (Smaller financial institutions seem particularly to fall into this one, "its for your security.") It should be granular enough to give the customer control of what it can and cannot be used for. The big thing being missed here is that all organizations should be expected to block any leaked password in the wild from being used. Banlists are rarely used by any entity except the largest. SMS-2FA is a step in continuous improvement, not a destination. It is also being used to either check compliance boxes or as a part of security theater. The hoopla, range, and witch hunt energy should be repurposed to get everybody using password banlists.
- 33Backpack33 6y agoIf they made it that far to get your password why do they need to log into your account? Having multiple locks on your door don't matter if they got in through a window.