The what and why make sense. The how is poorly done. People are generally familiar with passwords but passkeys are different.

sadly it seems like most of the banks I use still enforce antiquated password rules, no MFA and rely on stupid questions most of which can easily be guessed from public records.

You're agreeing precisely with the parent commenter that passkeys are, from a user's perspective, just passwords that require the use of a password manager. The difficulties many people have understanding or using passkeys are valid to point out and criticize, but they're precisely the same difficulties people have moving from the paradigm of "memorizing or writing down all my passwords" to "using a password manager."

>I have senior citizens asking me

>instead they have a mixed Windows + Apple setup with 3rd-party password manager

Why do I feel like this scenario is entirely fabricated.

What fucking "senior citizen" is confused by a passkey, but has multiple devices and password managers?

So you're saying that if you're inside Apple's walled garden, it works really well! Hmm...

[dead]

I don't think you're giving those seniors good advice. When the banks ask people to "switch" to passkeys, they're not removing the passwords; they're adding passkeys as an alternate login mechanism.

If you lose your bank passkey, (e.g. if you put it in the wrong password manager and you can't figure out where it is) you can just sign in with your bank password.

In the worst case, banks actually don't make it very hard for seniors to reset your password/passkey; just show up at a branch with photo ID, your bank card, and your PIN, and a teller will help you reset your credentials. They do it all the time.

And, remember, seniors could also put a randomly generated password into the wrong password manager. In that case, they'll either have to reset their password, or they'll have figure out what they did, retrieve their password from the OS password manager, and transfer that password to their preferred password manager.

The exact same story applies to passkeys, except, because passkeys can't be copied and pasted, you'd have to figure out how to use the finicky app-to-app transfer system ("Credential Exchange Protocol"). That's probably too complicated for most seniors, so falling back to a password is almost certainly their best bet.

Yes, this is exactly the problem.

Multiple pieces of software vying to be your passkey provider, often using dark patterns so you don’t realize you’re making a choice, and not using the term “passkey” so people are using the technology without knowing what it is or how to research it.

Kind of reflects the state of the web today, where every company wants to be your intermediary in every interaction, from making a purchase to transcribing a meeting.

> The idea was to provide a phishing resistant authentication method for enterprise users (companies loose quite a lot of money to phishing).

Honest question: If the main issue is phishing, why wasn't something like Yubikey adopted more widely - or dongles, or the venerable chip cards we have since the 80s?

Everyone knows what a key is - I mean the thing you open doors with. Most people know the basic security implications as well as what to do if you lose one.

The simplest way to translate that to "electronic keys" would be a dongle or chip card - that lets a device use its identity as long as its plugged in, but is not physically locked to that device. A user can unplug it, take it home with them or plug it into a different device. What a user can't do is copy them, so the same phishing protections as with passkeys are provided.

But for some reason, this never caught on except for niche solutions. Instead, the industry is increasingly moving to systems where the keys are fused with the devices themselves, using TPMs or similar technologies that can't be removed from the device. Which gives you all the well-kniwn hassles if keys have to be moved or devices get lost or stolen.

But I don't understand why this is done.

I don’t see hardware tokens (like Yubikey) in the list. Those are the only ones that provide a true second factor, to protect against the theft or compromise of your primary device.

I’m a little afraid that hardware tokens are getting lost in all the passkey marketing BS. At least they continue to work for now.

WebAuthn is the standard for token authentication.

(I.e., Yubikeys and other USB sticks.)

It works fine and it a no-brainer to use.

The problems start when vendors start trying to shoehorn their shitty cloud auth services into WebAuthn.

There 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/

It should have never been a cloud password manager play. It should be hardware device only, and tied to the device. One passkey on each hardware device.

> Every single major password manager supports export.

They all support exporting passwords, but, check your CSV; you won't find any passkeys in the CSV export for Apple, Google, Microsoft, Mozilla, 1Password, or LastPass.

(Bitwarden, Proton Pass, and KeepassXC do support exporting passkeys to CSV, which undermines the phishing protections, at least somewhat. It’s possible to trick you into exporting your passkeys from Bitwarden and sending the file to an attacker. It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.)

> How useful is your firefox passwords on an iphone?

Did you try it? That's the primary feature of the Firefox app for iPhone.

(Especially since the Firefox app for iPhone is just Safari's WebKit wearing a Firefox disguise.)

> Or Mac OS's keychain I use as a daily driver on my windows gaming desktop?

https://apps.microsoft.com/detail/9pktq5699m62?hl=en-US&gl=U...

> With the iCloud for Windows app, you can access photos, files, passwords, and other important information from your iPhone or other Apple devices on your Windows PC.

When Apple's your password manager, you use Apple's password manager app to synchronize passwords and passkeys.

> That's just wrong. I use android, my partner uses ios. If he creates the passkey in safari, it's not going to get synced over to my phone

It would, if the people implementing it weren't all so obsessed with pushing their own platform-specific solutions over enabling open standards. LastPass works fine on Android, iOS, Mac, and Windows, but each one of those platforms defaults to saving passkeys in their own platform-specific store unless you jump through hoops to specifically save them somewhere else.

>That's just wrong. I use android, my partner uses ios. If he creates the passkey in safari,

There. You just violated the premise of his point, that you use a password manager that syncs to all your devices.

> That's just wrong. I use android, my partner uses ios. If he creates the passkey in safari, it's not going to get synced over to my phone. And that's just the first of the family sharing passwords issues. Same person issue is also present if somebody uses an iphone and a windows laptop, or chromebook.

The passkeys sync just fine between iOS and Android on our devices using 1Password.

All of the major operating systems and all of the major browsers are password managers. Apple, Google, Microsoft, and Mozilla are all password managers. They all have apps that let you access their password managers on other operating systems.

You're right that all of the major password managers like their lock in. The Credential Exchange Protocol is just barely good enough that OS vendors can say they "support" it, but tricky enough to find that ordinary users probably will never try it. (Not to mention that it doesn't even work yet on Windows or Android.)

As for attestation, the good news is that Apple always returns 0s for the attestation ID (because Apple, like you, opposes it as a side channel), and so any public site/app that insists on attestation would reject all Apple devices. This gives smaller password managers like Bitwarden sufficient cover to 0-out their attestation as well.

> back those passkeys up to paper

Is writing down passwords something people do? I have countless passwords saved over >20 years and I don’t think I’ve ever recorded one to paper. I even checked a couple of popular password management solutions and they don’t seem to have “print” functionality.

There’s a process to scan a QR code with your phone and your phone then authenticates with the passkey.

Apple, Google, Microsoft, Mozilla, and 1Password don’t let you export passkeys to a file that you can read and backup, but Bitwarden, Proton Pass, and KeepassXC do.

I think Bitwarden is on HN's current happy list. (I just use Apple iCloud myself.)

Allowing passkeys to be exported to a plaintext file undermines the phishing protections, at least somewhat. It’s possible to trick you into exporting your passkeys from Bitwarden and sending the file to an attacker.

The major password managers say that this is the reason they don’t allow exporting passkeys, and it’s not false, but they’re also making it harder to switch password managers, which may be their ulterior motive. (You can’t even import those exported passkey files into any of the major password managers, which they would be incentivized to do, if those smaller players had significant marketshare.)

It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.

Depends on what qualifies as a password "manager", but I've been using pass (https://www.passwordstore.org/) for years on multiple desktops, and have recently added iOS app sepass to my setup (https://sepass.modiot.com/).

Quite complicated to get it all setup (definitely not for non-technical users), but both are GPL and I now have all my passwords available with hardware protection (yubikey on desktop, secure enclave on iOS) in all locations.

> That's the most annoying thing about password managers, and a major reason I still don't use them: there exists no password manager that is cross-platform (desktop/mobile in particular), local-first, and isn't sketchy or enshittified or otherwise on HN's current "don't use it, use <whatever> instead" list.

I had the same frustration, I ended up with Keepass, the store is a open spec db[0] that has several clients, I use it across windows, android, and Linux without any issue and just sync with your favorite file sync tool.

0 - https://keepass.info/help/kb/kdbx.html

> That's the most annoying thing about password managers, and a major reason I still don't use them: there exists no password manager that is cross-platform (desktop/mobile in particular), local-first, and isn't sketchy or enshittified or otherwise on HN's current "don't use it, use <whatever> instead" list.

I've used pwsafe for years now. I think it checks off all your boxes. Works on desktop and mobile. Local-first but allows cloud if you really want to. No ads or enshittification. Bonus: Open Source. Other Bonus: Not owned by BigTech or LittleTechThatValuesMonetizationOverSecurity

Speaking about hardware tokens:

If I have to go get the backup out of "secure" storage each time I want to add a new Passkey it's not really a backup.

The design should have allowed, even if it was just within only the purview of a single manufacturer, a method for the device to export an encrypted dump that could be reloaded onto a factory-new device. Heck, make it a value-added service that the manufacturer has to initiate and tie it to some real-world identity verification.

The idea of having to put backup devices in-hand regularly is a bad design.

Phone apps. get around this idiocy by backing-up the encrypted Passkeys to a hosted service.

Just have the 2nd device when you create any account. But have it away from the 1st device always. Just update 10s or 100s of accounts for every new device. Just never use sites which allows 1 Passkey.

That's where the attestation feature comes in. It allows them to force you into a hostage situations by restricting passkey implementation. There's a reason that was part of the spec from the get go but a passkey transfer system wasn't.

Yes, I did. When you set up a passkey on your phone in your password manager, you'll transfer it to your other device using your password manager.

Either your password manager will automatically synchronize for you, or you can transfer your passkey to another password manager that will do the synchronization, via the finicky app-to-app transfer system (Credential Exchange Protocol). You can transfer from Apple to Bitwarden and vice versa.

The family sharing question was added later, but the answer is: all of the major password managers have finicky family-sharing features for passwords and passkeys.

For passwords, most people don't bother with formal family-sharing features, and just share passwords via copy and paste. For passkeys, you have to use the family-sharing features, which means you and your family member have to use the same password-manager vendor to share those passkeys.

It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.

They're just text behind the scenes, so you can copy them if you really want to. KeepassX lets you do it, and got into a kerfuffle about it.[1]

It's an impossible design. It's all just obfuscation, most of which is confusing to users.

[1] https://github.com/keepassxreboot/keepassxc/issues/10407