Live data from Hacker News

Tell HN: SMS-based two-factor authentication is not secure

news.ycombinator.com

171–180 of 291 posts

Re: Tell HN: SMS-based two-factor authentication is not secure

#171
post #93

Earlier quoted context omitted.

phishable how? "your account has been hacked, please provide us a TOTP code"?

1. Somebody loads fakebank.com. 2. It pops up a username/password screen. The user types in their credentials for realbank.com. 3a. The owners of fakebank.com use your creds to log in to realbank.com and are presented with a TOTP page. 3b. fakebank.com loads another page that asks the user for their TOTP. The user enters it, still thinking they are logging in to realbank.com 4. The owners of fakebank.com use the TOTP…

This is certainly a vulnerability, but it also depends on how you get your TOTP codes. I use Bitwarden's browser extension to get mine, and if the domain is incorrect, the extension won't present me with the code. I think this is a decent level of protection from phishing.

Re: Tell HN: SMS-based two-factor authentication is not secure

#172
post #116

What really grinds my gears is the seemingly unstoppable global transition towards SMS to a mobile phone number as means of identifying an individual, conflated with "security" through 2FA/account recovery, with this as the only option. This is especially popular within Fintech. Wise (formerly Transferwise) recently started requiring 2FA for signing in - SMS is the one and only option. Revolut requires it for acknowl…

Super annoying, especially when (prior to the pandemic) I traveled a lot and had a new SIM every month or two. Insanity.

Re: Tell HN: SMS-based two-factor authentication is not secure

#173

Part of the issue here that I don't see people addressing is that SMS as an only-factor recovery tool is often not optional. I hit a case like this just the other day: the service would not allow me to log in at all without adding an SMS number. This is becoming increasingly common. The irony is that my security is now worse. At least my password was randomly generated. I'm not sure what there is to do about this, ot…

I really hope that I am not the only one requesting businesses to not do this when I encounter it. It may be the only way to get it to stop.

Open a case with customer service and represent it for what it is; a security hole that prevents you from using the service.

Re: Tell HN: SMS-based two-factor authentication is not secure

#174

Earlier quoted context omitted.

> TOTP or hardware tokens don't generally suffer from the same problem. But how many hardware tokens or TOTP tokens are users willing to deal with? I currently have eight for various clients and systems at work. If each online account required a TOTP token or a custom hardware token it would be a confusing mess of tokens. I don't know if there's a safe and easy way of reusing the same token across sites. Until then S…

It is safe to use the same U2F token for many sites, that's not an issue. Having a backup token is very useful, but apart from that, a single hardware token (not custom - standards are good) can easily be used to secure all your accounts.

Assuming that the sites allow you to change the token manually?

Re: Tell HN: SMS-based two-factor authentication is not secure

#175

Earlier quoted context omitted.

> TOTP or hardware tokens don't generally suffer from the same problem. But how many hardware tokens or TOTP tokens are users willing to deal with? I currently have eight for various clients and systems at work. If each online account required a TOTP token or a custom hardware token it would be a confusing mess of tokens. I don't know if there's a safe and easy way of reusing the same token across sites. Until then S…

It is safe to use the same U2F token for many sites, that's not an issue. Having a backup token is very useful, but apart from that, a single hardware token (not custom - standards are good) can easily be used to secure all your accounts.

The only thing I wish is that more sites support multiple tokens, since tokens can get lost.

If you only support one token but have an easy recovery procedure, that opens up loopholes. If you support multiple tokens, allow the user to de-activate one token from another token, and make recovery difficult, that's much more secure.

Re: Tell HN: SMS-based two-factor authentication is not secure

#176
post #98
post #21

Earlier quoted context omitted.

I have not regained access to my bitcoin account, in part because I have not contacted customer support to do so. I’ve been too busy regaining access and continuing to support my client base. My account is locked, and I am pretty sure my funds are still there. It will be a significant loss, but not devastating as this was my non-primary investment account. I still don’t know the full extent of my losses. So far, my l…

> I now understand why banks do not use email addresses as the login id. The thief would not (easily) be able to align my email address with my bank login id. This is an important point and one I've been thinking about for years. There's so much discussion about using password managers and good password practices and 2fA but almost no discussion on how using a single identifier to log into all these various services…

Or get a domain with catch-all, and a different email for every service. Ideally not trivially guessable.

Re: Tell HN: SMS-based two-factor authentication is not secure

#177

Earlier quoted context omitted.

Couldn’t this entire scenario play out exactly the same with SMS codes?

Yes. The point is the TOTP is precisely as bad as SMS for the common case (phishing) and only safer in a rare case (SIM-swap). This comes with large downsides (losing access). TOTP is, at best, a very marginal improvement over SMS. This is what makes the online push to complain about services that use SMS 2FA and demand a switch to TOTP very strange.

TOTP is far, far better for travellers who need to swap their SIM cards frequently, or need to work out of places with internet access but no cell reception.

Re: Tell HN: SMS-based two-factor authentication is not secure

#178

Earlier quoted context omitted.

It can be costly. I moved from Ireland to the US and kept my Irish number active - the cost was a €5 topup every 6 months. Going in reverse is much harder - a lot of the budget phone providers in the US don't have any roaming offering. Best I can tell, you really need to have an account with a real provider, and that realistically looks like $20/mo (Google Fi), 20x more expensive than the reverse.

Then it sounds like changing bank is a better answer for many.

This oversimplifies the situation - if every US bank uses SMS and you want to retain a US bank, what do you do?

Re: Tell HN: SMS-based two-factor authentication is not secure

#179

Earlier quoted context omitted.

Then it sounds like changing bank is a better answer for many.

This oversimplifies the situation - if every US bank uses SMS and you want to retain a US bank, what do you do?

That's such a huge "if" that an alternative immediately came to mind:

TransferWise doesn't require a US phone number, but you can have a US account number with them.

Re: Tell HN: SMS-based two-factor authentication is not secure

#180
post #169

Earlier quoted context omitted.

> Compare that to a U2F token where you can very reasonably remove the password entirely and still be just as safe Yeah, and it requires me to use a U2F token, which I can loose, etc. You have to balance security and usability, and SMS as a second factor seems like a perfectly reasonable balance.

I really wish that web browsers had worked on the UI for generating certificate signing requests and importing certificates and that websites had 2FA via username/password along with client-side TLS certificate for authentication. This is more portable than U2F tokens since client-side certificates are part of the TLS standard and should be supported regardless of the application protocol used. Adding other devices c…

It had it! HTML 5 keygen tag https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke...

But Mozilla, and Google double teamed to sink it in W3C to push their own bicycle reinvention attempts, which after 10+ years, multiple incompatible versions, and errata ridden revisions are still not there.

https://lists.w3.org/Archives/Public/www-tag/2015Sep/0001.ht...

Google needs to be kicked out of W3C

Post reply on HN