[dfabulich]

This is much, much simpler than you think it is. Passkeys are just passwords that require a password manager. If you lose your passkey, you'll reset your passkey the same way you reset your password, probably with a "forgot my password" email.

(But you're not going to lose it, because you use a password manager, and the passkey will be stored there and synchronized to all of your other devices.)

The weird part is that password managers provide no way for you to copy and paste your passkeys. To present a passkey, you have to use a password manager. This makes it impossible to copy and paste your passkey to the wrong person (someone trying to trick you).

Major password managers don’t even allow you to export your passkeys to a file that you can read/backup yourself. Instead, the password managers each have their own finicky app-to-app mechanism for transferring passkeys from one password manager to another. (I think all the password managers kinda like that lock in.)

Finally, note that for logging into your password manager itself, you'll always require something outside your password manager to login, probably a password, but possibly a YubiKey; your choice. (It's your one "last password," as they call it.)

https://danfabulich.medium.com/passkeys-are-just-passwords-t...

P.S. It's past time to move off of LastPass. LastPass lost all of your passwords again last month, just like they did in 2022. The most similar service is 1Password. If you like LastPass, you'll like 1Password about the same, but 1Password hasn't had multiple terrible security breaches.

[jasode]

>This is much, much simpler than you think it is. Passkeys are just passwords that require a password manager.

The issue isn't what passkeys _are_ (e.g. explaining they are like public/private "ssh keys" and hoping that type of explanation ends the confusion).

Instead, it's the workflow around passkeys. The websites show very confusing dialog popups and choices that a lot of normal people will not understand. This is a good article with screenshots showing the confusion: https://arstechnica.com/security/2024/12/passkey-technology-...

I have senior citizens asking me about passkeys because their bank and medical websites keep reminding them about switching to passkeys every time they login into their accounts. My recommendation to them is not to do it unless they have a simplistic single vendor setup such as only Apple iPhone and MacBook with iCloud Passwords app. If instead they have a mixed Windows + Apple setup with 3rd-party password manager, they could accidentally put a new passkey into the os or browser instead of their external password manager and not realize what has happened. This happens because the different parties implementing passkeys all have different agendas that suits their interests and that's what makes the workflow confusing for normal people.

[selicos]

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

[Reddit_MLP2]

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.

[vitorgrs]

That might change on the country. At least here in Brazil, all logins require some sorth of MFA.

This changes by banks, some send code to our phone number (thought WhatsApp or SMS), others send SMS+email + face ID. All of them require at least the face ID. Some biggest banks requires you to go to ATM to authorize app access. You insert your card, password and authorize there.

There's Mercado Pago, which supports passkeys and standard MFA too. So you can store on bitwarden even.

[bdamm]

Just the other day I was creating an ID on a government web site, which offered a list of security questions such as "Title of your favorite movie" or "Someone that you admired as a child" and the answer was not allowed to have any spaces.

Just absurd.

[enobrev]

Security questions have always been ridiculous, but I'll especially never understand how "favorite [thing]" ever made it to production anywhere. "Favorite movie" can change multiple times in the same conversation.

[thevinter]

Still better than the government (!!!) website that a few days ago gave me the option of using "What's the name of the company you first worked at?"

[Melatonic]

You can also just put any answer into the question as long as you will remember it.

[edwinjm]

It should work for all people and not depend on these “tricks”.

[account42]

Yet they still work and people generally don't have their accounts stolen. Why? Because security is more than technology. Stealing a bank account is illegal and you will be prosecuted for it.

[marysol5]

hahahahahahahahahahahahahahahahahahahahahahahahahaha

Nobody hacks because that's illegal

[account42]

The optimum amount of hacks is not zero.

[thrixton]

No doubt preaching to the Choir here but I just generate a new pass phrase and store it in Bitwarden. If course for the non HN audience, much more confusing and dangerous.

[tshaddox]

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."

[rstuart4133]

> 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."

Errr, no.

You can transfer a password from one manager to another. Those very same password managers won't let you transfer a passkey they hold.

And if you know the password, you can use it anywhere by just typing it in - no complex technology or protocols involved. But using a passkey involves your secure computer talking to another computer, using a complex protocol that can't go via eyeballs and fingers. If you don't have a way to connect the device holding the passkey to the computer wanting your id - say your USB A Yubikey isn't recognised by your phone, then you are out of luck - you can't use that passkey, even though it's sitting in your hand.

And you can't work around that by copying the passkey to a device that can communicate with the service you're using, because you aren't allowed to copy.

It's an unworkable mess. The mess is not created by passkeys themselves, because, as others have said elsewhere the protocol is pure elegance. The mess is created by vendors choosing lock in over transportability. I'm hoping it's a passing phase.

[tshaddox]

That’s a fair point. My thinking was that, once you’re using a password manager, you’ll A) use it to generate random passwords that would be unwieldy to memorize and B) have passwords synced to all your devices such that you will never deal with the plain text password directly.

Of course it is conceivable to want to directly access the plain text password for reasons you mention, although that would be exceedingly rare (at least for me). In those cases I agree that passkeys don’t work, although I might argue that if the average user thinks they need to access the plain text password, there’s a significant chance that they’re being phished!

[TeMPOraL]

> Of course it is conceivable to want to directly access the plain text password for reasons you mention, although that would be exceedingly rare (at least for me).

It's a daily occurrence for me, because especially because of going through steps A) and B), step C) which is copy-paste is needed to actually transfer the unwieldy, unmemorizable password from the password manager that stores it, into the app that requires it, when the autofill service refuses to communicate between the two.

[tshaddox]

But that sounds like precisely what standardized passkey integration in the browser and website solves! This is honestly how I think about passkeys: they're a standard API for browsers and websites to integrate with password managers without needing a browser extension to manually look for and fill out text inputs on the page.

[fragmede]

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

[baby_souffle]

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

Or google. If you use android and chrome then it all just works.

But god help you if you want to use a password manager to keep everything in sync; I haven't yet found a way for a mobile app or web page to explicitly signal to the device that the passkey to be created should live in $password_manager and not whatever built-in/on-device key-store exists.

So I only really use pass keys for desktop/web things because that's the only place the "store/read from $password_manager" flow _works_.

[rcxdude]

It's probably not something the app or web page should have any visibility or control over. It's more something the browsers and OS should allow a straightforward selection of where you want your passkeys stored (ideally something you can configure the default for globally). But of course the OS and browser vendors are trying to compete to do it, so they're not incentivised to make it obvious or fair.

[fauigerzigerk]

>I haven't yet found a way for a mobile app or web page to explicitly signal to the device that the passkey to be created should live in $password_manager and not whatever built-in/on-device key-store exists.

On Android 17 (on Pixel) you can select the password service under Settings -> Passwords and passkeys -> Preferred service.

If you have an alternative password manager installed, it will be listed there along with Google's own password manager. iOS has a similar setting but I don't know exactly where off the top of my head.

[baby_souffle]

> On Android 17 (on Pixel) you can select the password service under Settings -> Passwords and passkeys -> Preferred service.

I have this set to my password manager but I still can't _use_ the pass-keys in my password manager to sign in to most apps.

[dfabulich]

"Most" apps? So it works in some apps, but not others?

Setting your preferred password/passkey manager on Android 17 to 1Password works fine in Chrome and Firefox to log in to any site, presenting passkeys managed in 1Password. It also works in all of Meta's native apps. (I'm pretty sure it works the same in Bitwarden.)

Whatever issue you're having, it's not an inherent limitation of Android passkeys. It might be a bug in your passkey manager…?

[coffe2mug]

https://f-droid.org/packages/de.noisruker.openPasskeyAuth

Use this then totally offline

[anon7000]

Works fine on iOS. All my passkeys are in 1Password, and every prompt to use or save a passkey goes through 1P. You can also control which password managers are active on iOS (eg, I disable iCloud passwords, and only allow “autofill from” 1Password.)

So yeah, this is cross platform on iOS, macOS, Windows, and Linux.

[coffe2mug]

No one is convincing you need to use it. If it makes it makes other people's lives easy then ok

[marysol5]

>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?

[dfabulich]

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.

[Marsymars]

> 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.

Maybe... I just ran into an annoying scenario where the largest bank in Canada made an administrative error where they mislinked an account belonging to me to my wife's profile.

I went to a physical branch to get it fixed and was told that branches don't have that kind of ability so I'd have to call customer support.

I called customer support and failed the verification questions because the expected answers were wrong, based on their own clerical error. After failing the verification questions, I just got a "we have to end this call, no additional information can be provided, please visit a branch."

I was able to get around it by calling back in and providing the incorrect, but expected answers to pass the verification step - I imagine, however, that this could have turned into a real nightmare for seniors, or anyone who wasn't able to deduce what the expected verification answers were.

[Telaneo]

> I went to a physical branch to get it fixed and was told that branches don't have that kind of ability so I'd have to call customer support.

What are the branches even for if not customer support?

[baby_souffle]

> What are the branches even for if not customer support?

Lots of physical locations make the bank seem big/safe/reputable.

Beyond that, it's sales and a place to have ATMs. I have sometimes been able to get a replacement card issued at a branch instead of waiting for one to show up in the mail.

Some branches will accommodate special requests like "can I withdraw $200... in two dollar bills" / take coin deposits but that's been increasingly rare.

[SoftTalker]

My local branch has had a sign on the front door "our coin counter is broken, sorry for the inconvenience" for the past 6 months. I refuse to believe they don't have a working coin counter in a bank branch; they just don't want customers bringing in a big jars of coins.

[toyg]

A meeting space to discuss business services, and a terminal for people who insist on depositing cash. They are definitely not a customer support terminal.

[marysol5]

Banks don't want to run physical branches anymore, hence why, at least in the UK all local branches are done. And central branches are all that exist.

They want to close even them because the only services they have now is ingesting cash, which is getting less and less anyway.

But yeah, any time I've gone into a branch, which they made me do a few months ago to "validate" my documents for a mortgage. Which was just scanning and uploading to their internet..., they've made me sit on the phone to their call centre.

[crote]

Sales. They are there to talk you into getting the premium mortgage.

[andy99]

This is more a statement of how awful Canadian banks are than anything else. For anyone unaware we have an oligopoly of five identical banks all of which treat their customers like shit and effectively extract tax from the Canadian population while providing nothing.

[ChoGGi]

> while providing nothing.

You forgot about the endless frustration and annoyance.

[YuccaGloriosa]

Ironic given the prime minister's former employment

[kuekacang]

With advent of ai-based impersonation, I wonder why in-person reset is not the priority right now

[pishpash]

Uh, if you set up a passkey it becomes the default almost always. Then on another device it'll pop up looking for it and look like login failure and you need to "try another way". That's alarming to anyone, not to mention seniors.

[dfabulich]

Sure, that's alarming, but if you set up a passkey on the "wrong" password manager, you've (temporarily) lost your passkey. You should probably be kinda alarmed about that.

You can click "try another way" and use your password, and then you'll have access to your bank. But then, you should try to resolve that problem. If you (or a trusted friend/family member) can figure out how to use settings to remove the passkey from your bank's account settings, you can do that, or you can ask a bank teller to help you, instead.

(And, luckily, you won't need a bank teller, because you'll still have access to your account.)

[tetromino_]

> you can ask a bank teller to help you

At virtually all banks, the bank tellers cannot help you with login problems. You will have to call the bank's tech support and somehow navigate AI-modulated phone menu hell.

[dfabulich]

Citation needed. Walk in with photo ID, a bank card, and your PIN, and all the major banks will send you a reset-password email.

[selicos]

Even my primary Credit Union is limiting teller roles in branches. There are still people to help, but then you have to go in person. My nearest branch is a day trip away but I can do most banking tasks at any partner CU location.

[zabzonk]

> just show up at a branch

In the UK at least, there are very few brick & mortar branches anymore - banks expect everything to be done online.

[sandeepkd]

I am an engineer and have some insights on the discussions and developments around it.

ITS NOT SIMPLE AT ALL

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

2. Majority of industry players shared the vision of a credential which is available across the platforms and browsers

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.

4. Interestingly enough the earlier popular name was WebAuthn, Apple started calling it Passkey on fly, given Apple's popularity everyone just caved in.

5. My personal interpretation is that in some sense Apple wanted to be the default password manager on Apple devices.

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

Personally its a mess, the phishing resistant aspect has its own benefits though. 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.

[smelendez]

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.

[thewebguyd]

> Multiple pieces of software vying to be your passkey provider,

Which entirely defeats the point of using passkeys. There shouldn't be a passkey provider the "provider" is your device's TPM/secure enclave + your biometric challenge. They are supposed to be mathematically non-exportable, device-bound.

[unscaled]

"supposed" is doing a lot of heavy-lifting here. According to who? The FIDO2 or Webauthn standards? Or in a perfect world?

FIDO 1.0 started as two different standards: UAF and U2F. U2F was for USB keys used as second factors (so almost always stored in a TPM-like chip and device-bound, but not provided by your platform and there could be multiple of them). UAF were either provided by your platform or by any software and there was no requirement for them to be stored in TPM. Back in the day, very few platform had any FIDO support built-in, so in practice UAF was always done in software (usually based on whatever biometrics/TPM the hardware provided).

So competing options were the default for early FIDO, getting a default platform option is something that came later.

[sib]

Yeah - and as a user, I don't want my device manufacturer to have that level of influence or control over the authentication that I use for unrelated services.

[JohnFen]

> They are supposed to be mathematically non-exportable, device-bound.

Which would make the whole scheme unworkable (at least for me).

[l11r]

I pair of hardware keys (Token2, Yubico, etc) has the benefits from both worlds.

[crote]

Except enrollability. Got a new account? You need physical access to both tokens to enroll it. Got a new token? You'll have to individually enroll every website - provided they even support multiple tokens at all...

Yubikey tried to solve this, for obvious reasons. Their proposal was DOA.

[Itoldmyselfso]

The anti-phising benefits are still very much there even if you sync them to pw manager. Yes it introduces single point of failure (pw manager), but at the same time you no longer need to go reset all your passwords to every service you use if you happen to lose that device. Tradeoffs.

[xg15]

> 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.

[iamnothere]

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.

[jesseendahl]

> I don’t see hardware tokens (like Yubikey) in the list. Those are the only ones that provide a true second factor

passkeys are not meant to be a second factor; they are meant to replace the password as a primary factor.

>to protect against the theft or compromise of your primary device.

I love Yubikeys, but 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 have no idea if Yubico is involved with DBSC, but I would hope that they are, because it would help them make Yubikeys live up to the security guarantees that I personally feel are heavily implied by their marketing.

[otabdeveloper4]

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.

[NetMageSCW]

How well does that Yubikey work with an iPhone?

[sandeepkd]

Works just fine, you have to get the one with NFC

[bugcheck7b]

You can also plug them in to the USB-C port, works just fine.

[akdev1l]

Some functionality is not supported via USB-C. Namely HMAC Challenge does not work via usb-c but will work via lighting port.

[iamnothere]

Works great, they even have ones with USB on one side and Lightning on the other for older iPhones.

[thyristan]

iPhones are a lost cause.

[bdamm]

Passkeys on my iPhone works awesome.

Too bad for Yubikey. I don't need them any more.

[jesseendahl]

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/

[sandeepkd]

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.

[pishpash]

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.

[jallmann]

That leads to the cross-device usability issues from the original post. Even for an experienced engineer, it's a headache to manage multiple devices across multiple sites.

With the "cloud password manager" angle there is some hope of being user friendly, although we're certainly not there yet for most folks.

[Someone1234]

Then most of us would never use it. That means either:

- Only one specific device can ever login (bad).

- It doesn't limit login to one specific device, therefore it does nothing.

Linking Passkeys to a physical device was always DoA. At least not without a way to enroll every device you own, and strong recovery strategies. But considering how inconsistent every company's Passkey implementation is (inc. many that only allow ONE TOTAL!), it is DoA.

[thewebguyd]

> Only one specific device can ever login

That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys"

> It doesn't limit login to one specific device, therefore it does nothing.

It's not nothing. It provides an attestation that you the user are in physical possession of the device, and have passed the challenge to release the key form the TPM (biometrics, pin, something like a yubikey).

Giving your private key to a cloud password vault makes it phishable again (via an attacker getting acsess to your vault, just like with passwords). The private keys are supposed to be non-exportable, and the cloud password managers defeat that as well.

[sib]

>> Only one specific device can ever login

> That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys"

Unfortunately, given the laziness, incompetence, and cost-consciousness of organizations like traditional financial institutions, telcos, governments, etc., many of them have & will end up with that implementation.

[tialaramex]

> That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys"

In fact WebAuthn is explicit that you should allow multiple tokens. But every time I see an HN thread it has people who insist this doesn't work or at least isn't common. When asked for examples, if they give any answers...

1. Most often these are sites where you can't use this technology at all. They'll have TOTP or something and apparently "I don't know anything about this" == "I know everything there is to know about this topic" in the increasingly LLM-crazy world we inhabit.

2. Usually otherwise it's AWS. Which is pretty annoying, but it's one site. I have like a couple of dozen places where I use WebAuthn and in all of those two (or three, or in a few cases four) tokens are enrolled. I don't have an AWS account, my employer is a Microsoft-only shop in this respect.

[pishpash]

Why? The "one device" can be something portable like a Yubikey-like USB key, or for that matter, a smart phone, because people are already forced to use phones to do authentication codes, so it is kind of assumed a phone is always with you. In fact there is an existing workflow for this, where you use the phone to scan a QR code and pass the challenge back.

[Zak]

Then I wouldn't use it, and I would probably stop using services that tried to push me in to it.

I use multiple devices and I want to log in to things using only my master password. I also want to be able to back up my credentials to local encrypted storage so I can restore them if my password manager service provider stops operating or becomes untenable.

[malfist]

This is not much simpler than they think it is.

> But you're not going to lose it, because you use a password manager, and the passkey will be stored there and synchronized to all of your other 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.

It doesn't help that all modern browsers eagerly try to step in and offer their implementation of passkeys for logins, and they're not featured enough to support the type of shared access or synced access many people would expect from a password manager. How useful is your firefox passwords on an iphone? Or Mac OS's keychain I use as a daily driver on my windows gaming desktop?

> Major password managers don’t even allow you to export your passkeys to a file that you can read/backup yourself

This is wrong. Every single major password manager supports export. Lastpass, 1password and bitwarden all do that.

> It's past time to move off of LastPass. LastPass lost all of your passwords again last month

That just isn't true. Last month, their third party customer support portal was breached. That did not involve passwords.

[dfabulich]

> 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.

[Ajedi32]

> 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.

[porridgeraisin]

But this is well established behaviour in the real world. That the passkey design doesn't take this into account only proves even more that it was designed in a vacuum.

[Ajedi32]

The passkey design does take this into account, it's only the implementations that don't.

[s3p]

>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.

[izacus]

> 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.

[__MatrixMan__]

> Instead, the password managers each have their own finicky app-to-app mechanism for transferring passkeys from one password manager to another. (I think all the password managers kinda like that lock in.)

It's a nice simplifying step to talk about password managers here, but in the majority of the cases this won't be handled by a password manager, but rather by the device operating system, and the device manufacturers really like that lock in.

They're also in an especially good position to abuse it, because they now know every service that you authenticate and the webauthn "attestation object" field lets them set up a side channel with those services such that they can sell additional information about you.

Some people will tell you that the attestation object is not used in the consumer passkey system, so there's no way for this abuse to occur, but since it's usually going to be the device manufacturer who controls the password-manager-like component here, and they're the ones who stand to profit most from this kind of abuse, I think we need stronger guarantees than "the spec says you shouldn't do this unless the user is your employee and you paid for their device".

Until they fix this, I'm sticking with my mess of TOTP authenticators and yubikeys.

[dfabulich]

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.

[pseudalopex]

> 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.

The bad news is this could change.

[__MatrixMan__]

The risk is not that the site would insist on attestation, it's that Apple would volunteer it. They could pass an ID through that channel, use it to strike up a separate conversation which makes them some money, informs Palantir about what protests you've been to, and the service in the middle gets a finder's fee.

If we want this to be usable by consumers we need to prevent this kind of thing, not thank Apple for their restraint.

[lelandbatey]

> This makes it impossible to copy and paste your passkey to the wrong person (someone trying to trick you).

It also, unfortunately, means it's not possible (via most passkey implementations) to back those passkeys up to paper. Which is quite unfortunate: backing up to paper is one of the most stable and human accessible ways of ensuring redundancy and continuity, an inevitable but also oft-ignored part of credential management.

Security folks would like to pretend "solving continuity" isn't a problem, or is a problem that doesn't need to be accessible.

[no-name-here]

> 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.

[syntheticnature]

Yes, this is extremely common, both as a continuity means and/or as a localized password manager. Know someone who uses a Rolodex for hers, which is funny and yet it works.

Doesn't work well in office environments, but at home the local threat model is largely fine with this.

[Telaneo]

Yes. Old people constantly do it, since they have no hope of remembering 15 passwords. Sometimes, they can barely remember 1 (one).

I've written down one: the master password for my Keepass database, along with instructions on how to get to and open that file. It's in a 'open if I'm no longer alive' envelope.

[cwillu]

It is absolutely a thing people do. Google even offers a convenient printout as a way to provide account recovery.

[JohnFen]

> Is writing down passwords something people do?

Yes, it's pretty common.

[malfist]

The passphrase to my bitwarden database is in my will. And a bitlocker decryption key is right beside it.

[7402]

Yes:

  Paranoid password printing with a Raspberry Pi
  https://7402.org/blog/2020/paranoid-password-printing-pi.html

[tekla]

It is what the vast majority of people do.

[NetMageSCW]

I doubt if that’s true since the vast majority of people no longer have printers. Not even the vast majority of online people.

[Telaneo]

Both pens and pencils exist.

[tekla]

I was not aware writing down a password required printers.

[aetch]

Having to rely on a possibly proprietary password manager app to use a passkey sounds like a nightmare. A lot could go wrong with the password manager like becoming incompatible, becoming subscription based, lack of updates for bugs, etc. I don’t passkeys for the same reason as the original commenter.

[kodt]

I looked up the June 2026 breach and there is no mention of passwords being stolen. Only some PII (Phone, name, email, address) through a third party.

[xboxnolifes]

So to login using a public PC, you need either USB access (and carry around your password manager) or you need to install the password manager on the PC to log into a website?

[realityking]

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

[archargelod]

Discord has an option to login with qr code. And it's very often used maliciously to steal accounts.

[mwwaters]

The passkey method uses Bluetooth to ensure proximity.

[TeMPOraL]

> Major password managers don’t even allow you to export your passkeys to a file that you can read/backup yourself

That's a red flag to me. It's enough that phone backup systems go out of their way to prevent you from accessing your own data, too, for unexplained "sekhurity" reasons.

> P.S. It's past time to move off of LastPass. LastPass lost all of your passwords again last month, just like they did in 2022. The most similar service is 1Password. If you like LastPass, you'll like 1Password about the same, but 1Password hasn't had multiple terrible security breaches.

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.

For core security tool class, that doesn't inspire confidence.

[dfabulich]

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.

[threecheese]

I’ve relied on iCloud as well, but just learned that it allows apps to store persistent data. This data is synced between all devices, and there’s no way for you to view or manage/delete it. Even determining which apps do this requires you to enumerate the apps entitlements, which is nontrivial. And so an app you install on your iPhone can have configuration or credentials persist to each iCloud-connected device, and you have no control over it. This is certainly convenient, if that’s the behavior you want; if not, there’s no visibility or control.

[alwa]

Is this different from the per-app enumeration in Account —> iCloud —> Storage? That provides a means to delete per app

[TeMPOraL]

Does it provide a way to edit or at least view it?

[floathub]

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.

[unscaled]

It doesn't even have to be something as bare-bones as pass. You can have a full-fledged password manager that is open-source and local-first. KeepassXC (and the OG Keepass) were always OSS and local-first. The original version of Keepass 1.0 for Windows was released long before Lastpass or 1Password[1], so we had an open-source local-first password manager before we had commercial cloud-based managers.

[1] To be more accurate, although it was always proprietary, 1Password was also local-only at first, with syncing only supported by putting it on something like Dropbox. They only added native cloud syncing later and eventually made it cloud-first.

[saratogacx]

> 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

[ryandrake]

> 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

[pibaker]

> This is much, much simpler than you think it is. Passkeys are just passwords that require a password manager

Cool. So can I write down my passkey on a piece of paper and put it in a safe?

> you'll reset your passkey the same way you reset your password, probably with a "forgot my password" email

Cool. But what if I lose the passkey to my email account?

> and the passkey will be stored there and synchronized to all of your other devices

Cool. Surely backups and synchronization never fails.

> The weird part is that password managers provide no way for you to copy and paste your passkeys

Uh oh. So you are saying passkeys are not like passwords? Last time I checked, every password manager lets me copy and paste my passwords just in case.

> To present a passkey, you have to use a password manager

Uh oh. So you are saying passkeys are not like passwords, like at all? Last time I checked, I can just type in my password using a keyboard on all websites I visit.

> This makes it impossible to copy and paste your passkey to the wrong person

Uh oh. So it means I can't just give my password to a family member sitting in the opposite side of the room? Sorry mom, corporate has decided that you are trying to trick me.

> Major password managers don’t even allow you to export your passkeys to a file that you can read/backup yourself

Uh oh. So is there a registry of Major League Password Managers that are guaranteed to implement Corporate Strength Cybersecurity Measurements? Will I be blocked by services if I happen to have landed on a minor password manager?

[preisschild]

> This is much, much simpler than you think it is. Passkeys are just passwords that require a password manager.

This is not true. There are device bound passkeys where the private key is stored in a HSM (TPM2.0, Android SE, or apple SE) instead of a hosted service (iCloud, Bitwarden.com). You can just add multiple Passkeys to a single site to have another backup device should your other one be unavailable.

[EvanAnderson]

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.

[pseudalopex]

> 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.

Yes.

> even if it was just within only the purview of a single manufacturer

> Heck, make it a value-added service that the manufacturer has to initiate and tie it to some real-world identity verification.

No.

[pseudalopex]

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.

[dwheeler]

Wait a sec. My understanding is that passkeys are public/private keypairs. Public is in server, so even breaking into a server does not reveal the private key.

The big risk with passkeys is storing the passkey where it will be held hostage. Don't store it in most single-ecosystem devices like Apple. Bitwarden can export, and I think 1Password can as well.

[deltoidmaximus]

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.

[gblargg]

> This is much, much simpler than you think it is. Passkeys are just passwords that require a password manager. If you lose your passkey, you'll reset your passkey the same way you reset your password, probably with a "forgot my password" email.

This is why I don't bother with these if they have a weaker workaround, which will be open to remote hacking.

[jhhh]

I am not happy about a trade-off which involves me having to cede control of my digital identity to 'providers' who will not give me access to it, in exchange for maybe not getting phished. If passwords continue to exist for a long time then this entire exercise is pointless as they can still get phished. If passwords go away and we can only use passkeys then you're only entry point to any kind of digital account is through one of the designated providers. If you don't have a provider that spans all of your platforms then you're screwed or have to manage multiple pass keys which is also stupid. Even the current crop of online providers as you illustrated in your post are unsecure and unreliable. No thanks.

[pseudalopex]

> Passkeys are just passwords that require a password manager.

Passkeys are passwords which allow a relying party to control what password manager you can use.[1]

[1] https://news.ycombinator.com/item?id=46305566

[giantg2]

This seems like a consolidation of risk to rely on a password manager, especially software defined, especially if it relies on a password. I like the hardware token idea (yubikey). But even that seems cumbersome because you should be making a copy for safe keeping. And how do you securely do password recovery if most security questions can be obtained via osint or the reset links are sent to a site you are similarly locked out of is compromised?

[throwaway-blaze]

I love that you wrote 6 paragraphs and linked to a medium post all without actually answering the question posed by the comment you replied to.

[dfabulich]

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.

[pseudalopex]

> 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.

Until a relying party uses attestation to decide this for you.

[robertlagrant]

> The weird part is that password managers provide no way for you to copy and paste your passkeys.

The main feature of passkeys is that they can't be pasted into a website they shouldn't be pasted in to. That means you can't copy them, by design.

[Telaneo]

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

[robertlagrant]

> 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]

Yes - the kerfuffle is broadly I think the fact that it negates the main advantage of passkeys: people can't be tricked into pasting them into a fake login screen.

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

I agree - they're explained in a really odd way, and I think that's because they're a technology with multiple interaction patterns, rather than a single thing like a password. E.g. your fingerprint on your Mac is implemented as a passkey, or clicking on a browser passkey is also a passkey, or using a password manager via a different UI is also a passkey, or touching a Yubikey is also a passkey. The underlying mechanism (passkey) probably has been surfaced more than it should've been.

[Melatonic]

Oldschool KeePass ftw

[boobsbr]

> Passkeys are just passwords that require a password manager.

How come I log into my corporate Windows laptop by typing a passkey instead of a user/pass combo?