6 ms·

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

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.

lvh 9y ago
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.
- not_that_noob 9y ago
  That's a misconception - I don't see where this helps with phishing.
  - pfg 9y ago
    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_that_noob 9y ago
      Not disagreeing. Note however that I'm talking about the authenticator. If that is compromised, then the attacker now has access to all keys.
      - krupan 9y ago
        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.
      - pfg 9y ago
        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.
      - lvh 9y ago
        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.
  - 9y ago
Ajedi32 9y ago
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.
- not_that_noob 9y ago
  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.
  - Ajedi32 9y ago
    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).
    - not_that_noob 9y ago
      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.
      - Ajedi32 9y ago
arnarbi 9y ago
> 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.
- not_that_noob 9y ago
  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-empty-bank-account/ https://www.techlicious.com/blog/phone-porting-scam-can-empt...
  - arnarbi 9y ago
    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.
    - not_that_noob 9y ago
      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.
      - krupan 9y ago
        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.
krupan 9y ago
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.

lvh 9y ago

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.

not_that_noob 9y ago
That's a misconception - I don't see where this helps with phishing.
- pfg 9y ago
  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_that_noob 9y ago
    Not disagreeing. Note however that I'm talking about the authenticator. If that is compromised, then the attacker now has access to all keys.
    - krupan 9y ago
      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.
    - pfg 9y ago
      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.
    - lvh 9y ago
      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.
- 9y ago

Ajedi32 9y ago

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.

not_that_noob 9y ago
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.
- Ajedi32 9y ago
  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).
  - not_that_noob 9y ago
    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.
    - Ajedi32 9y ago

arnarbi 9y ago

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

not_that_noob 9y ago
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-empty-bank-account/ https://www.techlicious.com/blog/phone-porting-scam-can-empt...
- arnarbi 9y ago
  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.
  - not_that_noob 9y ago
    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.
    - krupan 9y ago
      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.

krupan 9y ago

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.