6 ms·

Mostly agree with a lot of this, but it's a little unfortunate to lump all WebAuthn authenticators together. WebAuthn keys--physical dongles you plug into the

by md_ 6y ago

Mostly agree with a lot of this, but it's a little unfortunate to lump all WebAuthn authenticators together. WebAuthn keys--physical dongles you plug into the USB port--are indeed problematic for the reasons the author notes. (A small--but user-visible--cost; the requirement for a spare USB port of the right form factor; loss.) However, authenticators that are built into the client device (e.g. Apple's support for a TouchID-verified WebAuthn authenticator) solve these problems, to varying degrees: the user doesn't see a marginal cost (it's built into the computer!) and doesn't have to worry about loss, USB ports, etc. The principle challenge with using (as an example) Safari's WebAuthn support is what how the relying party should support loss of the device. (If you lose your Safari--or claim to--how does your bank authenticate you?) Ultimately, the lost-device--or new-device bootstrapping--problem is currently what stands in the way of a truly secure ecosystem, but with platform providers increasingly supporting WebAuthn, we can at least reduce phishing risk to "phishing of the platform provider credential." Your iCloud password might get stolen, but at least that's the _only_ thing an attacker can steal to gain access to your other accounts. For most services, delegating authentication (and anti-phishing) to someone like Apple is a big plus.

edent 6y ago
I think that's a fair comment. It would be great to see more device come with built in support for this.
- md_ 6y ago
  Platform support isn't exactly the problem. Apple, Microsoft, and Android all support WebAuth (https://blog.mozilla.org/security/2019/03/19/passwordless-web-authentication-support-via-windows-hello/ https://blog.mozilla.org/security/2019/03/19/passwordless-we..., https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/ https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-..., https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/webauthnapis https://docs.microsoft.com/en-us/windows/security/identity-p..., https://developers.google.com/identity/fido/android/native-apps https://developers.google.com/identity/fido/android/native-a...), so most (??) users are in fact covered. eBay, for example, offers a passwordless experience using WebAuthn--so it can be done, even on a major consumer site. The problem is really that until relying parties can trust that 1. Platforms will backup and restore key material from authenticators 2. Users will figure out how to use those backups (including if they e.g. switch from Mac to Windows) they will have to provide some fallback. (Realistically, that means "for the foreseeable future.") This relegates WebAuthn, unfortunately, to a "neat trick"--eBay's "passwordless option"--and not a security guarantee. (Phishers can always downgrade the user to passwords or similar.) What's needed in the interregnum is probably a way to make that fallback option more secure by, at minimum, conveying to users that it's not _normal_--so that phishing attempts targeting that phishable backup are less likely to succeed. Unfortunately this requires a lot of good UX design and unilateral action on part of the relying parties, which I think is tough.
  - folmar 6y ago
    One form of securing fallback mechanism is to include a long delay, some 2 days, between reset request and execution. It surely does not fit all use cases, but should be good for a lot of less critical stuff.
3np 6y ago
I also think the most of the issues they bring up I understand as adoption (which gets improved by increased adoption on the user side), tolling maturity, and habits. TOTP and U2F actually has achieved pretty wide adoption, so I have hopes for WebAuthn.
drcongo 6y ago
I use Krypton [0] as a virtual YubiKey, I like it a lot but they got acquired by Akamai and the GitHub accounts have gone worryingly quiet. [0] https://krypt.co https://krypt.co
- md_ 6y ago
  That's cool. Either I haven't seen this before or I've forgotten. :) I do think (as I said elsewhere here) that ultimately people will adopt WebAuthn via their browser/OS vendor. Support is widespread! But for relying parties, there are still challenges to solve.
- dane-pgp 6y ago
  > Krypton is built on top of an end-to-end verified and encrypted architecture. This means zero trust. We, Krypt.co, cannot access your keys or see where you're authenticating. The keys only live in the Krypton app on your phone. Sounds great, except one of the "ends" is likely the Secure Enclave (iOS) or Keystore (Android), over which the user has basically no control. So while the architecture might require "zero trust" of Krypt.co, it still requires complete trust of Apple or Google. Perhaps completely trusting one of those companies is already the reality for nearly everyone, in terms of using a mobile device to access online data, but hopefully WebAuthn-supporting sites don't put extra restrictions on the devices you can use, via the "feature" of attestation: https://www.imperialviolet.org/2019/01/01/zkattestation.html https://www.imperialviolet.org/2019/01/01/zkattestation.html
  - judge2020 6y ago
    Trusting your HSM vendor is a requirement if you don't want your keys to be exportable, and there's much less risk in doing so compared to trusting Apple for other things like secure communications (iMessage is e2ee but doesn't tell you when your peer changes/adds keys, plus unencrypted backups are on by default). Also, a lot of people who use Krypton don't know that SSH keys actually don't use the secure enclave because it doesn't support rsa or ed25519: https://github.com/kryptco/krypton-ios/issues/73#issuecomment-318738866 https://github.com/kryptco/krypton-ios/issues/73#issuecommen...
  - 6y ago

by md_ 6y ago

edent 6y ago

I think that's a fair comment. It would be great to see more device come with built in support for this.

md_ 6y ago
Platform support isn't exactly the problem. Apple, Microsoft, and Android all support WebAuth (https://blog.mozilla.org/security/2019/03/19/passwordless-web-authentication-support-via-windows-hello/ https://blog.mozilla.org/security/2019/03/19/passwordless-we..., https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/ https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-..., https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/webauthnapis https://docs.microsoft.com/en-us/windows/security/identity-p..., https://developers.google.com/identity/fido/android/native-apps https://developers.google.com/identity/fido/android/native-a...), so most (??) users are in fact covered. eBay, for example, offers a passwordless experience using WebAuthn--so it can be done, even on a major consumer site. The problem is really that until relying parties can trust that 1. Platforms will backup and restore key material from authenticators 2. Users will figure out how to use those backups (including if they e.g. switch from Mac to Windows) they will have to provide some fallback. (Realistically, that means "for the foreseeable future.") This relegates WebAuthn, unfortunately, to a "neat trick"--eBay's "passwordless option"--and not a security guarantee. (Phishers can always downgrade the user to passwords or similar.) What's needed in the interregnum is probably a way to make that fallback option more secure by, at minimum, conveying to users that it's not _normal_--so that phishing attempts targeting that phishable backup are less likely to succeed. Unfortunately this requires a lot of good UX design and unilateral action on part of the relying parties, which I think is tough.
- folmar 6y ago
  One form of securing fallback mechanism is to include a long delay, some 2 days, between reset request and execution. It surely does not fit all use cases, but should be good for a lot of less critical stuff.

3np 6y ago

I also think the most of the issues they bring up I understand as adoption (which gets improved by increased adoption on the user side), tolling maturity, and habits. TOTP and U2F actually has achieved pretty wide adoption, so I have hopes for WebAuthn.

drcongo 6y ago

I use Krypton [0] as a virtual YubiKey, I like it a lot but they got acquired by Akamai and the GitHub accounts have gone worryingly quiet. [0] https://krypt.co https://krypt.co

md_ 6y ago
That's cool. Either I haven't seen this before or I've forgotten. :) I do think (as I said elsewhere here) that ultimately people will adopt WebAuthn via their browser/OS vendor. Support is widespread! But for relying parties, there are still challenges to solve.
dane-pgp 6y ago
> Krypton is built on top of an end-to-end verified and encrypted architecture. This means zero trust. We, Krypt.co, cannot access your keys or see where you're authenticating. The keys only live in the Krypton app on your phone. Sounds great, except one of the "ends" is likely the Secure Enclave (iOS) or Keystore (Android), over which the user has basically no control. So while the architecture might require "zero trust" of Krypt.co, it still requires complete trust of Apple or Google. Perhaps completely trusting one of those companies is already the reality for nearly everyone, in terms of using a mobile device to access online data, but hopefully WebAuthn-supporting sites don't put extra restrictions on the devices you can use, via the "feature" of attestation: https://www.imperialviolet.org/2019/01/01/zkattestation.html https://www.imperialviolet.org/2019/01/01/zkattestation.html
- judge2020 6y ago
  Trusting your HSM vendor is a requirement if you don't want your keys to be exportable, and there's much less risk in doing so compared to trusting Apple for other things like secure communications (iMessage is e2ee but doesn't tell you when your peer changes/adds keys, plus unencrypted backups are on by default). Also, a lot of people who use Krypton don't know that SSH keys actually don't use the secure enclave because it doesn't support rsa or ed25519: https://github.com/kryptco/krypton-ios/issues/73#issuecomment-318738866 https://github.com/kryptco/krypton-ios/issues/73#issuecommen...
- 6y ago