alt Hacker NewsThere are some parts of this that are correct and other parts that are incorrect:
>1. The idea was to provide a phishing resistant authentication method for enterprise users (companies loose quite a lot of money to phishing).
This is incorrect. The idea was to provide a phishing resistant primary factor that could compete with the usability of passwords to the point that consumers would actually want to adopt it.
>2. Majority of industry players shared the vision of a credential which is available across the platforms and browsers
This is correct/accurate.
> 3. The vision for collaboration never materialized so everyone went their own way to implement it. Examples would be google rolling out browser (Chrome) managed authentication which led to this situation where even on the same machine you have to remember which browser you used to create the Passkey credential.
IIRC at least Chrome's default on Apple platforms is to save to the Passwords app by default. There are then multiple fallback options in the case that the user isn't using the default credential provider -- ultimately falling back all the way to cross-device passkey sign-in (the QR-code initiated sign in) or Security Key.
The security engineering behind the QR-code cross-device sign-in stuff is interesting: https://www.corbado.com/blog/webauthn-passkey-qr-code#4-pass...
That said, I strongly agree that fragmentation of where passkeys get saved is super confusing and I wish there:
(a) was stronger guidance from the FIDO alliance on both educating users that it's totally fine to have multiple passkeys across different ecosystems (e.g. one in Apple, one in Google), and;
(b) that all the credential managers could figure out a better way to place nice together and make it super clear to the end-user where a passkey is getting stored, what context it's for (e.g. personal vs. work), and actively help them store it in the right place (which might be different credential manager app for personal vs. work!).
> 4. Interestingly enough the earlier popular name was WebAuthn, Apple started calling it Passkey on fly, given Apple's popularity everyone just caved in.
This is incorrect -- passkeys are not just another name for WebAuthn. If you go back and look at the original definition Apple gave for the word passkey, you'll find that it was meant to be a discoverable WebAuthn credential that syncs across a user's devices with end-to-end encryption. There was a bunch of industry thrash around the definition, but it seems like the original Apple definition has largely stuck/settled now, and when passkeys don't sync they're typically called "device-bound passkeys" rather than just "passkeys".
>5. My personal interpretation is that in some sense Apple wanted to be the default password manager on Apple devices.
If you go back and watch the original passkeys announcement from Apple, their stated goal was to create something that is both a better user experience and more secure than passwords. By "better user experience", they meant the act of creating credentials and then repeatedly using those credentials (logging in).
Part of actually achieving that goal means there needs to be something that "just works automatically out of the box" which means there needs to be a built-in credential manager. That said, Apple credential manager had already existed for many many years by the time passkeys came around. The only thing that changed was instead of being solely accessible from inside System Settings (which was hard for the average user to find), the functionality moved into a standalone Passwords app.
>6. This is when all password manager companies jumped in strongly to save their business and the protocol went into a direction where you can use your existing password manager to store the credential/Passkey as well
I think it's a huge positive that all the password managers jumped on board, and that they could jump on board (since WebAuthn is an open standard). I think this is a good thing for consumer choice and for overall adoption and perception of passkeys. A lot of folks (including on this thread) have big tech lock-in conspiracy theories about passkeys, and the conspiracy theories would be even more prevalent without a wide spectrum of consumer choice for credential managers.
>If you are using it with security in mind then my recommendation would be to use a hardware backed security key with NFC enabled. Everything else is pretty much lipstick on pig, they are worse than passwords in some sense from usage perspective.
Passkeys protect against phishing attacks, and you get that protection regardless of whether the credential is hardware-bound or not. That protection comes from the cryptographic binding of the credential to the domain at the time of credential creation.
The only additional protection you get by making the passkey hardware-bound is preventing an attacker who has already compromised your operating system from stealing the credential. But! Unless you are also doing hardware binding of the session (aka cookie) after sign-in, then doing hardware binding of your credential is mostly security theater, because the attacker can just wait for you to sign in and then steal your session.
And there is standards work happening separately for hardening session security, such as DBSC: https://w3c.github.io/webappsec-dbsc/
I try to be accurate when sharing information like this. Some things are fact and some things are opinions, I already tried to annotate the opinions as interpretation. Most of the information is first hand, I was a member of FIDO alliance in past, have been watching these discussions.
1. This can be subjective, Unfortunately Customer identity is not on the highest priority from security perspective, its all about ease of product use when it comes to customer identity. For customer identity, most account recovery methods still fall back to email or SMS even if you have 2FA configured. The real money lost with phishing is with enterprise identity, when some one poses as an employee. The recovery of these accounts can be managed. If a customer account gets hacked then the business is not really on the hook to make it even.
> Usability of passwords
This is the biggest point of contention as per my interpretation. The industry did a very poor job of securing their infrastructure leading the massive leaks of password databases. Instead of fixing that goal post changed, with the by introduction of PASSWORDLESS. The passwordless works just fine for enterprise identities, not the customer identity. Even for enterprises, you cannot get rid of passwords if you get into AAL concepts (guidelines provided by NIST for authenticator assurance levels)
4. I was working on WebAuthn when the term passkey was not there, I was there when the term was introduced, I saw how every one was trying to map their existing definition/understnading with the new terminology specially the part where Apple just announced them to be syncable. Enterprise companies had to actually disable the Apple Passkeys for this reason to begin with. I found it interesting to see how Yubico changed their documentation overnight, they switched every instance of WebAuthn keyword with Passkey. It took some time to settle on how to categorize discoverable credentials (where meta information about user is on the device in addition to credential) and non-discoverable credentials (hardware keys, they are limited in space so they did not store user meta information in earlier versions). Eventually google took the lead in calling the credential where private key cannot be synched as Security key and everything else as Passkey. Resident key, syncable, synched are all different bits of the WebAuthn assertion
5. Thats an interpretation of how I read things based on the overall play going on.
> Passkeys protect against phishing attacks, and you get that protection regardless of whether the credential is hardware-bound or not. That protection comes from the cryptographic binding of the credential to the domain at the time of credential creation.
The security aspect is tightly coupled with the authenticator implementation. The phishing aspect is the only default good in here, it just means that the credential is strictly tied to a particular domain, the one on which it was set, that too is highly dependent on the client (browser) doing the right thing. Additionally you have to count on the server to not get compromised as well (There is a a feature to support multiple domains).
Most importantly, when you make something this hard and complex to understand then be advised that people are going to make mistakes in implementation and leave gaps in security.