Tie everything to apple/whoever is pretty darn dystopian. And the "second factor" as described in this article doesn't exactly sound enticing.
Passkeys for Infrastructure
21–30 of 73 posts
Re: Passkeys for Infrastructure
#22You can't use Passkeys on iOS without iCloud, and you can't get an Apple ID without a phone number, which frequently maps to real-world ID. This means that soon your logins will be tied to your ID.
Re: Passkeys for Infrastructure
#23Is there any writeup about passkeys privacy? Tie everything to apple/whoever is pretty darn dystopian. And the "second factor" as described in this article doesn't exactly sound enticing.
https://www.w3.org/TR/webauthn-2/#sctn-privacy-consideration...
However Passkeys puts apple in a position of the Authenticator which is the riskiest part in terms of privacy.
Re: Passkeys for Infrastructure
#24Is there any writeup about passkeys privacy? Tie everything to apple/whoever is pretty darn dystopian. And the "second factor" as described in this article doesn't exactly sound enticing.
If you're more interested in WebAuthn privacy more generally, there's quite a bit of it in the WebAuthn specification itself, since it was an important goal of the design.
Re: Passkeys for Infrastructure
#25I wish SSO providers were able to hook into this Passkey mechanism. Instead of storing Passkeys in iCloud for sync instead we could store them at the SSO provider
you get a system where you can finally own your own identity and the first thought you have is to how to reaquire that dependency on a for-profit entity
Re: Passkeys for Infrastructure
#26Earlier quoted context omitted.
The problem with passkeys IMO is they typically aren't portable between devices, and if they are, they will have some of the same problems as passwords. A long passphrase will probably have the same threat profile as a portable passkey, but with an easier implementation.
Passkeys (in the sense the article is referring to, which is to say FIDO2 passkeys) are explicitly portable between devices. And the difference is they're always unique per-site in a way that passwords are not necessarily. It's possible to approach the security of passkeys if you always use unique passwords per-site (with e.g. a password manager) but you're still then vulnerable to phishing unlike with passkeys.
Re: Passkeys for Infrastructure
#27Is there any writeup about passkeys privacy? Tie everything to apple/whoever is pretty darn dystopian. And the "second factor" as described in this article doesn't exactly sound enticing.
Re: Passkeys for Infrastructure
#28Is there any writeup about passkeys privacy? Tie everything to apple/whoever is pretty darn dystopian. And the "second factor" as described in this article doesn't exactly sound enticing.
Apple has pretty good security whitepapers about how it does end-to-end encryption for Keychain items like this. If you're more broadly concerned about Apple not honoring those, having (un)intentional vulnerabilities, or them having the ability to shut you off from your account, then you can always fall back to non-synced FIDO2 devices, like a Yubikey. The underlying technology in both is the same: WebAuthn. I'd imag…
No, you can not. Because they are completely broken for a lot of use-cases, especially when you can only add one or two of them makes them worse than even passwords in many situations.
Re: Passkeys for Infrastructure
#29Is there any writeup about passkeys privacy? Tie everything to apple/whoever is pretty darn dystopian. And the "second factor" as described in this article doesn't exactly sound enticing.
There is a large section on privacy in the spec. https://www.w3.org/TR/webauthn-2/#sctn-privacy-consideration... However Passkeys puts apple in a position of the Authenticator which is the riskiest part in terms of privacy.
A different authenticator is paramount but the question is how secure and private a self-hosted solution can be, with reasonable effort.
Re: Passkeys for Infrastructure
#30* They effectively entrust the keys to your entire digital life to (right now) either Google or Apple. Account compromise, or a ToS-related suspension, becomes catastrophic.
* Domain changes happen (acquisitions, rebrands, etc.), and there is no way to share or migrate passkeys between domains. Right now the best you can do is a highly manual process involving the user authenticating on the old domain, registering a new credential on the new domain, and somehow linking them. This process itself could be highly vulnerable to interception, since every site would likely have to build a bespoke way of doing it.
* There's no way to migrate your passkeys between ecosystems. So if you're an iPhone user, and all your logins are iCloud Passkeys, it becomes really hard to switch to Android.
* Password-sharing is regrettably used a lot right now, but it's the simplest thing that works. For example, I and my husband have a shared 1Password vault for things like utility and streaming account logins. Right now none of the Passkey syncing providers support anything like that (and I feel like they won't, because it'd be a huge vector for scams).
I think the password is going to stick around until these issues are addressed.