Hacker News Reader

Comment by erpellan | Hacker News Reader

Dusting off my usual response: mutual TLS (aka client side certs) could practically eliminate phishing. It would be simply impossible to give your credentials to a phishing site as they never leave your device. There's 2 things missing that browser / device vendors need to do:

1. Improve the UI of client certs. 2. Figure out a way to manage credentials across multiple devices.

View on HN

In practice, FIDO U2F (Universal 2nd Factor) provides the same benefits and side-steps the major pains associated with mutually authenticated TLS (convoluted user experience, complex trust relationship management).

Google reportedly managed to all but eliminate phishing targeted at employees [1].

They also kind of solve your point 2: since the credentials live on the token, it's easy to move them from one device to the next. For devices with USB/NFC, that is.

[1] https://krebsonsecurity.com/2018/07/google-security-keys-neu...

Poor UI around client-side certs isn't a law of nature, it's not a priority for browser vendors. It should be super simple. Once you're signed up, the exact same tech that lets a browser show you the green padlock with the name of the site could seamlessly log you in with zero interaction needed, IF client side certs were easier to use (which is within the compass of the browser companies to improve).

Portability. You need to have access to your authentication mechanism from multiple devices, phones, laptops, desktops, even other people's computers. That's why the password still exists. I raised this issue with the WebAuthentication standard on their GitHub and the first reaction was to doesn't its importance. I log into services from a least the different devices every day.

So, the correct way to approach this in WebAuthn, which you'll see in popular implementations of its predecessor U2F and in for-real WebAuthn deployments is that users are allowed to have any plausible number of tokens, in GitHub this feels especially natural because it's managed the same way as your SSH keys, you can add or remove them, give them labels that help you remember what they are, and then you use any of them to prove your identity.

So I have a cheap FIDO token on my keychain that I take everywhere, and then I have one permanently plugged into the big desktop PC in my home and one in a desk drawer. You can buy ones that work nicely with a phone (unless you have an iPhone, can't help Apple) and Microsoft intends to effectively build one into Windows installs.

If you see a WebAuthn deployment that does 1:1 users to FIDO tokens, those people don't know what they're doing and need re-educating just like when people go "Oh, MD5(password) seems pretty secure".

2FA would also help, but people don't want to mandate it. And even if you require 2FA for your own employees, the third party "pay this invoice" request may not be gated on 2FA -- because that's up to the third party to enforce 2FA for (and they probably don't.)

Neither of these solutions helps with spear phishing emails, either. If you get an email that says "please wire money" from a sender you think you trust, the attacker's goal isn't credential harvesting, so protecting logins won't help.

Similarly we're seeing people fall for scams where a "trusted person" asks them to buy a bunch of iTunes gift cards and provide the codes on them in a reply email. Yes, people actually comply with this request when they think the requester is their CEO, etc.

2FA can be proxied through. The phishing site also asks you for 2FA, and passes through the code to the real site where the attacker logs in.

Does 2FA help? It might keep the account itself from being taken over entirely (assuming that another 2FA step also guards the ability to change the account's credentials), but a phishing site could transparently relay both factors to the real site to grant it access for a single session, which is enough time to do plenty of damage. And if the phishing email is of the form "you need to change your password now", the site could easily trick a user into handing over the additional second factor that guards the primary credentials.

Yes, you're absolutely right: 2FA makes things harder for the attacker but doesn't really solve the problem. But in practice, at least circa 2018, most phishing sites are very primitive. Attackers do OK victimizing people without 2FA, so they don't generally do what you describe ("transparently relay both factors").

Not 2FA alone, but something that authenticates the site as well, such as U2F

We don't do Client Certs because the problem is now you're asserting an identity. So what's the identity?

Maybe I'm happy for Hacker News and GitHub to know me as Nick Lamb, but I'd prefer that Grindr thinks of me as Steve Farmer, so that's now an additional certificate and then some sort of choice mechanic so I pick the right one. And if I screw up, or an advertising network is able to tie these identities together I can't undo that.

WebAuthn create a scenario where you can prove to a site that _you_ still have the same FIDO token as when _you_ signed up. But they don't get anything else, you have to mount an _active attack_ to even find out whether the token Alice shows you when she logs in is really the same token that Bob shows when he logs in, or to find out whether the credentials you've stolen from Facebook for alice@example.com are for the same token that Bob is using on GitHub. Passive attacks can't find any of that out, and remember each active attack attempt causes a physical human interaction, you can't just write a Javascript to try it a billion times until it succeeds.

Yes. Good point. Identity isn't ipso facto legit.

I've been working on PKAuth, which addresses this problem (not at the TLS level though). I wrote a short blog post [1] with a demo video about the underlying protocol. I'd appreciate any feedback!

[1] https://pkauth.com/blog/post/2018/08/27/announcing-pkap

Reply on news.ycombinator.com