3 ms·

Why in the world is this API so complex? Devs will continue to implement password authentication even when there's general browser support until either there's

by lxe 4y ago

Why in the world is this API so complex? Devs will continue to implement password authentication even when there's general browser support until either there's a simpler way to register and sign in users.

tptacek 4y ago
How could it be simpler? You ask the browser for a credential associated with an opaque ID, and get back a public key with its own ID. To use the credential, you ask the browser to sign a challenge (another opaque ID), and the browser gives you back a signature, which you check against the key. It's almost the simplest thing that could possibly work; it's much, much simpler than OAuth2. This page is an excellent summary introduction to WebAuthn, but it makes the API look more complicated than it is, because it surfaces a lot of options you probably won't care about.
- tedunangst 4y ago
  An API (or guide thereto) that surfaces fewer options seems like the obvious way it could be simpler. Is attestation optional or required? Is there a default? Can I not care? What do I read to not care?
  - dyml 4y ago
    It’s available at https://Passwordless.dev https://Passwordless.dev. I’ve worked on a open source library for fido2 for about 4 years and we created an API that makes it A LOT simpler to get started. And when ever you want to leave the API/Service you can just migrate to whatever self hosted webauthn service you’ve setup. Happy to answer any questions.
  - tialaramex 4y ago
    > Is attestation optional or required? Is there a default? Can I not care? What do I read to not care? Attestation is optional, the default is not to have it, and you should not use it. It's something some people insisted they needed, and eventually it's easier to let them have the feature than keep explaining why it's a bad idea. So, you can elide that element of the structure, or, write "none" instead of "direct" here to say you don't want attestation.
    - CSSer 4y ago
      Could you explain why I wouldn’t want it? I knew it was optional but I hadn’t got this bit of history yet.
      - tialaramex 4y ago
        If you just throw the attestation away (or do something morally equivalent, like log it and then only read the logs once in the first week when you're interested) then you annoyed the user (this prompts me to permit attestation, and explicitly refuse) for no purpose. Hopefully in authentication it's not necessary to explain why higher friction is not good. If you use the attestation to make decisions (e.g. allow Yubico products, refuse everything else) now you've got the burden of those decisions. You need to stay on top of new products, evaluate them and decide what's acceptable. For a private site you can control the burden by e.g. requiring employees to use the company branded Yubico authenticator, and just making sure you allow any new batches Yubico ships when you buy more, but for a public site this is definitely a real piece of work for a small team. If you're doing that work - to what end? Do you have the information to make wise choices? I think the user is far more likely to know whether the authenticator suits their purpose than you. They may know that - because they're constantly working with abrasive chemicals using their bare hands - their fingerprints are trash and so the fingerprint reader you recommend doesn't work, they go with the PIN entry device. Or despite your preference for USB-C they work all day with servers that only have USB-A ports so they want a USB-A authenticator. For a private site you actually might have policy coming from above that's most easily implemented using attestation. Like stupid password policies, at some point you've told the Powers That Be what you recommend, they've ignored it, you just do what they said and roll your eyes. On a public site it's just crazy. Attestation compromises FIDO's "Relying parties shouldn't care what the authenticator is" design because now you do care what the authenticator is. So as a purist that's enough reason to rule it out.

by lxe 4y ago

tptacek 4y ago

How could it be simpler? You ask the browser for a credential associated with an opaque ID, and get back a public key with its own ID. To use the credential, you ask the browser to sign a challenge (another opaque ID), and the browser gives you back a signature, which you check against the key. It's almost the simplest thing that could possibly work; it's much, much simpler than OAuth2. This page is an excellent summary introduction to WebAuthn, but it makes the API look more complicated than it is, because it surfaces a lot of options you probably won't care about.

tedunangst 4y ago
An API (or guide thereto) that surfaces fewer options seems like the obvious way it could be simpler. Is attestation optional or required? Is there a default? Can I not care? What do I read to not care?
- dyml 4y ago
  It’s available at https://Passwordless.dev https://Passwordless.dev. I’ve worked on a open source library for fido2 for about 4 years and we created an API that makes it A LOT simpler to get started. And when ever you want to leave the API/Service you can just migrate to whatever self hosted webauthn service you’ve setup. Happy to answer any questions.
- tialaramex 4y ago
  > Is attestation optional or required? Is there a default? Can I not care? What do I read to not care? Attestation is optional, the default is not to have it, and you should not use it. It's something some people insisted they needed, and eventually it's easier to let them have the feature than keep explaining why it's a bad idea. So, you can elide that element of the structure, or, write "none" instead of "direct" here to say you don't want attestation.
  - CSSer 4y ago
    Could you explain why I wouldn’t want it? I knew it was optional but I hadn’t got this bit of history yet.
    - tialaramex 4y ago
      If you just throw the attestation away (or do something morally equivalent, like log it and then only read the logs once in the first week when you're interested) then you annoyed the user (this prompts me to permit attestation, and explicitly refuse) for no purpose. Hopefully in authentication it's not necessary to explain why higher friction is not good. If you use the attestation to make decisions (e.g. allow Yubico products, refuse everything else) now you've got the burden of those decisions. You need to stay on top of new products, evaluate them and decide what's acceptable. For a private site you can control the burden by e.g. requiring employees to use the company branded Yubico authenticator, and just making sure you allow any new batches Yubico ships when you buy more, but for a public site this is definitely a real piece of work for a small team. If you're doing that work - to what end? Do you have the information to make wise choices? I think the user is far more likely to know whether the authenticator suits their purpose than you. They may know that - because they're constantly working with abrasive chemicals using their bare hands - their fingerprints are trash and so the fingerprint reader you recommend doesn't work, they go with the PIN entry device. Or despite your preference for USB-C they work all day with servers that only have USB-A ports so they want a USB-A authenticator. For a private site you actually might have policy coming from above that's most easily implemented using attestation. Like stupid password policies, at some point you've told the Powers That Be what you recommend, they've ignored it, you just do what they said and roll your eyes. On a public site it's just crazy. Attestation compromises FIDO's "Relying parties shouldn't care what the authenticator is" design because now you do care what the authenticator is. So as a purist that's enough reason to rule it out.