Hacker News Reader

Comment by scott_s | Hacker News Reader

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?

View on HN

Tavis 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.

Users 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.

> 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".

All 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.

You are typing your password into your browser. You must trust them with your password.

I don't trust them to store and safe guard the password.

So you're not using a password manager either?

This 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.

Nothing 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.

But 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.

> 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.

I 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.

I 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.

Defence 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.

Scenarios where someone might have my password but not my SMS: keyloggers, password written down at my desk, video surveillance or shoulder-surfing, audio analysis of keyboard and/or CPU tones[0].

The stronger or less guessable a password is, the more likely it is to be written down or recorded somewhere where it could be compromised.

[0]https://en.wikipedia.org/wiki/Acoustic_cryptanalysis

>If you believe that "everybody uses unique passwords" is achievable then Tavis is 100% correct and SMS-2FA achieves nothing.

This doesn't seem to follow. As the previous poster called out, if I have unique passwords, SMS-2FA makes me safer than not having it. If someone (let's say Bank of America) has their password database leaked, then an attacked can immediately log in to my account with a unique password.

If I have a unique password + SMS 2FA, the attacker has to compromise SMS to log into my account - a slower process that gives me more time to be informed of the leak and change my password.

But is that true? The hacker got the pw database somehow. So it isn’t a given that they need your sms to impersonate you, since they clearly have breached the system already.

> So it isn’t a given that they need your sms to impersonate you,

Correct. It's possible the entire system is compromised. It's also possible the entire system is not compromised, and the data breach happened without the target institution losing control of their systems.

> since they clearly have breached the system already.

No, not necessarily. Someone could, say, export the contents of a database and put it somewhere public. A data breach is not necessarily the result of hackers getting total control of the target.

Tavis has never attempted to educate an entire company about password security.

No one cares about it, most are people who will never be reading hackernews, who barely know how their computer works, and write down one password on a stickies A taped to their monitor and reuse it everywhere because they are in a hurry to do their actual job.

> 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.

> 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

But 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.

Security 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.

My 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.

What 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)

If 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.

Reply on news.ycombinator.com