Hacker News Reader

Comment by timcosta | Hacker News Reader

SMS is not reliable for 2FA, it's trivial for a determined party to sniff SMS messages. TOTP is the best way for typical users to do 2FA, as most people wont have a Yubikey or anything like that. Google Prompt is the equivalent of iCloud's cross-device prompt where you must allow the action from another device that's already logged in to the account.

The Google Authenticator app isn't the only app that can be used to generate TOTP tokens, even though many sites directly refer to it. Anywhere that you are given a QR code to scan you can use any TOTP app you'd like. I use Authy personally because it allows me to back up my TOTP tokens behind a master password and access to my phone number, so in the event my phone is lost or replaced I'm able to restore 2FA access by going through the process to configure Authy again and re-enter my master password from another password manager.

View on HN

As it becomes easier to emulate hardware tokens[1], Google may start limiting which ones it accepts. I believe they can use attestation keys to do that.

This is just a softer layer of security to slow down less sophisticated mass signup attempts.

Google may very well eventually phase out TOTP, under the justification that it is not as secure, but I would be shocked if they ever retire the highly insecure SMS verification.

> As it becomes easier to emulate hardware tokens[1], Google may start limiting which ones it accepts.

Why? I hope they don't, as I'm relying on my password manager to emulate a hardware token so I can finally log in to websites without needing a username/password.

At its core, FIDO2 is an authentication API, so the site can ask your browser to authenticate you (in whatever way the browser wants). If that's "talk to the password manager to authenticate the user using some fancy cryptography", why does the authenticating site care?

I'm looking forward to the day when my password manager only has one credential in it, my soft-FIDO2 private key.

> > As it becomes easier to emulate hardware tokens[1], Google may start limiting which ones it accepts.

> Why?

Likely not in the same of security, but as an extra speed bump for automated account creations.

The easier it is to create accounts in automated ways en masse, the more likely that system can be abused.

If you require SMS authentication, you can use that telephone number as a means to limit accounts being generated.

If you can restrict software emulating hardware, you're similarly increasing the barrier to entry to require hardware tokens too, increasing the cost of creating accounts used for fraudulent activity, and reducing the lower hanging fruit (e.g. spam) from being as profitable.

If you require SMS authentication, you can use that telephone number as a means to limit accounts being generated.

If you require SMS authentication, you can use that telephone number to personally identify the individual. Privacy invasion justified in the name of security.

Why is it that Google and the tech giants would rather that you use highly insecure HTTP than a possibly insecure self signed certificate?

You use self signed certificates all the time with SSH. If you haven't seen an SSH key before, you don't fall back to telnet.

If you stop to think about it, is incredible how much effort they put into forcing you to use the latest browser, and not trust self signed certificates. It is far easier to root your device and patch your kernel than it is to use an older browser.

Yes, it is a highly effective but clumsy heuristic to detect abuse. But I am convinced that they may have other incentives as well.

It's been a while since I used self-signed certificates, but experience used to be just about right. You hit the page and browsers throw a big fat warning. You add an exception, basically acknowledging that this is a certificate you trust (exception is for the cert, not any cert on this domain ever), and as long as the certificate doesn't change, your trust is at the same level it was on the initial load of the page.

The UX problem with self-signed certs is that you start expecting to accept them, so when that site asks you again to accept it while you are browsing in a cafe on a public WiFi, your browser would need to know that now you are on untrusted network and that you should better watch out.

Which is why LetsEncrypt came to be: it provides at least some chain of trust without any extended validation, which is a bit extra on top of self-signed certs.

> The UX problem with self-signed certs is that you start expecting to accept them, so when that site asks you again to accept it while you are browsing in a cafe on a public WiFi, your browser would need to know that now you are on untrusted network and that you should better watch out.

But again, should you watch out more than if you were using HTTP? Does your browser make you opt in to connecting to every HTTP site on an open wifi network? What about an HTTP captive portal on an open network?

I have not heard a good argument for the current behavior with self signed certificates that justifies the behavior of completely unencrypted connections.

The ideal behavior would be for your browser to make it clear that the connection safe from third party attacks, but that it can't verify the website. Perhaps leave the scary warnings for submitting something over an self signed or unencrypted connection.

It's again a user expectation problem. What if you connect to a web site for the first time while on a rogue public network?

If users expect to be "safe" when on a secure site, without them understanding intricacies of certificates, self-signed is counter productive.

There are certainly improvements to be made to the experience, but none of that can explain all these nuances in a way a temporary visitor will read and grasp.

OTOH, it's easier to teach them "HTTP unsafe, don't type anything private".

> The ideal behavior would be for your browser to make it clear that the connection safe from third party attacks, but that it can't verify the website.

If it can't verify the website, the connection is not "safe from third party attacks".

> Why is it that Google and the tech giants would rather that you use highly insecure HTTP than a possibly insecure self signed certificate?

There are legacy concerns that factor in here, where HTTP was the default, and HTTPS was a costly alternative.

Changing defaults can be expensive.

Chrome has been marking HTTP URLs as "not secure" in the URL bar for like three years.

The current implementation is idiosyncratic.

Out of the box, you will get a lot more resistance for using a self signed certificate than bare HTTP. At the very least, self signed certificates should be in the same security context as HTTP.

Our devices should opportunistically use encryption, even if validation is not available.

I had a client that wanted to use an Android tablet to monitor IP cameras on his local network, and it was virtually impossible to use the TLS on zeroconf .local domains.

The official solution is to rely on the underlying network for security. Even though the webservers on devices and our browsers have TLS support.

If your password manager has control of both your password and your "2nd" factor auth, it defeats the purpose of it being a 2nd factor.

You are still protected from your password hash being stolen from the target website, decrypted and then used for log-in, but if password hashes were accessed, potentially a bunch of other stuff that you'd care about is too, so that's a somewhat moot point.

But someone stealing your laptop and getting access to your password manager gets access to your 2FA too. Making it not a "second" anything: it's akin to using two passwords for log in to a single site and keeping them in the same place. Physical separation of the two authentication factors, thus, matters.

That also means that you should not have your password manager on the phone, or at least only have a separate one: ideally, password managers would integrate between desktops and mobile devices to pass short-lived access to passwords for Oauth/OpenID Connect auth instead.

Yeah, bridging convenience and security is a long standing nightmare of a problem to solve. :)

Yes, I know all that, and that's fine. I'm not looking to solve the problem of authenticating so I can launch nukes, I just want people to not steal my Twitter account.

A random thief stealing my laptop would have to:

1) Bother

2) Break my hard disk encryption/know the password

3) Break my password manager encryption/know the password

I think that's hard enough for someone wanting to get into my email. I use a separate hardware key to secure my domains, and that's about it.

That's fine, the only question is why use 2FA at all?

What's the attack vector you are protecting against that a good, non-reused password is not covering?

Keyloggers, stolen password databases, MITM, shoulder surfers, interception.

Yeah, that makes sense: I brought up stolen password hashes, but I generally disregard keyloggers/MITM/interception because I usually use trusted devices and network encryption (HTTPS), but not all sites do, and I can see how people might be forced to use untrusted devices.

Still, when you've got access to your password manager (to get your password and TOTP token too), you've got access to a trusted device too.

And there is still an option for anyone (including shoulder surfers) to type in your password+token a bit faster than you so they get in: nobody bats an eyelid for getting reprompted for another TOTP token.

You are also vulnerable to someone stealing your password manager password in this manner, especially with a cloud one (which is what most businesses require).

As a conclusion, it does grant you some extra protection against using password only, but when on a separate device, it's really another dimension.

I'd be interested to know more about how you use your password manager to emulate hardware tokens

I don't currently, I meant more in a "I'm hoping they will implement this".

Ahhh. I wonder if this is something I could cobble together with a few open source components.

I now have a weekend project....

It has always, from the very beginning, been possible to emulate hardware tokens.

I use 1Password for Google and it works fine. Follow the 'Google Authenticator' setup and don't believe the wizard -- it's not exlusive to Google Authenticator.

Check again—that option isn’t there these days

It was there last time I checked a few weeks ago. How else are you meant to set up an OTP with a Google account?

KeepassXC has pretty good support for 2FA. I use it for all my TOTP needs. On mobile, I also use Aegis, which is free open source and can backup your TOTPs.

The developers don't recommend storing your TOTP secrets in the same database as your passwords [1]. I used to do this, but now I'm using andOTP [2].

[1]: https://keepassxc.org/docs/#faq-security-totp

[2]: https://f-droid.org/en/packages/org.shadowice.flocke.andotp/

Bitwarden does TOTP as well if you give them $10/yr. It's handy as with most logins it will auto-fill UN and PW then put the code in your clipboard for you to just paste and hit enter.

Coinbase refuses to work with Authy.

I first heard about Authy when it was recommended to me by coinbase but sometime last year coinbase forced me to change to Google authenticator.

Smartphone secure enclave U2F is the best for users. TOTP is still easily phished.

I think phishing is an entirely different matter.

Any access is easily "phished" with pliable people (which is not necessarily a set of people, but also a question of timing and circumstances: everyone is sometimes more or less pliable): "please log in with your U2F device, download that document and upload it to this URL https://your-company-confidential.s3.amazonaws.myurl.com/, before we can reinstate your access to company systems".

It isn’t a different matter. It is the core matter. Phishing and stuffing completely dominate the actual attack space. SIM swapping and other theft of SMS messages is tiny in comparison.

The advantage of U2F is that it isn’t phishable. You can only sign the message for the pre enrolled URL.

Yes, you can still fall for more elaborate instructions but you cannot simply give the attacker your credentials through a normal looking flow.

Not sure what's "normal looking" in the flow where you are supposed to dictate/type-out a TOTP code to someone while not being allowed to use it to attempt a log in (and that they have <60s to make use of). "Be quick and type me out your TOTP code from your phone before it changes, darn, that one didn't work, let's try again".

I also disagree it's that far fetched to get people who'd do that to also do whatever else you want them to.

And while SMS swapping is miniscule in comparison, the big difference there is that there is no signal at all that you are under attack. With phishing, there is no way you are not feeling something is at least a bit off, so you know to check soon after, even if you've been compromised.

The phishing flow is precisely the same as the normal auth. You click a link. It takes you to evil.com that looks like your bank page. You type in your password. The system takes your password and starts an auth flow with the actual bank. You are shown a TOTP page. You type in your code. The system takes your code and completes the auth with your bank. This is 100% automated and the only observable different is the URL.

After this happens it takes you to a “something went wrong” page and has a link back to your real bank website.

With U2F this impossible because you cannot sign a message for bank.com when visiting evil.com.

Reply on news.ycombinator.com