3 ms·

Passwords can be compromised on client side or server side and since users tend to reuse them, compromise on fun.com can compromise your bank.com account. Pass

Passwords can be compromised on client side or server side and since users tend to reuse them, compromise on fun.com can compromise your bank.com account. Passwords+OTP plus a whole bunch of heuristics based account lockdown mechanisms improve this quite a bit. But still OTP is vulnerable for sophisticated targeted attacks. Passkeys improve on this while actually improving the usability as well. Passkeys come in two flavors – independent-hardware-bound (example: yubikey) and platform-authenticator-bound (example: Passkeys by Apple). The former is bound to a single hardware token but can be used on many devices (your phones, laptops etc) to login to your accounts. The latter is primarily tied to your Apple ID account (where Apple is the platform provider, for example) and also to your Apple devices like iPhones and MacBooks where your Apple ID is already logged in and iCloud Keychain syncing is turned on. Apple automatically and securely syncs your passkeys to those devices. Obviously hardware-bound is a bit more secure than platform-authenticator bound, because platform authenticator can have a SPOF within the platform (a compromise anywhere within that platform stack - client-side, server-side etc. large surface area) where such a compromise is also completely hidden from the user. In contrast, the hardware-bound has a much smaller surface area. Only possibility of compromise are the hardware, the client (browser or the app), and the particular app backend server-side. Like all software stack, it is very likely this stack also has bugs that can be exploited. But this stack is relatively lot simpler to audit and secure.

taeric 3y ago
Right, I don't know how to be precise in simple paragraphs about the ideas here. Basically, though, if you can authenticate from two or more devices (or, in a real sense, even applications on the same device), then whatever compute or secret is doing the authentication has to be copied between them. A brief dump of my understanding: (Edit to add, I put this dump here largely to see if I actually understand the general landscape. If there are holes/mistakes here, please call them out.) This was historically done by trusting the user to manage a secret that they attest they will not let anyone else know. In this world, the "compute" was often common knowledge, but hinged on a hard to guess part. This is no different than a credit card, so far. You agree that you will not let unauthorized users have your credit card. A not surprising hole in this security, was that you had no way of knowing if someone else had your secret. You could do audits, but in general access patterns had to checked by others. (Note, this works better than folks give credit.) Security keys took the path of making it so that the secret never gets off of the token device. There would be a challenge protocol that you could only succeed if you knew the secret, which was offloaded to the token. If you lost your token, you could not just get a new one. As the secret was flat out gone. Passkeys are taking a lot of the security lessons learned there, and trying to bring them to the general public. In doing so, though, they are looking to increase user friendliness by letting your secret be managed by their ecosystem. In the case of Apple and Google, they are basically taking the route that, as long as you are sticking to their programs and services, they will replicate a secret for you. This article is upset that Apple and Google are limiting the replication. Calling it a trap of passkeys. But... what is the alternative that is being pushed? Note that if the argument is that the increase in security is already enough with existing audits and non verbally communicated passwords, that is probably fine. I got the tone from the article that something sinister was at play from Apple/Google. Sounds like the sinister motivation is more of wanting high security, though?
danShumway 3y ago
It's not clear to me that "platform-authenticator-bound" passkeys are a real thing. I've actually talked to someone behind the upcoming portability standard, and their standard allows for arbitrary export (encrypted, but in a form where the user can control the keys). I did not get the implication from them that passkeys are meant to be "platform-bound", I think that's a security standard that's mostly made up, the impression they gave me was that user control over export to arbitrary clients was a strongly supported use-case in the upcoming spec. Even Apple keys are not platform-bound today in the way you suggest (ie, bound to your Apple ID) -- Apple keys can be shared to other users using Airdrop, they're not bound to a singular Apple ID. In practice, while passkeys are a meaningful reduction in phishing risk, they can be compromised, leaked, or phished, even in their current state -- and certainly will be phishable once portability standards land. That doesn't make them useless! But it does mean that we should stop pretending that the current lack of export is a pure security measure. The entire promise of portability is the promise that companies like Apple are not trying to create platform-bound keys. We're at least meant to believe that these companies want passkeys to be truly portable between platforms. If "platform-authenticator-bound" is a thing, I suspect you are not explaining it correctly? Or maybe I'm misunderstanding what you mean -- but passkeys are not (intended to be) restricted to individual platforms.

taeric 3y ago

Right, I don't know how to be precise in simple paragraphs about the ideas here. Basically, though, if you can authenticate from two or more devices (or, in a real sense, even applications on the same device), then whatever compute or secret is doing the authentication has to be copied between them. A brief dump of my understanding: (Edit to add, I put this dump here largely to see if I actually understand the general landscape. If there are holes/mistakes here, please call them out.) This was historically done by trusting the user to manage a secret that they attest they will not let anyone else know. In this world, the "compute" was often common knowledge, but hinged on a hard to guess part. This is no different than a credit card, so far. You agree that you will not let unauthorized users have your credit card. A not surprising hole in this security, was that you had no way of knowing if someone else had your secret. You could do audits, but in general access patterns had to checked by others. (Note, this works better than folks give credit.) Security keys took the path of making it so that the secret never gets off of the token device. There would be a challenge protocol that you could only succeed if you knew the secret, which was offloaded to the token. If you lost your token, you could not just get a new one. As the secret was flat out gone. Passkeys are taking a lot of the security lessons learned there, and trying to bring them to the general public. In doing so, though, they are looking to increase user friendliness by letting your secret be managed by their ecosystem. In the case of Apple and Google, they are basically taking the route that, as long as you are sticking to their programs and services, they will replicate a secret for you. This article is upset that Apple and Google are limiting the replication. Calling it a trap of passkeys. But... what is the alternative that is being pushed? Note that if the argument is that the increase in security is already enough with existing audits and non verbally communicated passwords, that is probably fine. I got the tone from the article that something sinister was at play from Apple/Google. Sounds like the sinister motivation is more of wanting high security, though?

danShumway 3y ago

It's not clear to me that "platform-authenticator-bound" passkeys are a real thing. I've actually talked to someone behind the upcoming portability standard, and their standard allows for arbitrary export (encrypted, but in a form where the user can control the keys). I did not get the implication from them that passkeys are meant to be "platform-bound", I think that's a security standard that's mostly made up, the impression they gave me was that user control over export to arbitrary clients was a strongly supported use-case in the upcoming spec. Even Apple keys are not platform-bound today in the way you suggest (ie, bound to your Apple ID) -- Apple keys can be shared to other users using Airdrop, they're not bound to a singular Apple ID. In practice, while passkeys are a meaningful reduction in phishing risk, they can be compromised, leaked, or phished, even in their current state -- and certainly will be phishable once portability standards land. That doesn't make them useless! But it does mean that we should stop pretending that the current lack of export is a pure security measure. The entire promise of portability is the promise that companies like Apple are not trying to create platform-bound keys. We're at least meant to believe that these companies want passkeys to be truly portable between platforms. If "platform-authenticator-bound" is a thing, I suspect you are not explaining it correctly? Or maybe I'm misunderstanding what you mean -- but passkeys are not (intended to be) restricted to individual platforms.