I've always thought myself very able to explain technical things quite well to non-technical people, but always struggled to explain the public/private key exchange in a simple way. This is really neat.
A Guide to WebAuthn
71–80 of 122 posts
Re: A Guide to WebAuthn
#72I've written an implementation of WebAuthn for Python-based webapps: https://github.com/pyauth/pywarp that may be useful to implementers.
Re: A Guide to WebAuthn
#73Earlier quoted context omitted.
@nickray, with ssh, I manage the root of thrust. With Webauthn, someone else manages it for me, be it Yubico or Intel or Apple. This is a fundamental difference.
You're wrong. You can manage your own keys. You don't need any big corporation for WebAuthn.
"But attestation is not spoofable. Therefore, if sites launch webauthn support and accept attestations from the current set of token vendors, future vendors may be locked out of the market: Their devices won’t work because their attestations aren’t trusted, and they won’t be able to get sites to update because they won’t have enough market presence to matter."
Re: A Guide to WebAuthn
#74Re: A Guide to WebAuthn
#75Earlier quoted context omitted.
You're wrong. You can manage your own keys. You don't need any big corporation for WebAuthn.
Well, that's assuming that the anti-feature of device attestation doesn't end up being used in the inevitable way that the spec allows: "But attestation is not spoofable. Therefore, if sites launch webauthn support and accept attestations from the current set of token vendors, future vendors may be locked out of the market: Their devices won’t work because their attestations aren’t trusted, and they won’t be able to…
Re: A Guide to WebAuthn
#76Earlier quoted context omitted.
Firefox lets you enable software tokens, and disable USB tokens: in about:config, set security.webauth.webauthn_enable_softtoken=true security.webauth.webauthn_enable_usbtoken=false then the registration will go through without needing a hardware token.
In other words, I can't use it in production (yet), because I'd need to ask users to change browser settings for it to work. That's disappointing :(
Re: A Guide to WebAuthn
#77Earlier quoted context omitted.
@nickray, with ssh, I manage the root of thrust. With Webauthn, someone else manages it for me, be it Yubico or Intel or Apple. This is a fundamental difference.
As Stavros mentions, you can, and if you feel qualified, you should manage your own keys. Be that with some software authenticator you deem safe or write yourself, or with e.g. our keys that are open source, so you can modify anything to your liking, etc. etc. I sense a bit of 90s security thinking from your arguments though, where every end user and mid-level admin handles security decisions they're frankly not qual…
Re: A Guide to WebAuthn
#78Why not a single CBOR object?
Re: A Guide to WebAuthn
#79Earlier quoted context omitted.
Well, that's assuming that the anti-feature of device attestation doesn't end up being used in the inevitable way that the spec allows: "But attestation is not spoofable. Therefore, if sites launch webauthn support and accept attestations from the current set of token vendors, future vendors may be locked out of the market: Their devices won’t work because their attestations aren’t trusted, and they won’t be able to…
Yes, if a service says "we only support Yubikeys for login", you should boycott them.
Similarly, if China mandates a government-approved (backdoored?) device when accessing Chinese websites, I don't suppose Chinese citizens are going to boycott those. Other countries might reasonably retaliate by forbidding sites to accept authentication by devices made in China.
Do you think that if Apple decreed that you can only securely log in to Apple websites with an iPhone (or some other device made by Apple) people would switch to Android? It's hard enough to get people to boycott Facebook despite repeated scandals that are much worse than having a whitelist of supported authentication devices.
Re: A Guide to WebAuthn
#80Why is the information that needs to be sent to the server so complicated? Specifically you need to send the rawId (raw bytes), clientDataJson (json), attestationObject (cbor) and the result of `getClientExtensionResults()` (js object). And then the attestationObject further includes an `authData` field which is itself a structure which contains another field which is CBOR encoded. Why not a single CBOR object?