Comment by not_that_noob | Hacker News Reader

Comment by not_that_noob | Hacker News Reader

While I applaud the hard work the W3C group has put into this, and the excellent spec, I can't help but think that they are solving a problem that doesn't exist.

Attackers are much more likely to assume a user's identity and thus acquire the user's certificates for such a system. That's how most compromises today happen.

The central issue is verifying a claimed identity - not just at enrollment time but also on every use. The spec waves that off to 'Authenticators' (see below). But that's not a solution. If user authorization to certificates are based off passwords, for example, then what prevents an attacker from taking compromised data about me and using that to get access to passwords?

Don't get me wrong - this is good work. But I just think everyone seems to be focussing on the wrong end of the stick.

=======================

User Verification

The technical process by which an authenticator locally authorizes the invocation of the authenticatorMakeCredential and authenticatorGetAssertion operations. User verification MAY be instigated through various authorization gesture modalities; for example, through a touch plus pin code, password entry, or biometric recognition (e.g., presenting a fingerprint) [ISOBiometricVocabulary]. The intent is to be able to distinguish individual users. Note that invocation of the authenticatorMakeCredential and authenticatorGetAssertion operations implies use of key material managed by the authenticator. Note that for security, user verification and use of credential private keys must occur within a single logical security boundary defining the authenticator.

It _does_ solve a real problem. Several actually: password reuse, weak passwords, and phishing. If this catches on, it'll pretty much eliminate all leading causes of account compromise on the modern web. That's huge!

However, as you said, it seems like the other piece of the puzzle (the authenticators) isn't fully baked yet. U2F is one existing option, but that's not really suitable as a password replacement all on its own (it's just "what you have"). Hopefully Google, Mozilla, and Microsoft (all of whom contributed to development of this standard) have some ideas for standard cross-browser, cross-platform authenticators that provide the other authentication factors.

It doesn't actually. If the authenticator expects passwords, then this simply moves the problems you cite to another part of the system. These are the sources of compromises on the modern web. It's a neat system - but it doesn't solve the key issue.

Doesn't really matter if the authenticator expects a password, because that password _isn't_ what's used to authenticate to the site itself; it's always a public/private key pair.

If the user decides to use 12345 as his password for a Web Authentication authenticator that's obviously less than ideal, but still impossible to phish (the browser validates the domain the user is on), infeasible to brute force without access to the user's device (where the actual key pair is stored), and impossible to compromise in a data breach (the site only has a public key).

It's the weakness of single-sign on - if the authenticator is compromised, then the attacker now has the key that controls access to all the keys.

Sort of. Except the attacker has to compromise each user individually; there's no centralized server to target as is the case with existing single sign on services.

This already happens - it's called spear phishing. Instead of wasting time with multiple users, the attacker picks a high-value target. For example, if you can get one admin, it's game over.

True. But spear phishing is also harder with this standard, since you can't just phish credentials; you need to actually compromise the user's authentication device. (Get root on the user's phone, physically steal their authentication token, etc.)

In this thread, you keep moving the problem statement to cover a smaller and smaller subset of the general problem of account compromise. This is exactly what the attackers you're describing will do.

That's the point of this solution. If we can remove the vast majority of account-compromise tactics and force attackers to achieve success only if they "get one admin," then that's an incredible victory -- especially for the large number of ordinary people who are not admins.

It's true that U2F/WebAuth doesn't fix e.g. a CSRF vuln or an XSS vuln where someone abuses legitimate credentials like a session cookie, but this does effectively beat phishing, and that's no small feat.

That's a misconception - I don't see where this helps with phishing.

webauthn helps with phishing in the same way that U2F does: by binding the keys to specific domains/origins. A phishing site hosted at gmailsecurelogin.com can still steal your password, but the security key is not going to produce anything that's usable on mail.google.com as a second factor.

Not disagreeing. Note however that I'm talking about the authenticator. If that is compromised, then the attacker now has access to all keys.

All keys, for one person

That is not great, but it's much much better than the 500 million people in the Have I Been Pwned database.

I'm not exactly sure what your threat model is, then. The typical way this gets deployed is with U2F USB devices with non-extractable keys. "Access to all keys" is not exactly technically feasible.

If your concern is "well, there's always the admin/support backdoor", i.e. a compromised admin account or a social engineering attack on support personell could lead to attacker-controlled keys being enrolled, I'm afraid that's not really something you can solve by just throwing new technology at the problem. However, you'll definitely make it harder to even get to the point where admin accounts are compromised by rolling out U2F or webauthn.

Personally, I'm perfectly fine with a technical solution that solves phishing for everything but the most advanced social engineering campaigns.

If an attacker compromises the credential, the credential is useless, yes? The credential is still customized _per origin_, so you'd have to decap the U2F key to extract the secret. This hardware is specifically designed to make that hard to do.

Because the Web Authentication API is built in to the web browser and uses unique credentials for each origin, it's not possible for a user to authorize a login session for a domain that's different from the one they're _actually_ browsing at the time.

If I visit g00gle.com and sign-in using the Web Authentication API, my browser is going to use my credentials for g00gle.com, not for google.com; unlike me, it _can't_ be fooled by similar-looking characters.

> If I visit g00gle.com and sign-in using the Web Authentication API, my browser is going to use my credentials for g00gle.com, not for google.com; unlike me, it _can't_ be fooled by similar-looking characters.

In the age of punycodes this has become particularly important because the human eye cannot visually distinguish between ASCII and punycode lookalikes - many are visually indistinguishable in many fonts.

I'll add in to what has already been said by the fact that this should eliminate relay attacks completely as well assuming you have already visited the site before. The site presumably has a copy of your public key so they can send you messages you can only read with your private key and since you have their public key as well, no MITM is possible.

This attitude slows down progress. Perfect is the enemy of good enough.

Instead of telling how this solution is not perfect (no solution is perfect) tell us how this solution is worse than our current situation. The fact is, it's not. It's actually better in a number of ways as other comments have pointed out.

> But that's not a solution. If user authorization to certificates are based off passwords, for example, then what prevents an attacker from taking compromised data about me and using that to get access to passwords?

Maybe I'm misunderstanding your point, but an attacker will also need physical access to your authenticator. That's a much less scalable attack vector.

As for a real problem, others pointed out phishing already. U2F and Webauthn aren't just a certificate management solution, but a protocol for the user agent to make trusted statements to the server.

Attackers don't bother stealing physical tokens - way too hard. It's much easier to ask for token re-issue using compromised info. See for example https://www.techlicious.com/blog/phone-porting-scam-can-empt...

Right, if a service provider is willing to register new public keys/certs (or any kind of credential) on your account as a result of identity fraud, that is indeed a different problem. But not nearly as big as phishing and password reuse.

So, I don't see how the presence of that problem suggests it's not worthwhile to work on better types of credentials.

If one link of the chain is broken, it's game over. While this is a good effort, my point is that not considering the entire system as a whole simply transfers problems from one part of the domain to another.

You are right in a sense. Right now the problem is up to individuals to create secure passwords for each and every website they interact with. People that have no idea how computer security works. The problem now is also on individual website developers to be trusted with those passwords and keep them secure.

This transfers the problem away from both of those groups. Individual no longer have to create multiple secure passwords and website developers no longer have to store those precious secrets. This is a huge improvement. You are correct that it's not perfect, but instead of security pros spending all their energy teaching people how to manage passwords, they can focus on the remaining problems that you point out.

> simply transfers problems from one part of the domain to another.

No, it completely eliminates several huge vulnerability domains. Just because it doesn't solve a different one doesn't make it bad.

Reply on news.ycombinator.com