Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator.
Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator.
Ideally, there would be a per-passkey UI option to opt out of synchronization at creation time.
> Security must be a balance with functionality, and this is a huge improvement over passwords.
Sure, but I'm somewhat disappointed that the WebAuthN WG basically forced this huge change of semantics (it's essentially a security vs. availability tradeoff) into relying parties without explicitly collecting their opt-in beforehand, or even providing an ergonomic way of opting out.
[1] https://support.apple.com/guide/iphone/sign-in-with-passkeys...
It should also be able for relying parties to express that desire (whether opt-in or opt-out by default). As it is, I think it'll just make banks and governments less likely to adopt passkeys.
That's sad, because all in all I think WebAuthN has the potential to have a very positive impact on security globally.
If a platform gave users this option per credential, and there was any visibility to that choice on the relying party side, the replying party would likely just reject the credentials they don't like outright, and tell people 'go figure out how to twiddle this setting if you want to use your phone here'.
Part of the web focus of these APIs mean that they will default to being open and user centric - features that might enable relying parties to block user choice will receive tremendous scrutiny, and proceed very slowly. Sites are expected for now to accept what the user chooses, and do additional steps as necessary to meet their needs. This means passkeys as a whole are not going to be always accepted as a MFA replacement.
Even features like hardware attestation are gated by a prompt by some browsers, because some consumer-facing websites went live with code saying "we will only support this one brand of security key". This led to some of the warnings in the document here: https://www.chromium.org/security-keys/
I can sympathize with the desire of a "footgun mode", which might even lie to the website about whether the credentials are backed up. However, I wouldn't trust something that critical to what is almost going to be a poorly maintained path through the system. Instead, I use (two) Yubikeys for such credentials.
This is what you expect when you buy into the closed Apple ecosystem.
I must be missing something but I do not get all this hand-wringing. Don’t like the passkey options from Google or Apple? Fine! Use the hardware authenticator you absolutely already have if you’re the kind of person who has these sorts of objections.
Your argument sounds a bit like "Don't like Safari? Just use a different OS then" in the context of allowing browser choice on iOS. There is no technical reason a Passkey provider and OS/platform should be necessarily bundled.
It would encourage competition in both functionality and security, it reduces reliance on a single account your entire digital life, it allows niche products to address special requirements in all kinds of scenarios...
Except… you can just use a YubiKey. It’s closer to saying “install Firefox” than “install a different OS”.
> There is no technical reason a Passkey provider and OS/platform should be necessarily bundled.
Sure, fine. This is like V1 of every provider’s implementation. None of this was even available three months ago, I have no doubt these things are coming.
No, you're literally recommending I use a separate physical device because there is no API to achieve the same functionality that the OS provides via their bundled implementation.
> Sure, fine. This is like V1 of every provider’s implementation. None of this was even available three months ago, I have no doubt these things are coming.
On iOS, Passkeys have been available for more than half a year now. I really hope that Apple will eventually follow suit.
A $50 device that I have no doubt you already own, and that does not require you to change or modify any of your existing computing setup or habits.
If your point truly has merit, you shouldn’t need the hyperbole.
Wonderful. Until every second web service starts to require a signature from such digital identity ("age verification" perhaps?) and that's the end of pseudonymity.
Local-only iOS+macOS Codebook sync (open-source encrypted! by SQLCipher) provides password and TOTP convenience, durability, transparency, decentralization and fewer supply chain dependencies with one-time purchase. Founded in 2005.
Passwords and TOTPs are not MITM-safe, WebAuthN/Passkeys implicitly are. (Credentials are bound to a specific RP, i.e. it's impossible to accidentally provide one to the wrong website or a scammer on the phone.)
Can Apple allow existing password managers like Codebook to manage passkeys and synchronization locally?
Sure, but passwords are still multiple-use, and sometimes auto-fill fails (often due to websites actively messing with it), requiring me to manually copy-paste the password and exposing me to phishing risk, or that of insecure/malicious applications on my system sniffing the clipboard.
> Can Apple allow existing password managers like Codebook to manage passkeys and synchronization locally?
Unfortunately not at the moment. There is some hope though, given that Apple has recently added a TOTP API for third-party authenticators, but I'm personally not holding my breath.
For those, Safari share sheet -> "Find in Codebook" = dialog with URL-matched credentials appearing first.
> insecure/malicious applications on my system sniffing the clipboard
iOS now requires interactive user consent for apps to Paste from clipboard.
Fortunately it does – a big security win. But unfortunately, macOS does not yet, and I'm copy-paste-ing passwords there more often.
I'm often wondering if drag and drop of text is actually more secure than the pasteboard?
WebAuthn is different:
1. The client (browser) knows which site is requesting credentials, which means a phishing site cannot ask for another legitimate site's credentials
2. Credentials are created as private keys and unique per-site.
3. The authentication protocol does not share secrets; it is based on public/private keys.
4. The authentication protocol involved indicates the requesting origin.
There are still vulnerabilities if you have compromised DNS or javascript on the site, but it is overall significantly stronger against phishing and credential reuse attacks than password managers could provide before - even those with browser integration.