I do not know how to use a Passkey in a way that won’t impede how I log in to systems. I’ve been in tech for 26 years, and I understand the Public/private key behind what a Passkey is. Here’s what I don’t understand:
I access a website through at least four different devices (my iPad, iPhone, Windows Desktop computer, and MacBook Pro) and three different browsers on each device (Brave, Firefox, Safari) , and I use LastPass. If I accidentally set up a passkey on my phone (let’s say I use Safari one day instead of my go-to, Brave), can I still log in without that passkey on other devices? Is there a way to ensure that passkey can be used on other devices? Can I add another passkey on another device? How many passkeys can I set up for a particular site/app? I have at least 6 different combination of browser/devices in use.
I don’t want to use Passkeys because I don’t the answers to those questions, and I don’t know whether each website/app that has set up Passkeys has decided the answers to those questions in the same way as the others. For now, I’m going to stick with LastPass and use Passwords; because no matter whether I lose my device or not or whether I’m on my own devices or not, I can be sure I’ll be able to get into a site/app.
Edit: One final consideration, my spouse and I share user/name passwords for some things (notably Pandora and our Amazon Prime account) since they don’t handle things like family logins well; how do both my wife and I use amazon or Pandora with passkeys? Do we each set up passkeys? How do I get her Pass if that’s not an option?
A potentially good idea got corrupted by vendors, password managers, browsers, etc trying to assert control. I'm also an engineer and I find the UI around passkeys entirely unclear, but it doesn't have to be that way. It seems like everyone wants to be _the_ password manager for all your passkeys. They don't want to make it easy to understand that is what they are doing though, they just happily offer to "handle it for you".
My non-technical friends are extremely confused by passkeys and if they should use them and how to use them and I honestly don't have very good answers. It is a mess. I don't believe an inherit mess, but one created by the companies and projects trying to take advantage of the new system.
> It seems like everyone wants to be _the_ password manager for all your passkeys.
Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound, the private key held in the TPM or secure enclave or whatever other security chip, mathematically non-exportable. Storing all your private keys in a cloud vault still leaves you exposed to potential credential theft if your vault gets compromised.
Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).
> Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).
I have just shy of 2000 site credentials in Keepass. Let's assume that they were all Passkeys.
1) When I buy a new device, how do I create 2000 new Passkeys for that device?
2) Can I still do that if I don't have access to the old device? Maybe it was destroyed, stolen, or lost.
3) How about if the new device is from a different vendor than the original device? E.g. switching from Apple to Android?
Nothing in the post you're replying to is about "is 2000 passkeys storable", it's about "if I have 2000 passkeys and I need to move between an Apple device and an Android device, do I need to establish a second set of 2000 passkeys"?
> Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound
If you watch the original Apple WWDC talk presenting passkeys, you will find that they were always intended to sync, at least for the consumer use-case.
What you are describing is how the WebAuthn standard had been implemented by Yubico and Google up until the point of the introduction of “passkeys” by Apple.
The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices.
Right; but THAT idea is consumer hostile by design.
So your account is now tied to a physical device; great, but the device is dead, or you own a dozen devices, now what? Each vendor has their own idea about what THIS means. Heck I have a couple that allow, max, a single Passkey at a time.
> Right; but THAT idea is consumer hostile by design.
No argument from me there, just stating what the design actually calls for.
It was never meant to be consumer friendly in the first place, it's an enterprise standard. It was just shoehorned onto consumers with the synced credential compromise to make it easier, instead of coming up with something better, and then just calling it a "Passkey" which now has dual meaning.
But the real solve is difficult. If a system requires a consumer user to manage, remember, or safely store something extra, it will fail.
The FIDO set of standards (UAF, U2F which predated passwords and passkeys) haven't even started as enterprise standards. There are multiple origins for what became FIDO, but the main ones I know are:
1. PayPal was looking for a physical authentication solution for their users, Michael Barrett was their CISO at that point and he became the president of FIDO.
2. Google developed Gnubby (which was internal, and therefore enterprise) and they wanted to push a similar authentication to their end-users, supported directly on Chrome. They wanted this to become a standards, so donated the underpinnings of the Gnubby technology which became FIDO U2F.
I might be wrong but at least these are the two parts I know.
And while the original FIDO could be called dual-use, Webauthn and especially Passkeys were developed to be first and foremost a customer-facing standard.
It doesn't mean they are not confusing, but they are clearly designed with end users in mind.
> Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).
This is a misconception. A particular service can choose to enforce those class of passkeys, but most don't need that and shouldn't.
Passkeys are primarily meant to replace passwords and be hard (but not necessarily impossible) to exfiltrate.
The key difference is during normal usage you don't have to type the secret in anywhere, it's strictly asymmetric, so a unwitting user is far less likely to get fooled into accidentally leaking the actual credential.
Passkeys is basically a brand name for "discoverable credentials" (a Webauthn term). They do a little more than that technically, but in practice their purpose is what you said. Replace passwords. Or more accurately usernames and password pairs. This is in contrast from 2FA, but even before Apple started marketing Passkeys the FIDO standard supported the concept of Passwordless authentication, alongside 2FA.
Passkeys came together with multi-device syncing when Apple introduced them and IIRC it was pushed as their killer feature by Apple back then, but passkeys can also be completely device-bound. The marketing around this was all quite confusing, but it's a bit too late to fix now.
What we got, as far as the average consumer should be concerned, is that "passkey" is any authentication mechanism (not the actual credential) that can replace a password. And it's still confusing.
Stronger than "don't care about" (at least if I and some friends I've discussed this with count as normal people): this is actively what I don't want! I want control over my authentication and I don't want it bound to device, browser, OS, etc.
But the original FIDO2 standard wasn't made with consumers in mind in the first place, it was driven by enterprises that wanted high-assurance security. It works in that environment because, well, a big IT department controls it, can support the employees, and you can mandate and control its use.
It was just sort of haphazardly shoehorned onto general users/consumers, prematurely IMO, via synced credentials as a compromise instead of coming up with something better.
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.)
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.
>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.
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.
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.
> 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_.
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.
>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.
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 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.
> 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.
> 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.
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.
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.
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.
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.
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.)
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.
I went to my bank with all my ID and my bank card, talked to the teller and was told to call a support line. One of my parents went through the same thing.
I don't have a citation for you just recent experience, do you have a citation?
I help run a non-profit and the only time I have ever been able to get this kind of service is when I visit a bank that has in-person business services. Tellers do not have any ability to do any of this.
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.
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.
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.
> 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.
"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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
> 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?
> 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, 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.
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.
> 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.
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?
> 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.
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.
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.
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'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
> 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.
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.
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.
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?
> 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.
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.
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.
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.
> 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.
I get your problem, i don't really accept it as valid. Passkeys were always supposed to be fungible. You have one in your iPhone, a different one on your desktop. A third in your significant other's phone. All stored in the hardware tpm equivalent.
You can have 7 passkeys. You can have 14.
The real failure of passkeys (emphasis on the s!) is that people think they must only have one.
That's the real failure? I think the real failure is that people must have _more than one_. I thought so hard to add all my credentials to 1Password. Now people tell me I should use a Yubikey (or better two or three of them). What do you think, I'm going to register a couple of hundred accounts times three for something I already have (my password manager)?
The real advante in passkeys is in allowing me to log in into a service on a foreign device without typing [my password], which is (honestly) something now sane person should ever do.
Again, is this true for all major sites that support passkeys? And how do you set it up? My passwords are automatically synced between my devices, how to I achieve the same thing if I set up an account with a passkey?
In practice, because site owners know users are going to mess up having their passkeys on all devices, I've not seen any insist that a passkey _must_ be used, and you can always log in with your password (or worst case, email magic links) as a fallback.
However, this negates the primary stated objective of passkeys, removing the possibility of users being phished, so I'm not sure how long that will remain the case everywhere.
I've also encountered sites that have a login with passkey prompt that then turns around and asks for TOTP 2FA or email confirmation anyway, which to me seems to negate the primary customer benefit of passkeys...
> I've not seen any insist that a passkey _must_ be used, and you can always log in with your password (or worst case, email magic links) as a fallback.
Is "passkey" only supposed to mean devices that implement specifically U2F, WebAuthn, etc.? I would have thought TOTP and challenge-response hardware tokens to count, including cellphones with apps that implement such.
As to
> No major bank revokes your password when you setup a passkey, either.
If we're talking about requiring 2FA via TOTP or challenge-response hardware tokens or banking apps implementing such, that depends on the country. It's the status-quo in some places. Some banks even put the input field for the token output as a third input in the login form on their website because all customers have them. The rest separate their login form in multiple steps, but they likely require it of all customers too.
Such a generic word. I imagine there are tons of CLI utilities out there with a --passkey option that refer to simply files with a key inside. Kind of crazy that it's being used to mean specifically devices that implement a specific protocol.
Kind of feels like "crypto is a type of currency and not all cryptography".
This is the main reason I've avoided passkeys. I have these exact questions and there's no a clear explanation given for these. I don't want to lose access to important accounts.
If you use something like 1Password it's very easy. It stores your Passkey and it syncs cross device. It's another thing but once it's set up it's less of a pain than using authenticator apps or having to find some random iPad that Google popped up an approval prompt on.
This is the #1 most common misconception I see about passkeys. They do not make it more likely that you will lose access to your accounts. They actually have nothing to do with account recovery. They are just a stronger primary factor than a password.
Most providers continue to offer email-based recovery in the case that the end-user loses access to their primary factor, regardless of whether the primary factor is a password or a passkey.
And email based account recovery does not make the security advantages of passkeys disappear, which are:
- credential that's guaranteed to be unique
- credential that's guaranteed to be strong
- credential that cannot be phished (due to cryptographic binding to the domain at the time of credential creation)
- changes the incentives for compromising servers (there's nothing worth stealing from the server -- only public keys)
- if/when an app/website transitions to retiring password-based authN, then it will entirely eliminates credential stuffing attacks
And if the account recovery scenario in question is your Gmail or Apple account, then you would need to go through their account recovery flows regardless of whether you were using a password or a passkey:
I can safely write down a password on a piece of paper and keep it somewhere phyisically safe.
Passkeys and 2FA are a usability nightmare if you need to recover, or all the security vanishes if you put usable recovery mechanisms for the passkey or the second factor.
>Passkeys and 2FA are a usability nightmare if you need to recover, or all the security vanishes if you put usable recovery mechanisms for the passkey or the second factor.
Most providers continue to offer email-based recovery in the case that the end-user loses access to their primary factor, regardless of whether the primary factor is a password or a passkey.
And email based account recovery does not make the security advantages of passkeys disappear, which are:
- credential that's guaranteed to be unique
- credential that's guaranteed to be strong
- credential that cannot be phished (due to cryptographic binding to the domain at the time of credential creation)
- changes the incentives for compromising servers (they're nothing worth stealing from the server -- only public keys)
- if/when an app/website transitions to retiring password-based authN, then it will entirely eliminates credential stuffing attacks
password managers do the backup for you based on how you set them up (eg. to your google drive, or to a simple SFTP/FTPS/S3 URI)
those that don't have this built-in (eg. KeePassXC) recommend using Dropbox or some external sync mechanism
but the keys are stored in a file, which you can back up.
> all the security vanishes if you put usable recovery mechanisms for the passkey or the second factor
no, not at all. it still gives you better UX, because when you use the passkey you know it's the site you want to log in to. (because there's mutual authentication.)
That's all I want to know. How do I restore from a backup? Specifically, a backup that I make to a medium I control, like a piece of paper or a burned CD-R in a safe deposit box. If I could get a good answer to that, I could be onboard. But from the conversations that I am getting here, it looks like only certain managers allow it, and with device attestation, they could be banned at any moment by any website with no recourse.
Now that I think about it, you are right. But if they could ban my use of written passwords as easily as banning my use of a particular passkey device, why go through all the extra hoops to just be as vulnerable as before? This seems like a whole lot of extra work to do that gains me nothing.
How? Where are they stored? Which password protects them? How do I back them up? How do you move them to another device? Can I print them out on paper as a last resort measure?
it depends on which password manager you are using. if you use Google's then it gets backed up to your Google account.
BitWarden, KeePassXC, and probably a bunch of other password managers have very thorough support for import-export, automatic/periodic backup, sync/merge, etc.
Sounds like something security services would love people to use. Instead of using wrench to extract the password - and distressed person may lose memory, they can just locate the passkey.
Nobody is safe from a nation-state "attack" they'll just go threaten your providers to give up your data. Passwords written on paper are probably safer than a centralized password manager for almost every circumstance other than a government coming after you.
My issue is that they're touted to the consumer as secure, and they're not really doing much more than a complex password.
How do you generate a new key if you need one? Same process as a password reset. Does it prevent session stealers? Not at all.
Its "benefit" is grandma can't read it to an attacker. OK, well can grandma click a link and have a session stealer bork her life instead? Yeah, and attackers know that and just shift methods. Session stealing isn't a sophisticated attack, and so all that's being done is shaving a cost on PW resets in the interest of shareholder value, at the cost of security theater and locking up your keys in a single domain that holds control over our access to everything.
There is security value. A passkey will not work anywhere except the actual website. Fake look a like sites can't get the credentials. Evidently they can trick you into authorizing their device.
That's also how any good password manager works. You'd have to manually copy-paste the password to get around the same-site fill restriction (whether it's autofill or manual fill).
This is one of the key security features of passkeys. I did a little searching and the work around is to do a standard fake website that prompts for your standard credentials. That should be a fairly simple fix. Require access from a new device to be authorized from another source with an explanation that they will never request this info.
I think the intended workflow is you login with your phone and that device is now the authority that allows other devices to issue their own passkeys.
In my opinion it's a bad plan, because it elevates certain devices to privileged status, if you lose your phone you are hosed.
Passkeys should be allowed to be synced between devices and stored on password managers in the cloud. I am making my own password manager for my personal use, but have not delved into passkeys.
> Passkeys should be allowed to be synced between devices and stored on password managers in the cloud. I am making my own password manager for my personal use, but have not delved into passkeys.
They are, that’s exactly how I use all my passkeys with Bitwarden. They sync to any device I have Bitwarden installed on when added on one device.
Yeah that's all hackery I think, if you read at the specs there is always a device involved, bitwarden and company just pretend to be a device or have an extension that just ignores the spec.
Listening to Yubikey and OnePassword talk about this, they actually say "One Person, One Device". Which really speaks to their failure to understand their users.
Because the original FIDO/WebAuthn standard was built for device bound credentials. They imagined unique keypairs tied strictly to a specific piece of hardware. Synced passkeys were a compromise, mostly driven by Apple and Google, because per-device credentials are too much friction for general use. It's not that they failed to understand users, it's that they incorrectly assumed the level of inconvenience people are willing to tolerate to be textbook secure (the answer is almost zero inconvenience).
The device bound model also completely falls apart in the enterprise, fails to address shared devices and shift workers where employees share the same PC under the same OS profile, now you're back to needing good old fashioned SSO w/ physical MFA (Yubikey) to attest who the user is in addition to attesting the device itself.
Before synced passkeys, the actual standard is a unique key pair per device. The key pair on my phone shouldn't be synced to my laptop, my laptop should generate it's own key pair.
Even then, unless you use one for work, where work can issue you a new one if you lose it, you're going to need (at least) two Yubikeys if you want to go that route, because not having a backup is a bad idea.
>If I accidentally set up a passkey on my phone (let’s say I use Safari one day instead of my go-to, Brave), can I still log in without that passkey on other devices?
Yes, but you can also add the passkey to your password manager so it's available on all your devices.
>Can I add another passkey on another device?
Yes.
>How many passkeys can I set up for a particular site/app?
I haven't really seen a specified limit on any sites, but also if you're using a password manager it's only 1 passkey for all your devices anyways.
> For now, I’m going to stick with LastPass and use Passwords; because no matter whether I lose my device or not or whether I’m on my own devices or not, I can be sure I’ll be able to get into a site/app.
Your passkeys would be in LastPass as well like your passwords, so arguably the same result regardless of which you use.
>Edit: One final consideration, my spouse and I share user/name passwords for some things (notably Pandora and our Amazon Prime account) since they don’t handle things like family logins well; how do both my wife and I use amazon or Pandora with passkeys? Do we each set up passkeys? How do I get her Pass if that’s not an option?
If it was me I'd add a second passkey to my password manager for your wife under a new entry, and share that entry to her lastpass account.
Or if she's not on lastpass, you could just copy the data from the passkey over to whatever she does use.
> Edit: One final consideration, my spouse and I share user/name passwords for some things (notably Pandora and our Amazon Prime account) since they don’t handle things like family logins well; how do both my wife and I use amazon or Pandora with passkeys? Do we each set up passkeys? How do I get her Pass if that’s not an option?
Lets say it is a android phone. Open amazon app. login in the usual user/password + 2FA (like with QRcode or phone). create passkey. done. This passkey would have been now synced to your google account.
Take next spouse phone. Open amazon website or app. try login it will try for passkey but cannot find it. so
- login in the usual user/password + 2FA (like with QRcode or phone). create passkey. done
- Now this passkey would have synced to spouse google account.
In future, assuming you have apple or windows laptop. assume you have signed into Google (chrome). Now go to amazon. It will ask - shall I sign in with passkey. Yes, give your macos fingerprint or windows hello or password of that laptop. login Done magically. You dont even need to remember username or password.
Assuming you both have iPhones. You can sync the passkey to icloud account. And for every new iDevice it will be available.
The main bottleneck of passkey would be that all 3rd party sites will have another non-passkey way as backup to login. I have never seen a website that would say - remove all other methods and keep only passkey.
In a way passkey is 99% convenience. If a hacker would some how get your sms and password they can by-pass.
Thanks. One glaring issue I see is that right now police can’t ask you for your password in the USA (a violation of the right against self-incrimination). They can however get a search warrant for your device and your biometrics, and wouldn’t need your password if they can gain access through your pass key.
If you save it via Passwords app, it'll be iOS / macOS mainly, but you can unlock with any Apple device that supports Passkey / Passwords app (so likely modern + reasonably updated) the easiest. If you want it to work "everywhere" then you CAN use your iOS / MacOS Passkey, it will show you a QR code, some places poorly support this, I believe both devices need bluetooth, and then it will authenticate it.
Linux is the only oddball here, I had issues getting this flow to work.
If the UX for Passkey improves, I will go all-in on it, I'm at the point I'd love to just completely block passwords from accessing my account, unless I explicitly enable it temporarily by logging on via passkey, I wish some sites would let me lock my account to this level, it would be better. Passwords feel like they just wind up all over the web.
Weirdly enough you can store multiple passkeys for a given domain, which can get confusing in some cases if they dont have normal names tied to them.
Edit: Originally I thought Passwords from Apple was iOS / macOS only, but its not! So I have been editing my original message, sorry for the confusion, I had forgotten that I can login on Windows with my Passkeys from Apple's ecosystem.
As another poster noted, you can transfer them out of Apple's ecosystem too!
Firefox just didn't support it cleanly, I think Chrome did, I don't remember. Apparently it's just due to Linux not having a native passkey implementation. Dang.
Edit:
Apparently BitWarden should work, but my particular passkey was not on there.
> Apparently it's just due to Linux not having a native passkey implementation.
Excuse me? The infrastructure for "an apps is trying to login with a private/public key pair, and right now it needs the private key to encrypt some part of the transaction" has existed on Linux since it began.
The problem, as best as I can understand it, is that some/all browsers are not treating passkeys as an extension of the key system that began with ssh(1), even though technically speaking, they are.
Unpopular opinion but correct the whole thing has been designed to lock you to devices they make and have themselves be the arbiter of your authentication.
If that wasn't the intent they could have make the thing work like ssh keys, encrypted at rest, you can take them wherever you want.
It is not Apple's job to implement Passkey into Linux, that is up to the Linux community to build up and figure out, and then for Firefox to implement it on Linux. On the other hand, Chrome just works with it, so maybe Firefox either implements it for Linux in-house, or figures out an existing initiative they could invest resources towards and help to prop up so they can integrate against it on Linux.
My issue is not the lack of Linux support, my issue is the dependence on hardware components, that are distributed by a small group of incumbents, that is pretty much baked into the spec.
What they want is to lock your identity to your android and/or iphone devices.
Only to other proprietary systems within the FIDO Alliance that you don't own or control.
Additionally passkeys allow services to detect and ban specific password managers, so have fun when the only approved managers that works consistently across all services are Google/Apple/Microsoft. There is already a list of "bad" clients here https://passkeys.dev/docs/reference/known-issues/
I didn't realize this was supported, I'm kind of favoring Apple's Passwords app since you can lockdown your account and they are very on top of someone accessing anything of yours. Any time I power on an iPad I havent used for months they tell me a new device can read my texts type of thing, which is a nice paper trail.
I wouldn't favor an application that is locked to a big player account (Microsoft, Apple, Google) where a ToS violation for something unrelated may lock you out of all services, passwords/keys included.
> A Public Key Credential Source’s generating authenticator determines at creation time whether the public key credential source is allowed to be backed up. Backup eligibility is signaled in authenticator data’s flags along with the current backup state. Backup eligibility is a credential property and is permanent for a given public key credential source. A backup eligible public key credential source is referred to as a multi-device credential whereas one that is not backup eligible is referred to as a single-device credential. See also § 6.1.3 Credential Backup State.
I think the point is that Passkeys are not supposed to be as precious as passwords. You're supposed to have a brand new one for every device/application combination. So they are just login cookies at this point, and haven't even come close to replacing passwords because you need to know your password to get a new passkey every time you log in.
Now, is that the official stance? I don't know; but it's _absolutely_ what every current implementation suggests the companies deploying this stuff want.
You can make passkeys better. Like me, you can install a well-funded password manager (well-funded, because it needs the engineering effort behind it to keep up with the ever-changing passkey apis on every platform in the world; screw up and oos, can't log in today!). Then you have one passkey per remote service, and just have to make sure 1password is _always_ installed and perfectly integrated. Easy!
There are a couple of problems I have with that. 1) Many websites limit the number of passkeys I can link to my account. Some only allow 2 or 3. I have more devices than that. 2) If I am supposed to create a new passkey for every device, how do I login in the first place? Most websites currently fallback to password login which defeats the security benefit of using passkeys in the first place.
I currently only use passkeys for a few websites that have awkward password login workflows or do not autofill properly from my password manager. I just have a single passkey for each that is synced via Bitwarden. Currently, I see passkeys as using an electronic biometric lock on the front door while passwords are still regular locks on the backdoor. The biometric lock on the front door does not do much for security when the backdoor still exists and I have come across very few websites that support only allowing passkeys. And those that do still run into problem 2 listed above.
Yeah, I agree. My policy is much the same as yours: set a passkey only when a site makes logging in with a password such a PITA that the PITA of a passkey becomes the easier option. Google comes to mind. They seem to actively not want anyone to log in. At some point sites will start to 2FA you even with a passkey, but we don't seem to be there yet.
For me, it is "how many passkeys can I have for the same site?", and "how do I revoke them?"
Worse, I'm still using LastPass -- but migrating over to Chrome password storage as it syncs between phone and laptop. LastPass doesn't give you the option to not use it for passkeys. It might be the thing that causes me to finish the migration away from it.
I can't speak to all of your browser combinations, but most desktop browsers can present a QR code when logging in with a passkey. I keep my passkeys in a password manager synced between my phone and personal computers. On my work computer, where the password manager is not installed, I can still use passkeys by scanning the QR code with my iPhone's camera app.
It makes sense for a work device that is off network/domain, but then it is your primary/only means of interfacing with services. Then you can consolidate under a Windows Hello passkey or something else.
The second you have a second device to log in from they are useless. The second you want or need to share a credential (smart or not) they are more work than a password.
The passkey trend seems lead by platforms that want to make it easier to get or stay logged in, Netflix type companies that want to prevent account sharing, and those that value convenience (if one device) over security.
I find it abjectly terrifying. Like if I log into your site with a Passkey what happens if my device breaks? What if some big tech company decides to nuke my account for no good reason?
You can store your passkeys in Bitwarden or Keepass vault. Then you can use them through Bitwarden or Keepass apps on any other device. Been using passkeys like this for several years, and it works pretty seamlessly. With Keepass vault, I even have an offline copy as backup.
They are bigger. Not as easy to guess. More like pretty impossible. It's like not letting the user choose the password. That way they can't have a bad password.
> If I accidentally set up a passkey on my phone (let’s say I use Safari one day instead of my go-to, Brave), can I still log in without that passkey on other devices?
N=1 and I'm sure I'm holding it wrong, but I can only log in to ADP to request PTO from my personal laptop because I set up an iCloud passkey, work laptop does not allow access to iCloud keychain, and you can't request PTO from mobile.
Although that's more a failure of your workplace's security policy than of the Passkey itself. It makes sense that the passkey doesn't work if you can't access the place the passkey is stored.
The thing I find burdensome is managing all the keys in a secure way. I think I would want a hardware token to store the keys on, have separate keys for every site, need to back up my keys onto a second token in case the first one is lost, etc. It gets burdensome. At least with passwords you can store them in various ways that are not hardware or software dependent.
Answer to almost all of your questions is that it entirely depends on the service what kind of auth implementation they offer. I personally have completely adopted passkeys and use them with every service that allows it.
I use ProtonPass and have made it the default password store on every device and browser. This way all passkeys get stored in proton and I can login from any other personal device with proton setup.
Also from experience, most sites will implement it in every wrong way possible.
For example, all the major sites that allow the total of 1 active TotP authenticator app - trying to add one forces to delete the other. Which is fine while you have only one phone and aren't in the process of switching to another one.
With foresight you can get around this since you can reuse the TOTP seed values.
The annoying thing is so many services don't even support TOTP. They either want their own proprietary app, still insist on SMS, some of them even try to get you to use voice prints!
> These are all answerable questions, but getting those answers is confusing for most people.
It's the same answer when someone asks 'how am I supposed to have a different password for every site' and 'how am I supposed to remember a password of X+ characters.' Use a password manager. Pretty sure every major one supports passkeys by now.
Write it down on a sheet of paper and put the paper in a safe place. As a bonus, I can have multiple copies in multiple places. It is simple, easy, and I have been doing it all my life. I see no reason why it has to be more complicated than that.
Password managers are themselves cross-device footguns and I could easily write the same headline for them myself. I've been working in tech for 20 years now, and I don't use them.
ETA: Well I do use auto-fill in browsers/mobile, but funny thing about this, I have three running on my phone[0], they all activate at the same time, and they contain mostly non-overlapping set of credentials, and I got tired of trying to sync them together, so I just look up passwords manually one by one in each and use clipboard to transfer the credential once I find it.
And I had to stop using passkeys because they interact with this split-brain system in unpredictable ways.
--
[0] - Specifically: Google Password Manager / Google Autofill / whatever they call it, Samsung Pass / Samsung Wallet (they're sort of but not the same?), and auto-fill built into Firefox.
Password managers for passkeys have a huge problem when dealing with any kind of remote support or working on someone else's hardware - you can't just copy/paste or type in the passkey so you're forced to install the password manager on a family member's/stranger's/employer's PC or do what? I'm not even sure. At least SSH keys have forwarding when you ssh to a remote machine, how do you "forward" a passkey?
With Apple's Passwords app, you can create "groups" for passwords and passkeys and share them with people. Once shared, the passkey/password automatically fills as if it was that person's own.
I have a "Family" group in my Passwords app where I share passwords and passkeys with family members for exactly this purpose.
Don't think it's any more confusing than e.g. logging in with an email address and password, or logging in with email + code, etc. A website's auth is usually a black box that they don't explain, and the only reason people find passkeys confusing is because they've been conditioned to enter passwords instead.
I've taken up the strategy of telling any less-technical person who asks me about passkeys that they are the mark of the beast, intrinsically evil, and should be avoided at all costs, and I encourage all y'all to do the same.
Maybe, at some distant point in the past, there was a plan for a whole system of intercommunicating implementations of passkeys. That is no longer the case. The moment that they decided to include the information necessary to only allow the use of certain passkey vaults in the protocol, and then use that capability to threaten to lock out certain vaults that dared to let users actually be in control of THEIR OWN DAMN CREDENTIALS, it invalidated the entire project in my eyes. Passkeys cannot be trusted, they are designed to let entrenched powers hold your authentication hostage, and should under no circumstances be allowed to take root in the computing ecosystem.
I use ProtonPass and afaiu it just syncs the passkeys private part everywhere you need it. So it “just works”. This is better than just old fashioned credentials because the passkey only “triggers” on the correct domain, so they can’t be phished by other domains… Right?
Copying / syncing passkeys between password managers is still work in progress, but you can usually work around it by making multiple keys. For important websites, I recommend saving additional passkeys to Keychain, etc, as backup, assuming the website allows that. (It should, but some websites might not have a good implementation.)
Also, nothing says you have to delete passwords (or alternate means of logging in) if you already have them set up. Having multiple ways in will help prevent lockout.
Unfortunately probably implementation specific, but you don't always need to have multiple passkeys. There is cross device passkey login. I had this occur in the last couple weeks. Evidently I had created a passkey on my phone. Logging into that site on my PC, it identified that I had a passkey and allowed me to authenticate using my phone.
I’ve just been operating under the assumption passkeys are gonna lock me out unrecoverably in some way at some point, and have been avoiding them for anything important while allowing them for low-value accounts so they’ll stop nagging me.
I hate that I can’t just put a value in a plain text file somewhere (encrypted, let’s say, to preempt the inevitable and low-value response) and rely on that to work when I need it on any device and interface that can accept keyboard input.
I avoid using them altogether for the same reason. I won't use them for low value accounts because it signals that I think they might be acceptable to eventually require for high value ones. And of course low value accounts have no value so I don't even care about phishing on most of those.
Haha, this thread has prompted me to follow some of the discussion about stupid bullshit like requiring "user is present" attestation and banning passkey programs (LOL wut?) if they lie about it, or resistance to allowing exports and portability.
I'm now on team "I am outright anti-passkeys and hope they fail and everyone pushing them cries a whole lot about it and never gets over it".
I recognize the point of your post is more about the lack of clarity and details around passkeys. That's real, and I don't really have an answer for that - other than, I think maybe the quest for making them simple and "just work" has maybe made them nebulous enough that we've wound up in the current situation where a lot of even technically savvy people don't really understand them. But I feel like answering your questions might sort of help explain why that's the case, so I'm going to take a stab at it:
> If I accidentally set up a passkey on my phone (let’s say I use Safari one day instead of my go-to, Brave), can I still log in without that passkey on other devices?
Assuming you have LastPass set up to be an iOS password manager, and it fully supports iOS' passkey implementation: when you create a passkey in Safari, it will ask you if you want to store it in LastPass or in the iOS Passwords app (previously known as iCloud Keychain). If you say LastPass, then it's up to them, but I assume it'll sync to all your devices - it's how 1Password works. If you were to accidentally say Apple Passwords, it'll sync to all your Apple devices automatically, and you can either use Apple's password browser extension on Windows, or you can use the "another device flow" I'm about to detail.
> Is there a way to ensure that passkey can be used on other devices?
As mentioned above, passkeys are intended to sync via your password manager of choice as the primary use case. If for any reason you don't have that passkey synced to that device, _and that passkey is on a mobile device with a camera_, most browsers will give you the option to scan a QR code with your phone. This kicks off a flow that will authenticate you via your phone's biometrics or passkey, then use Bluetooth to first ensure device proximity and then handle the authentication exchange. In the case of iOS, this includes any passkey-supporting password manager, so the passkey itself can be in 1Password; it doesn't have to be in the iOS password system for this to work.
When I first read the above, my hackles were raised given how well Bluetooth operates at times; but every time I've used it so far, it's been fast and flawless. Still, I can see a lot of scenarios where this might not work - e.g., the first one I thought of was a public computer at a library where Bluetooth might be locked down; corporate computers or remote servers could also be troublesome. As far as I know, passkeys don't yet have answers to those scenarios; other than to just use your password + 2FA as you would without a passkey.
As far as I know, both of the above apply to every passkey-consuming site.
> Can I add another passkey on another device? How many passkeys can I set up for a particular site/app?
This touches on your last paragraph, where it indeed could change based on the website. In my experience, every website where passkeys are fully supported - e.g., not ones that are using passkeys as a substitute for FIDO/U2F keys - has let me add multiple passkeys and have not _appeared_ to have a limit. I typically will create a passkey in both 1Password and Apple Passwords just to have a backup, and I can't recall any cases where that's been a problem. Still, I can't say for sure that isn't a problem on any website.
I went all in on trying passkeys when they started to be an option, and I don't have any notable regrets. For me, passkeys have generally worked well when the site is designed to use them well; and at no point have they been a _major_ hindrance. That isn't to say there are _no_ annoyances, though:
- Most websites that support passkeys tend to use them as a replacement for both the password _and_ 2FA, which makes them more convenient. However, a few - Amazon being the most notable I can recall - only use them as a second factor, which just makes them feel a little useless.
- A passkey can _also_ be used as the proof of identity, meaning you can log in in one fell swoop and don't need to enter a username or email address, which is IMO the best showcase for passkeys. Like above, this makes websites that ask you to enter an email address before letting you use a passkey also feel annoying.
- Most web browsers I've used support the QR + Bluetooth flow I mentioned above (otherwise known as Hybrid Transport or caBLE) without issue; Linux has been the odd duck out. Firefox doesn't seem to support it at all on Linux, and Chrome-based browsers do but sometimes are missing what they need and in that case don't show it as an option. Since I sync just about every passkey with 1Password this typically isn't a problem; the exception is the passkey for Apple Accounts, which Apple creates automatically, and (AFAIK) doesn't allow you to enroll your own. Apple Accounts are the only service I've found that does this, though.
- Some websites seem to only offer passkeys as an option if you're on a mobile device, or at least did so at the time of enrolling. eBay and PayPal I think are the two that jump out at me as having done this. Why they did it this way instead of simply detecting if the browser supported passkeys, I have no idea.
All of the above issues have gone down over time, so it's generally been a net decrease in friction over time. And, at least as far as I can recall, passwords themselves continue to be an option in every instance I've enrolled a passkey. So if you like your passwords, generally speaking, you can keep them :P
> passkeys are intended to sync via your password manager of choice as the primary use case.
The sync was actually a compromise to the standard. The idea was unique, device-bound credentials. One person, one device. The private key/passkey on your phone should not be the same one on your laptop, or your tablet, etc. Each device was supposed to have it' own unique credential.
Allowing sync is a security downgrade to the standard, in terms of threat-model guarantees. Pure WebAuthn credentials should be sealed in hardware (TPM or Secure Enclave or equivalent) and be mathematically non-exportable which guarantees zero remote blast radius, an attacker must physically posses the device.
Allowing sync and storing passkeys in a password manager reintroduces cloud account compromise risk and recovery flow hijacks. You lose non-repudiation.
Still more secure than passphrase + TOTP, but doesn't eliminate account takeover attacks against your cloud credential vault, which purely hardware based, per-device credentials do.
I don't get it. How does every device combo having a unique key pair help with security? They can all log in, right? So all you need is to compromise their session and you're in, whether they share the same passkey or not.
And if you're compromised in such a way that an attacker could steal your password then wouldn't they be able to just hijack your session instead?
Passkeys protect against credential theft, not session hijacking, two different parts of the stack. Passkey's only concern is initial authentication, it was never meant to provide any sort of protection against session theft. RFC 9449 Proof of Possession is how you prevent session hijacking, or session binding with a client-side TLS certificate.
Device-bound passkeys take care of non-repudiation. With synced keys (e.g., 1password), an account compromise of your vault hands the attacker all your credentials, the private keys are in the vault.
Device-bound keeps the private key sealed in the TPM (or secure enclave), the key cannot be exported, so it cannot be extracted remotely. Even malware on the machine, can hijack your session, but it cannot exfiltrate your private key, TPM won't release it to the service without user verification via biometrics, yubikey, or a PIN. There's also an attestation chain that breaks with synced passkeys. The attacker has no way to get your private key, so the only way to compromise the account is, yes, session hijacking, or physical access to the device with the user present to pass the biometrics check.
> Still, I can see a lot of scenarios where this might not work - e.g., the first one I thought of was a public computer at a library where Bluetooth might be locked down; corporate computers or remote servers could also be troublesome.
None of my desktop computers support Bluetooth. Neither do my wife’s.
I'm using bitwarden, but it's possible to use passkeys from multiple devices and if it's not available for whatever reason, you can just login with username/password/token/biological probe/whatever you used before. As an example: GitLab gives you both options right from the start, so you can use whatever you fancy in that particular moment.
Passkeys basically MITM the 2FA process so that they can track and deplatform you with a single click across all your accounts.
The biometric verification also allows to confirm that a certain person is holding the device, and they can easily be matched to existing passport/travel databases.
Great system if the good guys have it, a bit problematic if it's abused by nepo kids to hide their crimes.
The service can use the use the attestation feature to block passkey providers that are deemed undesirable for whatever reason. Hard not to see eventually only major providers being accepted, even things like Microsoft services requiring Microsoft Passkeys using the Microsoft Passkey App which you're now required to have on your phone. Or worse you now need Symantec Passkeys to login to Symantec services (using that example since I believe Symantec had a ToTP App you needed to reverse engineer to extract the ToTP seed from if you wanted to use a different Authenticator)
If a service wanted to do that they could already do that, you even point to an example with a platform requiring their specific app to use the account. I've had banks which required me to have their own time-based code physical security tokens to log in, isn't that in the end the same?
This thing you're talking about isn't inherently a thing about passkeys. If a service wants to remove your ability to log in to their service they can do it in a million different ways.
Also, the above poster said:
> deplatform you with a single click across all your accounts
"They" could do it across all your accounts with a single click. If service A decides to require attestation, how is that now affecting all my accounts?
Most of your devices are in the Apple ecosystem and when you are prompted to create a passphrase it will ask you to put it in your iCloud Keychain. Boom, now it is available across all of those
This is how it will work for most people who don’t care about security and just casually use their devices. My boomer mom does this. It’s better than the notebook full of handwritten passwords she was using.
You have chosen lastpass and a multi-ecosystem environment with windows and multiple browsers on each. You have chosen complexity and this is not a limitation of passsphrases as they have been designed for a more common use case.
I use Linux and apple. I have chosen protonpass for my vault. I just tell my OS to save the passkey there and everything works pretty well. If not, my password is right there as fallback. It’s really not that hard.
Proton Pass is on the official Passkey client naughty list[1]. I hope the services you log in to don't choose to ban it because of those big, scary X's.
This is why I am so concerned about passkeys. They could be a good improvement, but in practice I already see how it's going to result in Google/Apple/Microsoft/whoever seizing even more control.
The document there is laughable too, because KeepassXC is listed as "not performing User Verification" when it demands manual authorization per request. But this isn't good enough for the passkey people. Ultimately, I see any FOSS option being effectively banned from most services and all important ones. It's a parallel to how you must now be on Cloudflare's nice list or be banned from the majority of the internet.
Yeah they're really trying to solve problems that should be solved at a technical level with soft solutions in porcelain. See also this issue asking keepassxc to disable plaintext exports, which is completely technically feasible
The author of this ticket seems to come across as an arrogant know-it-all that thinks "the threats i thought of (or personally face) are the only threats that are significant, fuck anyone in a different situation."
I proudly print my entire KDBX file including passkey private keys and I encourage my elderly parents to do so too.
Lightning strikes (and assisting people with cleanup and repair from them) have taught me that there are definitely a class of threats that will leave me with paper but possibly no technology until I can go buy a cheap laptop to restart my digital life, SO BEING ABLE TO BACK EVERYTHING UP IS ABSOLUTELY ESSENTIAL.
His website says he's in Boston, so I seriously doubt he's ever seen what lightning can do or dealt with a hurricane or tornado.
In general, if you're in the FIDO Alliance and had anything to do with the kind of micromanagement that passkeys can allow, FUCK YOU. Go get a job at Walmart as a greeter. We'll all be better off.
That issue was exactly why I took up my "Never use, under any circumstances" stance on passkeys. It is an indictment of the entire passkey project. I now routinely tell the less technical folks in my life, when asked about those weird passkey options, that they are the mark of the beast, and should be avoided at all costs.
(I might be wrong, please correct me if I am) What I'm gathering from this page is that the Passkey spec can specify whether the app handling the passkey should prompt the user for biometric scan, PIN code, etc. but some apps simply ignore that flag. This makes sense though. I've already logged into my password manager and it hasn't timed out yet, so why would my password manager prompt me again? I'm glad that they don't prompt me again when I'm already logged in. I don't see this as a problem.
Your understanding is correct and I agree with you. The Passkey spec authors, however, think services should be allowed to ban your client for behaving this way:
> [When UV is required, KeePassXC must request user verification or not handle the request]
> This implementation is not spec compliant and has the potential to be blocked by relying parties.
> > This implementation is not spec compliant and has the potential to be blocked by relying parties.
The only conclusion I can come to when it comes to this and the earlier kerfuffle regarding being able to export the plain text of passkeys is 'the spec is bad and you should feel bad'.
Right, not only are you authorized, but you are also prompted to manually complete the request, which will fail if you do not accept. However, this isn't considered sufficient by the passkey people, who do in fact want you to retype your password at each prompt.
Then you'll login to your Apple iCloud account using your password.
Passkeys are just passwords that require a password manager; you can't login to a password manager without something outside the password manager, usually a password. (That's why they call it "LassPass" and "1Password"; there's one last password you'll still have to maintain.)
No password manager tries to get you to login with a passkey without setting a password, for precisely that reason. Apple, Google, and Microsoft do invite you to login to their password managers via passkey, because it's convenient and unphishable, but they always also allow you to login via password (or "backup codes", which are just backup passwords).
That is not a rare threat model. Many people use iPhones and Windows computers. Fortunately, Apple has released iCloud Passwords which lets you access passwords and passkeys from a Windows computer.
That's the point: passkeys, and even 2FA, address rare and unlikely threat scenarios, while defeating most common use cases (delegation by sharing credentials), and making people vulnerable to most common threats (like, losing or breaking your phone).
these questions all have easy answers that could be quite easily discovered by simply trying to use passkeys, instead of trying to find reasons not to use them.
But since there's a potential nonzero risk of permanent account loss, I don't want to experiment, and since I can still log in with email/password I'm going to keep doing that.
It’s quite the opposite. Passkeys are phenomenal for a lot of consumers. Based on this thread, it’s the engineers who understand authentication in the first place and have their own system (eg password manager) that are confused.
Consider a user in the Apple ecosystem: you are already conditioned to just do Touch ID or Face ID when asked. I was on Amazon the other day, it prompted randomly for “want to set up a passkey to sign in easier”? I set it up and now I can easily sign in to Amazon on my mac or iphone with zero friction.
For the normal consumer this is not a replacement for “dig out my password manager and copy-paste/autofill my password”, it’s a replacement for “oh it’s prompting for my password again” -> proceed to type your shared password for all sites.
A password manager let's me use my service specific credential from any device, securely and decentralized.
Passkeys lock into a specific device and seem easy until you need to use another device.
But instead of being a credential you own and control, across what could even be a local password manager, it's one password to everything. Maybe it is more secure than a regular password in some cases but it largely seems like a worse fix than existing tools for a problem that has better solutions.
Passkeys do *not* do that. I use 1Password to manage my passkeys and they are all synced across all my authenticated devices where I installed 1Password.
The moment my mom needs my help to login to something because she clicked the button but now it's expired / she got a new phone / raison du jur, I will be totally unable to assist her. It's a horrible concept being foisted on unsuspecting victims.
The first time I got asked by a site if I wanted to use a passkey I immediately googled what they were and... never really found the answer, not in the 5mins I devoted to being distracting from my task at hand anyway.
"magic fairy dust to login to apps." is the most accurate description I've seen.
Unlike a password or a TOTP token, I know how those work, I know its my responsibility to keep track of them. If my passkey is on my phone what happens if I lose my phone? Do I need a unique passkey per device? How do I rotate them? What if a device gets stolen?
I'm so glad I'm not alone in thinking these are so poorly explained.
Think of it like SSH authorized keys but automated for the web. Instead of storing the keys in a file; it stores them in a hardware security module (yubikey, or TPM).
Registration generates an asymmetric key pair between your passkey, and the website. Login is the usual challenge/response process. The biggest step forward is phishing resistance. A fake login page can relay a TOTP code, but not the passkey challenge/response.
100% had said something to the tune of this months ago in another thread on passkeys
> Passkeys need a marketing campaign and UX overhaul.
I’m a technical guy, but I really don’t understand what the fuck is going on when I use a passkey. All I know is one day it appeared as an option and it let me login to things. I don’t really understand where it lives, what device it’s tied to, how scanning a QR code on Google Chrome on my phone magically logs me in, etc etc.
The user was not educated on this. Hacker News is the top 1% of computer power users. You gotta understand to someone’s grandma or mom or brother who works in real estate none of this makes any sense nor will they educate themselves on what it is.
You can use both hardware bound passkeys (where you may not even be able to read the secret so you probably would want to add multiple device passkeys to a site)
or shared passkeys (where the private key can be synced through something like a cloud service across your devices, see Bitwarden, iCloud)
Sounds good until you realise theres no way to transfer/back them up and you are limited to 100 [1] (previously 25?).
Personally my password manager has almost 4x the entries so hardware passkey solutions are a joke leaving users with single option - upload their keychains to ms/apple/etc clouds where they can be requested by any gov under the sun for x reasons.
Like some folks already commented here, even as someone who has been working in tech for 20+ years, I find Passkey confusing. I understand the key aspect in computer science term, but I don't know how to use it across devices. Another big worry is that if I tie that to a physical key, then I might lose it (because it's physical) and never get it back.
use an open source password manager that supports them.
as others mentioned, there's BitWarden (cross-platform, self-hostable), but if you want something simple there's KeePassXC (and you can put the store file on a dropbox shared folder)
The cabal of evil behind the passkey project actively have KeePassXC on their naughty list fore deigning to allow users to access their keys, and specifically included in the standard the means to discriminate between different passkey vault providers. It is the opposite of an open system, and cannot, under any circumstances, be trusted. Do not use passkeys, tell other people not to use passkeys, and make sure to not let shills astroturf conversations about passkeys unopposed.
The problem here is i want to have more than 1 yubikey, so if i lose it, all is not lost... I can't do that with the current implementations unless i present N yubikeys to every new account i make. Which makes an off-site backup yubikey impossible. With my current yubikey usage with password store, my "offline" yubikey can be brought in whenever i want to decrypt the passwords, including ones inserted while the key was in storage.
Also yubikeys have limited passkey slots (100, 25 with old firmware)
Also, where do I store the backup Yubikey, or any other pass key owning device for that matter? It has to be easily accessible to set up the pass keys, but also safe from accidents like house fire.
There's a strange tension where I want to use pass keys because they are easy to use but also they are easy to lose, so I choose a KeePass synced over cloud and deal with a bit of a hassle by having to copy/paste my passwords.
a big problem with passkeys is that there is a lot of flexibility in how it is rolled out with a given site or app. Some sites ask your browser for a passkey as soon as you hit the login page. Some sites you need to enter your username/email address first before you're prompted. Some sites a passkey satisfies both password + second factor. Some sites you need to enter your password and the passkey is the second factor. Some sites you don't need a password but do need the passkey + a second factor (usually SMS)
This is on top of the confusion around enrolling passkeys in your device and synchronizing them
I am a big passkeys fan, and use them on every service I can, but they leave a lot to be desired in terms of user experience. Not sure all of them are solvable, either. The platform vendor side can be fixed: vendors can better integrate with each other to make your passkeys available on every device. But, the issues with how they work across sites and applications is probably not solvable
FWIW: I find passkeys to be a very simple and easy to use concept.
Simple: it's like a password that I don't have to type in
Easy to use: because I use 1Password and just have it installed on everything. On Android, it can be set as the default passkey provider so, even on mobile, I am using passkeys shared across devices.
Is this "less secure" because I'm sharing the keys through 1Password. I suppose, at some level. But before that, I was simply sharing passwords through 1Password in the exact same way. So, I don't think my security posture has changed any.
What has changed is the UX and IMO for the better. Now I don't have to generate/fill/copy-paste text strings for user names or passwords. 1Password knows what site I'm on and usually responds automatically when I'm in a passkey context. If I have more than one passkey available, because I have multiple accounts (for something like Google Workspace), it shows me options and I pick the one I want.
Honestly, it's mostly a "just works" system and I like it a lot better than passwords.
OK now say you're on a work/library/friend's computer and you want to look up an account in 1password on your phone so you can type in the password. Passkeys don't support this very basic and common workflow. Meanwhile there's no real security benefit over password manager generated complex and not reused passwords.
I use a passkey with discord on my phone. If I want to log in to discord on a computer it shows a QR code on the page/desktop app and I scan it with my phone to log in. I could see this become a pretty common pattern.
I like it because I can use discord on even a pretty untrusted computer without providing it any credentials or access to my passkey, and then later when I'm done I can revoke the session.
If I'm on someone else's computer and I want to use a passkey on my phone, the computer will display a QR code. I scan the QR code with my phone, the phone signs the login request and posts it to the service's callback. Then I'm logged in on that new device.
If my phone's camera is broken but both devices have bluetooth, it can do the handshake over bluetooth.
If I'm on someone else's computer and I want to use a passkey on my authenticator on my keychain, I'll just plug it in and then tap the button on the authenticator.
Meanwhile, if I logged in with the password and the account only has a password then they have a full copy of my entire authenticator to the account. With the passkey, once the session is invalidated the access is gone.
This is good in theory but in practice doesn't always work.
It isn't just a QR code like I would like it to be, its a QR code and you need bluetooth. Maybe there is a hypothetical world where bluetooth drivers actually work on windows machines and can connect to a mobile device seamlessly but that is not my experience. Across multiple windows machines i often have a problem where windows just decides the machine doesn't have bluetooth, and will refuse to display the QR code without any explanation. It doesn't tell you that bluetooth is the problem it just says "insert a hardware token to authenticate".
I would love for this feature to actually work but every time I've needed it to it hasn't. Literally this week I only had a passkey on my phone, but at the time I was in Linux with Firefox, and afaict the qr code workflow basically requires either chrome or windows 10.
I use this feature a bunch across dozens of different Windows and Mac devices from various device vendors with multiple Android phones and seemingly never had an issue.
But I'm also a person who generally never experiences the issues some people have with Bluetooth in general. If I ever have an issue with Bluetooth on a computer, I swap out the wireless chipset with an actually good one. Its almost always just bad hardware. I've only had to do that a few times in the last decade though, more modern WiFi/BT chipsets are generally pretty OK. Its the old ones that are near worthless.
Although I will say most of the time I just plug in my USB authenticator. I normally only fall back to the QR code if I don't have my keys on me.
And as an edit, I wasn't aware fully that the QR code is to help assist the BT handshake, I had assumed it was posting a signed request back to the service. My bad, my above comment isn't completely correct. Thanks for cluing me in to the BT requirement for the QR code path.
From what I understand the Bluetooth is required to ensure proximity. It isn’t actually used to transmit anything of vital importance. The QR is doing most of that. It’s just there to prevent scanning the QR through a video call and logging in from elsewhere.
Which I’m sure is great in theory. But IMO just adds even more complexity to a system that already has several moving parts and is more fragile than it should be.
This is a big problem I have with "just works". Everyone is used to services only allowing a single password. I know the answer to this, but it's not clear in the marketing or how it's explained to normie end-users: Won't creating a passkey erase my password? How do you sign in on another device? Won't that change the passkey and lock me out from the first device?
it just a lot of complexity and i don't want to deal with it but i have to because of all these dark patterns. sometimes i enable pass key and don't even notice.
I try to use passkeys when possible as I'm also a 1Password user, but this hardly "just works". Firefox on Windows often triggers the Windows password manager for passkeys (some how this is only on some sites), making it impossible to use 1Password.
I've seen the same on Android too, and I think there's a difference in how Chrome and Firefox are handling the requests.
Then you get in to cases like a Microsoft Account. You need to use your account to log in to the device that has the passkeys, so the workflow never works properly and you have to fall back to another method.
Amazon is another one. If an app like Libby redirects to Amazon, I get a different, passkey-less password prompt, so I need to have a password readily available.
It's great when it works, but honestly 1password with straight up username/passwords is probably just a better UX in the end.
This. Honestly, most of the arguments I read against passkeys just sound like “old man yells at cloud.”
It’s not that difficult. Spend 10 minutes researching the topic and you’re fine. Passkeys are so much more convenient than having to use passwords. When implemented right, it’s literally one click from opening the login page to being signed in. On all of my devices.
With physical U2F key, I could explain to my 78 year-old-parents "this is a physical key needed to access your account. Think of it like the front door key to your house. Don't lose it or lend it to anyone. We should have a couple of backup keys too." And they got completely understood and added it to all of their accounts. This was not hard. People assumed consumers were too stupid to do this without even giving them a chance.
I never found a comfortable way to ensure all of my accounts had more than one U2F key associated with them. I always wished there was a way to have 2 physical U2F keys, one on me, and by adding one to an account, both would work.
As is, I had to either:
- Keep both on me, and add both - I am at risk of losing both at the same time
- Keep one one me, one in a safe - I have to keep track of which device I've added to which service, and periodically take the backup one out of the safe and iterate through the "new" services
I was never satisfied with either approach, so I ended up with an OTP app with backups.
And/or maybe the vendors were annoyed that people would lend the keys anyway, refusing to accept that it is normal because that's how delegation of authority works in real life too. House keys are also things you often lend to a third party that you want/need to access your house in your absence, and in fact making extra duplicated for trusted third parties is normal.
Software vendors continue to refuse to support, or even accept the existence of, this entire class of use cases for regular consumers (they are, however, more than happy to milk enterprises on convoluted implementations of those).
I still can't even get a physical key anywhere in person. You can certainly get phones just about anywhere, but you can't get any FIDO keys at brick and mortar, last I checked.
Until I can tell Grandma to "go down to Walmart and ask the man at the electronics counter for a Yubikey", we still have a few issues.
(No. Ordering online is *not* a valid option in this scenario. If I want to order a Yubikey to this address at this exact moment in time and space, Amazon won't deliver one to me for at least six days at the earliest, based on their rural delivery estimate. Replacing a key is basically impossible.)
UX is not the problem with Passkeys. Passkeys were designed to align with the interests of BigTech, who are bent on stopping the abomination that is general computing devices in the hands of consumers and forcing them into their walled gardens. The language that is used for taking away freedoms is the same as always, safety. Where we ended up with Passkeys is an operating model that is suitable for corporate devices, i.e. the user can only do what the owners of the device allow them to. Suboptimal UX is downstream from that problem.
I think about this a lot when using our corporate SSO tool.
When I hit the button to log into Slack, there are like, 3 popups in succession - the last one ultimately asking for my fingerprint. Then when I give it, there is a flurry of web pages that get loaded and redirects that happen until finally Slack pops up again.
There isn't any realistic world in which I check each window to make sure everything is happening right and I am not being MitM'd.
I'm a fairly technical person, and I would be unable to perceive the difference between a really tight security environment and my computer being hijacked.
Aren’t passkeys intrinsically resistant to those attacks? With hardware security keys, the private key remains on the device, never crosses the network, and is cryptographically bound to the site being authenticated.
The point of passkeys is that you don't need to. Unlike passwords, your session cannot be hijacked because the thing that you give your fingerprint cryptographically verified the requester.
The website for my HSA required me to set up a passkey last time I logged in. I set it up on my work laptop and my work password manager, which means I can now no longer access my account from my personal computer. This is fantastic, just what I wanted
"But that's just a bad implementation, many other sites do it right!"
And many sites block paste from password managers. Passkeys have so many ways to do them wrong that we're going to see all kinds of new and exciting failure modes that lock you out of your account in the future.
Are you also using HealthEquity for your HSA? I'm the same boat, they're forcing passkeys on me. I can still login using my employer's SSO but I've been putting off setting up the passkey until I have to.
I mostly love passkeys to be honest even though I use multiple browsers across multiple devices and OSes (iOS, Chromebook, Linux, macOS, Xbox, etc). Bitwarden’s support is (finally) pretty good.
My problem is that I manage a lot of accounts for my family which makes passkeys a nightmare. If I’m out and a kid gets chucked into a login flow that happens to require a passkey, I can’t text a password and TOTP code to the adult with them. I know that’s terrible opsec but the reality is people share accounts and passkeys are designed to thwart that.
My take: (1) I've had passwords handled pretty well for a long time now: same password manager for something like 15 years; (2) companies are pushing pretty hard to get me to use passkeys instead.
From (2) I assume that the companies see benefits to themselves. I don't care about benefits to them. I don't see much in the way of benefits to me, so I'm not changing anything if I don't have to.
I'll admit to not having looked into passkeys all that much. Someday, I might. But for the time being, I don't see much point. I imagine that eventually I'll be more or less forced to deal with passkeys in at least some contexts. Will leave that for later.
I think portability is very confusing: they rolled out passkeys with no device portability (device-bound) and only recently added it (CXP). So for anyone with multiple devices it was a relative disaster - why should my Windows PC hold a device-bound passkey to anything? How do I login on Linux or macOS?
Picking a password manager to do portability also means another kind of lockin, though maybe you can live with that kind if you really trust the company. Even so, the password managers all seem to be competing to have relaxed security, so that vault and account passwords are the same, or you are asked to type your master password into a webpage - surely we didn't replace per-site passwords with this?
Yes, a bit of a mess. As the only practical way for most to use is with a password manager. So essentially, all your accounts still have a real password, just you enter that into your password manager app. So if your device is every compromised and someone has your master password then you are screwed.
And of course, passkeys on most all sites don't really improve security since someone can just choose to login with user/pass instead since presumably very few sites allow you to have just passkey.
Also if you use a password manager you may get locked into using that platform. Or ideally using a third party one but then having to pay a subscription, or using an open source option that is not ideal for the average person.
If one uses a passkey as intended and without a password manager and the site truly only supports logging in via your passkey, for all the touted benefits of passkeys, that would be a nightmare if a person loses access to their device, etc.
This comment section is the best example of all time of the arrogance of Big Tech and its employees. Please try to take a second thinking outside of your bubble before commenting ridiculous stuff.
Yes, as a wealthy American, you "live in the Apple ecosystem". 99% of the world doesn't. And guess what, they're affected by passkeys all the same. They use a Windows laptop, and either an Android phone or iPhone. A lot of people even have an Android phone and an iPad. And no laptop at all. But at work or school they have to use Windows.
It's quite simple. Besides people "living in a single ecosystem" (discussed above, this is almost nobody), passkeys are only viable (i.e. not very painful to use) if you use a dedicated cross-platform password manager. Yet people who use those - which too is a globally negligible percentage - are exactly the people who tend to have near nothing to gain from passkeys, and only to lose. The majority of them is tech-savvy and they use auto-generated unique passwords. In that scenario, the minuscule improvement in security is meaningless and not worth it.
Ironically, this comment section shows exactly why passkeys are a shit show. Half the people here are exactly those who are coming up with this shit in their FAANG jobs, happily part of the global 1% (of which their tech-illiterate grandma too is part of), and they have no idea or care in the world for the remaining 99%. Unless of course this was simply a land grab for lock-in, which is about as likely.
Passkeys are just SSH keys in how they work. We've been doing this since the 90's. The only people that use SSH keys are the Linux savvy users and those who are forced to via an enterprise solution for vaulting.
The average person doesn't know anything about this stuff nor do they care. I also have yet to see a Passkey solution that didn't also have a password on it and a nice little box letting people choose to use the password instead of the passkey. They just added a new layer on top of all the old ones and created confusion. Now people use password and passkey interchangably in conversations and no one knows what they are talking about.
My read on it all is that FIDO is stuck in some sort of groupthink. They don't feel the boots on the ground confusion around passkeys being opaque. They only care about phishing and being called "insecure" and don't care about anything else. Hence why WebAuthn has additional weird anti features like AAGUID for provider authentication.
Another one of those ridiculous threads is saying you gotta have support for nonsense like user presence verification.
The phishing resistance on fake websites is largely a function of the fact its an ssh key and you can't man in the middle those after first setup because you have known_hosts, which in the case of passkeys gets replaced with the website certificate technology.
The baking in "which authenticator is storing this passkey" and "require user to provide biometrics/pin to verify presence for this passkey" and "don't make it easy or possible to export passkeys" behaviour is more just control.
I guess it sort of helps if the threat model is complete remote code execution inside the victims brain because you got them to export their keys to you, but it seems more useful for websites and governments whitelisting what hardware and software they deem acceptable.
> I guess it sort of helps if the threat model is complete remote code execution inside the victims brain because you got them to export their keys to you, but it seems more useful for websites and governments whitelisting what hardware and software they deem acceptable.
Reminder that Facebook has warnings and prevention mechanisms to avoid users pasting malicious JavaScript into the console on Facebook.com (which would exfiltrate session cookies).
Preventing users from accessing these keys directly makes sense!
Aren't they effectively locked in the database of whatever password manager is used? I know you can export them, sort of, but that feature may blacklist your password manager and make it useless. Are they portable? I thought passkeys are locked to the device.
I was answering to the storage part. Blacklisting is the attestation part which is definitely a concern. Again, you can use passkeys as a yet another way to login. You can still use passwords. It doesn’t have to be one or other.
They might be the same thing cryptographically, but passkeys remove your ability to manage, move, or back them up at will. I can trivially move any single SSH key I want between my Mac, my iPhone, my PC, my Raspberry Pi, and my backup media. Can I do that with passkeys? It seems to depend on which storage mechanism I choose, and even then it's often a matter of dumping the entire password database to plaintext first.
Edit:
Oh yeah, I can also share SSH keys with friends and co-workers. I can freely choose which SSH key to use when authenticating and I can have an arbitrary number of SSH keys for a given server on each machine. Some of this stuff is esoteric, but some is not. Most of the stuff I can do with SSH keys I can also do with passwords but not with passkeys (or at least not always). Finally, as many others have mentioned, the attestation stuff is really ugly and takes control away from the user entirely.
Stop thinking of them as alternatives to passwords. That is something they do, incidentally. Really, they are an alternative to normal TOTP 2FA (and shudders SMS 2FA). Those were already dependent on an app on a single device, or a password manager. And now, you can have the security of that, automatically used with biometrics. It is only because they are so secure, due to being a cryptographic key, that they can replace passwords.
They really should come up with a way to transfer them across devices/password managers though.
If you want a consistent, and seamless authentication experience, then one party has to own that experience. Go federation/SSO. Sign into everything with microsoft, or google as your identity provider, and live with the privacy implications.
Passkeys are great, and they take a significant amount of work away from the user, and make them much less prone to phishing attacks while also not turning their entire online identity into the property of google. I've had much more luck with onboarding non-technical people into a yubikey vs a password manager. Platform authenticators tend to trip people up. However, the process of adding a new key is getting much more consistent, and legible to people over time, and things will settle on platform authenticators rather than external physical keys for most use cases.
I really don't get passkeys and how they are supposed to be safer.
Currently I save all login tuples to Bitwarden and store OTP secrets onto Aegis. Could have been 1password and authy, it's irrelevant. The thing is, I only get pwned if both are compromised.
Now with ubiquitous passkeys in Bitwarden if someone has access to my vault unencrypted it's already endgame.
Passkeys are a political play aimed at bolstering government support. They’re the privacy sabotaging arm of Digital ID. They go hand in hand with “age” verification. It’s all the same play. Get your identity, get your access credentials, give it to the prying eyes.
Passkeys work well when you have password managers with multi-device sync. While it is indeed trivial to get one, consumers don't like password managers in first place. And it is very hard to make person use password manager, instead of his john1988 type of password
My biggest issues with Passkeys is how inconsistently they are implemented and how opaque they attempt to be.
I understand SSH keys, I've been using them for decades, I know where they live, I know how to secure them.
Passkeys are murky as fuck. Is your PW manager supported? Do they sync? Where are they stored? How can I move to another PW manager if I want to in the future? Can I have more than 1 passkey per site? And the list goes on.
I _know_ some of you out there can answer some/all of the questions above but it's mostly on a per-site basis. Passkeys take too much of the control out of my hands and I don't like that.
Even more than that, I hate how they are trying to be pushed on me at every turn. Login -> Want to save a passkey (but they never call it that, they use some other confusing euphemism)? I click "No" and then it proceeds to pop 1Password's UI, then I dismiss that and it opens Chrome's passkey save UI, I dismiss that, and then it opens the OS's passkey UI. It's incredibly disrespectful and unclear.
I never use anything but 1Password but somehow everyone (OS and Browser) try to reach their grubby hands in. This is what scares me, I don't like having to be on high-alert to not accidentally save a passkey in Chrome or Safari and not realize until I'm on a different device and notice it's not in 1Password.
Lastly I trust the developers implementing passkeys... none, I trust them none, zero, zilch. I don't trust them to pick the right defaults, I don't trust their recovery options, and I know they will always pick the configuration that benefits them and not me.
No, for now I'll stick with my as-long-as-you-let-me-make-my-password random passwords which I never copy/paste into random website and be perfectly safe, thank you.
Passkeys are a vector for locking your logins to Big Tech ecosystems. They support device attestation, which means the service you are logging in to can require you to only use certain Passkey clients such as those provided by Google, Apple or Microsoft. The Passkey spec authors also maintain a list of "naughty clients"[1], which are clients that allow the user to manage their own data how they want. Services could choose to block those clients for "security reasons," justifying the decision to force you to use one of the Big Tech providers.
Until device attestation is removed or strongly curtailed in the spec, I suggest you do not create any Passkeys. Which sucks, because it's otherwise a pretty cool tech.
I find Google Password Manager makes passkeys pretty easy to use. As long as you don't accidentally create a passkey some other way. Hopefully websites will adapt to the reality of how people use passkeys in practice and some of the UX weirdness around them will disappear over time.
One annoying thing though is that while they recently added password sharing, they don't allow sharing passkeys. Basic passkey sharing would be nice, but it also seems possible to implement fancy sharing features that wouldn't be possible with password sharing. Things like sharing one time use passkeys or time limited passkeys or limited access passkeys or secure revocation of shared passkeys. I hope people are thinking about this.
I spent a long time working in the network security field, and you speak truth. The perverse thing about it is that security people should care a lot about usability. If the scheme isn't usable enough, people will figure out how to bypass it or aspects of it.
The technically weaker security scheme that everybody accepts is more secure than the technically stronger security scheme that everybody tries to bypass.
I will never understand how a small group of tech savvy people are heavily confused and against a simple and more secure system.
You want anecdotes? Ok. I’ve had elderly adult relatives who aren’t good with their devices tell me unprompted they’re using them and like them when I mentioned the word out loud to myself using my phone around them.
These are people who don’t know the difference between apps and the web. Who have 200 tabs open because they don’t know what tabs are so a new one just gets opened automatically all the time. Can’t tell some websites apart. Who change their passwords on every login to some sites because they can’t get sign in right.
Yeah if you want to write them down or refuse to save passwords outside text files or demand they live on a security key on your keychain you’ll have a hard time. You’re being 0.0000001% of the user population. You’re not representative.
They are a MASSIVE UX win. A MASSIVE security win.
I’ve logged into my work computer with a passkey on my personal phone, no issue. It’s fine. They’re backed up locally. It’s fine.
The biggest problem, which is getting better and somewhat a transition problem, is sites using terrible UX to trigger the workflow. Those that follow the suggestions or close to it are great.
I've yet to meet a non tech person irl who uses them. I went through the laborious process years ago setting my parents up with 1Password. They find passkeys very confusing addition. I have yet to see the massive UX win. If that were true I don't think we'd be having this conversation. Good UX becomes the natural state of things and we don't even notice. I've had trouble myself setting up passkeys correctly with my 1Password. This never happens with traditional passwords and 1Password
My elderly mother accidentally created a passkey (in Chrome) for one of her accounts. Normally, I try to keep a copy of her accounts and passwords in case she forgets them so I can help her out. With the passkey, this is impossible.
She doesn't know how she created one, she doesn't know what it is, and I don't know how to explain to her that if her PC dies I won't be able to help her log back into her account. I'm not even sure how I'm going to migrate this thing to a new PC for her.
I think the problem was that there wasn't a "Best Practices" way of using them when they were launched, which really prevented describing them in a consumer-friendly way.
And web site implementors couldn't follow that golden path, or describe the golden path, so there's fragmentation in usage and meanings and practices, making it far more confusing.
I love passkeys, I want to eliminate any and all password-based logins and switch entirely to passkeys. It's such a better experience, it's a "physical" key that can be backed up to multiple devices, and thinking of it like a key for a physical lock really gets at the core of its capabilities. But locks can be used in many many ways! Maybe you need to open the lock and still tell the guard a password, which is weird, but how most websites still operate.
I don't use passkeys because I can't tell if they're a one-way door. If I use it once, can I still use passwords to log in in the future?
I also don't understand how the system works when things go wrong (someone hacks your account, etc.). I don't even understand all the ways things could go wrong with passkeys.
Seeing the comments here makes me realize I'm not stupid or ignorant for not understanding these things. Some people do understand them much better than me, but there is no universal answer that emerges after sufficient study.
This is mostly a complaint about bad copy/explainers in Google's UI. Passkeys, properly implemented, can be perfectly consumer friendly (e.g., Apple Touch ID is delightful).
I don't know everything there is to know about passkeys or anything, but my reaction to most of these comments is "You're passing yourself off as someone who has relevant opinions about security, and you can't possibly imagine how these things work or how they're useful? Come the fuck on."
Passkeys are basically session cookies that are signed by a secure element in one of your devices at the time you log in. That's it. They cannot be phished because there is no password to steal. If I had to guess, the basic flow is something like this:
1. When the passkey is created, the device's secure element coughs up a public key or something to the server representing itself as a trusted device
2. When a user logs in, the server issues a challenge (basically a random number) to the device and says "sign this with a private key that corresponds to one of the trusted public keys I have"
3. The secure element signs the challenge and sends it back
4. The server goes through its list of trusted device public keys until it finds one that verifies the challenge response. If it finds one, it logs you in. If it doesn't, you don't log in
Step (1) is probably bootstrapped with a username/password and second factor like SMS 2FA, OTP, or email 2FA.
Even if this isn't exactly how they work, it's a plausible implementation. Nothing about this requires vendor lock-in. The various secure elements that can produce passkeys come from many different places, so I'm sure sufficiently motivated open source people could create a firmware TPM that is certified for use with passkeys or something if they cared enough.
At Caution we -exclusively- allow passkeys. The entire database is user ids and public keys. If it leaks, it would only be mildly annoying.
If you are confused about digital passkeys, you can use a physical yubikey or nitrokey and tap it when it blinks. You can treat them like a credit card or house keys.
Asking people to keep up with and remember passwords is and always has been the thing that was invented with zero understanding of the consumer brain.
Isn't that just a euphemism for "we mandate passkeys"? Saying 'exclusively allow' draws the reader's attention to the positive (allowing!) while de-emphasizing what's not permitted.
Regardless, I think it's a lot less of an issue for services exclusively oriented at people in tech instead of just everyone. Even then, there is a barrier to adoption besides just understanding it, which is relying on new software or owning a piece of hardware. It's a lot messier, while text remains universal and has no dependencies.
I only use pass keys by storing them in 1password. Then I don't have to worry about the whole "lose/broke/replace a device" thing, which is inevitable. Then just be really good about keeping your backup codes etc with 1pass solid.
We've all been through at least a couple rounds now of the security industry pressing us to change how we log in, ostensibly in our best interest: impractical complexity requirements, 2FA, "magic links," ridiculously short session expiry, whatever this bullshit is with the username and password on separate pages that make your password manager less convenient.
The only observable outcome of each of these changes has been making these products less convenient for us to use. At this point I don't think I am alone in being knee-jerk opposed to any further "improvements." I have yet to see a website make a case for a passkey being more convenient than what it is replacing, so I will continue opting out of them as long as I am allowed to.
Passkeys are so, so, so bad. One of the worst things our industry invented. The sooner sites start leaving them on the wayside and just go back to TOTP, SMS, and Email codes/links, the better. These work. We solved auth. Its fine.
I don’t understand this point at all. I think the author has himself confused with the average consumer. For the first time in a decade or so you can buy a PHYSICAL key and use it to sign into websites. I can explain this to any grandma out there. Likewise, I’m an Apple user. Once you’re in Apple universe passkeys are extremely easy. Tap your thumb on the scanner, done.
Now we can put on the tinfoil hat and say how this fosters vendor lock in yadda yadda but the last thing I would say is that it has terrible user ergonomics. LOL
And there's your blocker. Being limited to only devices from a single vendor is horrible, and a firm no from a lot of people.
> Now we can put on the tinfoil hat and say how this fosters vendor lock
The fact that you call it a tinfoil hat type issue is just insane to me. Literally every person in my household has some apple devices and some other ones (android, windows, etc). And some of them have switched back and forth.
Plus, the "ergonomics" of logging into a website on a random device to check something are awful.
I literally presented you with the solution in the sentence before. Buy a usb c dongle key. You pay 20 euros to NEVER have to remember a single password ever again. Seems like an ok trade off to me.
Likewise you can register multiple passkeys for multiple devices, so long as you do it in sequence (first Apple, then Android) etc.
Really it takes very little getting used to.
Ever tried to fill out a crap password form which wants 7 special characters but no dashes but uppercase but not uppercase Y and so forth.
if you have good password hygiene is doing a lot of work here. such a large population of the world does not have this, credential stuffing is a huge class of vuln
Another noteworthy annoyance is the increasing number of services that try to aggressively push you towards passkeys, without you ever asking.
Every other time I open the Costco app (needed to walk in to the store, since I don't carry my card and they refuse to provide Apple Wallet integration) I get asked to switch to passkey, without a way of saying "don't ask me again".
If you're in any position to determine this in your company/software, please stop this pattern. Give users the option to say "stop asking me about passkeys".
I find it difficult to explain how to use password manager to non-IT person. Whatever I say, they say it is not secure. No amount of explanation will change their mind. They prefer to keep their passwords in their physical note book hidden in the safe (yes, they open the safe etc each time they need to log in somewhere when they get logged out).
As someone with ADHD a passkey is something I can lose easily and I don't want my accounts to be tied to any specific device. What if I have to upgrade my laptop tomorrow because one I use got bricked? Sounds like an absolute nightmare.
Password on the other hand I can remember for dozens of services, each very long.
If the person you describe really is doing that for all their passwords, then they are correct. Their password store is more secure than a password manager by nearly every metric that counts.
The one thing I would ding that approach on is recoverability, though. If a fire burns that down, it's gone.
They should buy a Yubikey (a physical key) and keep their passkeys resident on that. Then they can truly keep that physical key locked up in their safe. And it is truly safer than their physical notebook because they are safe from being tricked into entering their password in the wrong place.
How do they tell their significant other how to logon to a shared account when they aren’t together? How do they use the Yubikey with their phone, laptop and tablet conveniently?
It just so happened that Microsoft sent an email today to our M365 tenant administrators that SMS and voice for 2FA is being removed 1-Feb-2027 and that automatic enrollment to passkeys starts 1-Sep-2026. Bring on the passkey overlords. Although, LLMs say that passkeys are superior to passwords since it includes a public/private key setup with the private key saved to a device that requires a PIN or biometric to access the private key.
The use of a passkey doesn’t require Authenticator or other OTP app. Gemini said that an OTP app can be used as a vault for the passkey, but it’s not the mechanism that permits the check of the private key. Rather, that’s the PIN or biometric. Now, perhaps I don’t understand your statement and you can clarify if that’s the case.
I do not understand all of the drama surrounding passkeys. They work flawlessly for me on all my devices. Maybe that’s because I’m all-in on Apple devices, but I have yet to have a single problem with passkeys.
The cumbersome and poorly designed workflows surrounding passkeys are a significant hindrance to their adoption as well. It surprised me how bad they were when they emerged -- it was as if the UX was intentionally designed to kill passkey adoption.
One of the worst technologies I've had the misfortune of being forced to use honestly. It's always confusing and always breaking or not working as I expect across my devices?
The fundamental blind spot engineers have had with every authentication protocol for 30 years is forgetting that trust must be mutual. The lone exception has been phishing prevention with user-selected avatars, and that didn't last long.
Every advancement in "security" has assumed the service needs to more strictly identify the customer, without caring about the customer's trust for the service, or experience with performing the identification ritual.
So when your bank asks you for a code or your mom's maiden name, they never offer anything to verify they are who they say they are. whenever I ask they say "of course we're from chase, we just called you", without realizing how absurd that is.
Now Passkeys suffer an even worse dilemma. Now the customer has 4 dimensions of tools to record & use in order to log in. Did I use email, google, facebook, apple ID to log in? Did I save this code via phone, text, authenticator app (which one, there are multiple incompatible ones)? Did I use a passkey ? where is that passkey located? my phone, my browser storage, my authentication extension.
We started with a single dimension of email + password to log in. Now it's an entire decision tree that has to be recorded. How do you even record this?
disqus : credential = email, password = "see bitwarden", 2fa = microsoft authenticator, passkey = "on iphone in icloud"
viator: credential = google sso, password = same, 2fa = symantec, passkey = "edge on windows 11 laptop in office"
This is absolutely absurd!
I thought engineers were tested for scaling during the interview process. This protocol doesn't even scale to a single site.
I'd like to try passkeys out. I actually tried again on Amazon in response to reading the comments here. But it just.... doesn't work?
I'm on a laptop running Ubuntu, I use Firefox as my browser, and I use 1Password as my password manager. I have both the browser extension and native Linux application installed, and they sync/communicate with each other (so if I unlock the native Linux app, the browser extension also unlocks).
When I open my Amazon.com item in 1Password, it has a helpful link to https://passkeys.directory/details/amazon which tells you clearly, step-by-step how to set up a passkey. Great! I love clear directions.
But when I get to the step when I click the "Set Up" passkey, Firefox gives me an address bar pop-up saying "Touch your security to continue with www.amazon.com".
Huh?
I don't have a security key. My laptop does have a fingerprint reader, which I use to unlock my screensaver (and it's integrated with some KDE keyring thing), so I tried putting my finger on that. Nothing. I opened the 1Password extension. Nothing there, just normal view of my login info. I opened the 1Password native application. Nothing there either.
Maybe it's a Firefox issue, or a Linux issue? So I tried setting it up on my phone (running GrapheneOS and their Chromium-based browser), which has the 1Password app installed. I logged in, and this time got far enough that 1Password brought up a prompt asking "Do you want to save this passkey?" I tapped Yes, and it then immediately told me "Unable to save passkey: For security reasons, 1Password did not save this passkey. The associated URL for this passkey does not match the selected app." So... does that mean 1Password is refusing to touch the passkey because it didn't come from the com.google.chrome Android application?
This whole experience has re-affirmed my skepticism of passkeys in practice. I think it would be awesome to have public/private key security on my online accounts. I think it would be great if I could log in without having to copy/paste passwords (when autofill doesn't work, or for TOTP codes). But I have zero confidence that this opaque stream of bytes will actually work to get me logged in to my account. When the 1Password input field detection fails, I sigh, copy/paste my username and password, and then forget about the mild inconvenience after about 30 seconds. I don't even want to think about what would happen to an account if the only way to log in to an account was via passkeys.
Passkeys do have drawbacks and tradeoffs, as has everything, but my god did I feel the energy of „lol I’m so bad at math” in that tweet and a lot of „lol smelly nerds” in replies.
I don't know how to rationalize it: is passkey so good that even the banking apps start pushing it, or is it all a big conspiracy theory with a hidden agenda?
Passkeys were invented so hacked sites could brush off their leaks with "no credentials were leaked" and minimise any regulatory fines. This is the reason why its being pushed by the big players.
Additionally this puts the same players in control of your logins - want to sync your passkeys? - enable "iCloud Keychain", or some other 'trust me bro' app that will 'securely store/sync your data' - no thank you.
In perfect world users should be able to generate a certificate, upload it to a couple nfc capable ubikey like devices that blow a fuse afterwards preventing from additional writes/reads and use that to login to every app ever. You would buy such devices in packs of 3, upload same cert to all, hide the other, burry the third.
My tinfoil hat take is that there's significant interest to keep everything digital, always-online and connected to the major providers, so it can easily be snooped by five eyes using their omnipresent backdoors.
Passkey biometrics also allow you to confirm certain person is holding the device right in this very moment, and not receiving a TOTP via walkie-talkie. Especially important for kinetic sanctions.
If you check out their Terramare group of companies those guys are still using typewriters. Unless you're US/UK millionaire I recommend to stay as analog as possible with physical password book and TOTP/yubikey.
Same with the push for "post-quantum crypto" and elliptic curves. I feel my systems get significantly more attention when using 8k RSA than any of its modern replacements. While I love wireguard the transition to ED25519 felt way too smooth..
Diversity is resilience; no need to standardize on curves or "post-quantum" IBM bullshit if other approaches still work perfectly fine.
And if the pros are using typewriters in 2026 it's not a signal for me to put even more eggs into the US-megacorp dominated basket who treat me like an NPC who can be droned at will.
An important skill to develop is determining whether somebody is bullshitting you. Because it would be impossible for any one human to perfectly understand all of these concepts, right? So when I read this person's blog post, I felt I could trust him, based on what I know about work he's done previously. I'm not saying you should trust me on this, or even blindly trust him, but look at his body of work, and the sources he cites, and make the call for yourself: https://words.filippo.io/crqc-timeline/
I think there are probably sinister motives behind some of the push to pass keys, but you'd think that if that were true, they would make it really quite easy to add one and to use.
That is not the case. The entire setup/enrollment/add a passkey to your account processing is DMV inspired.
Consumer passkeys are just an extension of the OMB Policy Memorandum M-19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access Management (dated May 21, 2019). It is ultimately part of anti terrorism efforts with regard to banking and fraud. Think of this as consumer computer version of the scene in the movie The Baader Meinhof Complex when the cops are discussing a proposal for electronic data processing. "According to a poll by the Allensbach Institute, one in four Germans under 30 sympathizes with the RAF. That's nearly 7 million people. That amounts to an enormous pool of sympathizers, which makes the search for perpetrators extremely difficult." It signals the end of publicly available general computing. This was always inevitable, the mob cannot be trusted with weapons of mass destruction. Computers = Guns
Passkeys are a mitigation against users being bad at password hygiene and phishing being a real issue to users.
You can't phish a passkey, and you don't rely on the user providing you 'hunter2' on every site.
As for vendor lock in? No. The specs are open. You can run the code on a microcontroller, or, you can keep it in your arm with something like the Vivokey Apex. Note that the FIDO2 for the Apex is an open source Javacard applet.
The UX on the other hand is not great. If you have a password manager, your OS may prompt you which target to store the passkey with.
> As for vendor lock in? No. The specs are open. You can run the code on a microcontroller, or, you can keep it in your arm with something like the Vivokey Apex. Note that the FIDO2 for the Apex is an open source Javacard applet.
That is not true. Passkeys support device attestation, enabling websites to lock you out if you don't use their approved devices. Which is happening with all the big platforms right now.
I do not know how to use a Passkey in a way that won’t impede how I log in to systems. I’ve been in tech for 26 years, and I understand the Public/private key behind what a Passkey is. Here’s what I don’t understand:
I access a website through at least four different devices (my iPad, iPhone, Windows Desktop computer, and MacBook Pro) and three different browsers on each device (Brave, Firefox, Safari) , and I use LastPass. If I accidentally set up a passkey on my phone (let’s say I use Safari one day instead of my go-to, Brave), can I still log in without that passkey on other devices? Is there a way to ensure that passkey can be used on other devices? Can I add another passkey on another device? How many passkeys can I set up for a particular site/app? I have at least 6 different combination of browser/devices in use.
I don’t want to use Passkeys because I don’t the answers to those questions, and I don’t know whether each website/app that has set up Passkeys has decided the answers to those questions in the same way as the others. For now, I’m going to stick with LastPass and use Passwords; because no matter whether I lose my device or not or whether I’m on my own devices or not, I can be sure I’ll be able to get into a site/app.
Edit: One final consideration, my spouse and I share user/name passwords for some things (notably Pandora and our Amazon Prime account) since they don’t handle things like family logins well; how do both my wife and I use amazon or Pandora with passkeys? Do we each set up passkeys? How do I get her Pass if that’s not an option?
A potentially good idea got corrupted by vendors, password managers, browsers, etc trying to assert control. I'm also an engineer and I find the UI around passkeys entirely unclear, but it doesn't have to be that way. It seems like everyone wants to be _the_ password manager for all your passkeys. They don't want to make it easy to understand that is what they are doing though, they just happily offer to "handle it for you".
My non-technical friends are extremely confused by passkeys and if they should use them and how to use them and I honestly don't have very good answers. It is a mess. I don't believe an inherit mess, but one created by the companies and projects trying to take advantage of the new system.
> It seems like everyone wants to be _the_ password manager for all your passkeys.
Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound, the private key held in the TPM or secure enclave or whatever other security chip, mathematically non-exportable. Storing all your private keys in a cloud vault still leaves you exposed to potential credential theft if your vault gets compromised.
Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).
1) When I buy a new device, how do I create 2000 new Passkeys for that device?
2) Can I still do that if I don't have access to the old device? Maybe it was destroyed, stolen, or lost.
3) How about if the new device is from a different vendor than the original device? E.g. switching from Apple to Android?
Apple's keychain or google password manager - can hold 2000 passkeys easily.
Nothing in the post you're replying to is about "is 2000 passkeys storable", it's about "if I have 2000 passkeys and I need to move between an Apple device and an Android device, do I need to establish a second set of 2000 passkeys"?
Did you not read the comment thread you're responding to?
> Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound
If you watch the original Apple WWDC talk presenting passkeys, you will find that they were always intended to sync, at least for the consumer use-case.
What you are describing is how the WebAuthn standard had been implemented by Yubico and Google up until the point of the introduction of “passkeys” by Apple.
The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices.
Right; but THAT idea is consumer hostile by design.
So your account is now tied to a physical device; great, but the device is dead, or you own a dozen devices, now what? Each vendor has their own idea about what THIS means. Heck I have a couple that allow, max, a single Passkey at a time.
> Right; but THAT idea is consumer hostile by design.
No argument from me there, just stating what the design actually calls for.
It was never meant to be consumer friendly in the first place, it's an enterprise standard. It was just shoehorned onto consumers with the synced credential compromise to make it easier, instead of coming up with something better, and then just calling it a "Passkey" which now has dual meaning.
But the real solve is difficult. If a system requires a consumer user to manage, remember, or safely store something extra, it will fail.
The FIDO set of standards (UAF, U2F which predated passwords and passkeys) haven't even started as enterprise standards. There are multiple origins for what became FIDO, but the main ones I know are:
1. PayPal was looking for a physical authentication solution for their users, Michael Barrett was their CISO at that point and he became the president of FIDO.
2. Google developed Gnubby (which was internal, and therefore enterprise) and they wanted to push a similar authentication to their end-users, supported directly on Chrome. They wanted this to become a standards, so donated the underpinnings of the Gnubby technology which became FIDO U2F.
I might be wrong but at least these are the two parts I know.
And while the original FIDO could be called dual-use, Webauthn and especially Passkeys were developed to be first and foremost a customer-facing standard.
It doesn't mean they are not confusing, but they are clearly designed with end users in mind.
> Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).
This is a misconception. A particular service can choose to enforce those class of passkeys, but most don't need that and shouldn't.
Passkeys are primarily meant to replace passwords and be hard (but not necessarily impossible) to exfiltrate.
The key difference is during normal usage you don't have to type the secret in anywhere, it's strictly asymmetric, so a unwitting user is far less likely to get fooled into accidentally leaking the actual credential.
Passkeys is basically a brand name for "discoverable credentials" (a Webauthn term). They do a little more than that technically, but in practice their purpose is what you said. Replace passwords. Or more accurately usernames and password pairs. This is in contrast from 2FA, but even before Apple started marketing Passkeys the FIDO standard supported the concept of Passwordless authentication, alongside 2FA.
Passkeys came together with multi-device syncing when Apple introduced them and IIRC it was pushed as their killer feature by Apple back then, but passkeys can also be completely device-bound. The marketing around this was all quite confusing, but it's a bit too late to fix now.
What we got, as far as the average consumer should be concerned, is that "passkey" is any authentication mechanism (not the actual credential) that can replace a password. And it's still confusing.
This is exactly all the stuff normal people don't care about.
If your system requires any basic intelligence or interest scrap it and go back to the drawing board because you just lost your customers.
Stronger than "don't care about" (at least if I and some friends I've discussed this with count as normal people): this is actively what I don't want! I want control over my authentication and I don't want it bound to device, browser, OS, etc.
I mean, no one ever said it was a good design.
But the original FIDO2 standard wasn't made with consumers in mind in the first place, it was driven by enterprises that wanted high-assurance security. It works in that environment because, well, a big IT department controls it, can support the employees, and you can mandate and control its use.
It was just sort of haphazardly shoehorned onto general users/consumers, prematurely IMO, via synced credentials as a compromise instead of coming up with something better.
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.
>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.
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.
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.
So you're saying that if you're inside Apple's walled garden, it works really well! Hmm...
> 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_.
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.
>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.
> 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.
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 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.
> 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.
> 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?
> 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.
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.
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.
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.
> while providing nothing.
You forgot about the endless frustration and annoyance.
> 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.
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.
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.)
> 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.
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.
I went to my bank with all my ID and my bank card, talked to the teller and was told to call a support line. One of my parents went through the same thing.
I don't have a citation for you just recent experience, do you have a citation?
I help run a non-profit and the only time I have ever been able to get this kind of service is when I visit a bank that has in-person business services. Tellers do not have any ability to do any of this.
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.
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.
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.
> 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.
"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.
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.
> They are supposed to be mathematically non-exportable, device-bound.
Which would make the whole scheme unworkable (at least for me).
I pair of hardware keys (Token2, Yubico, etc) has the benefits from both worlds.
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.
> 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.
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.
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.
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.
> 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.
>> 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.
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.
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.
How well does that Yubikey work with an iPhone?
Works great, they even have ones with USB on one side and Lightning on the other for older iPhones.
Works just fine, you have to get the one with NFC
You can also plug them in to the USB-C port, works just fine.
iPhones are a lost cause.
Passkeys on my iPhone works awesome.
Too bad for Yubikey. I don't need them any more.
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.
> 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.
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.
> 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.
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.
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?
> 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.
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.
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.
Is this different from the per-app enumeration in Account —> iCloud —> Storage? That provides a means to delete per app
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'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
> 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
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.
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.
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?
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.
> 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.
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
> 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.
> 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.
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.
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.
> Is writing down passwords something people do?
Yes, it's pretty common.
It is absolutely a thing people do. Google even offers a convenient printout as a way to provide account recovery.
The passphrase to my bitwarden database is in my will. And a bitlocker decryption key is right beside it.
It is what the vast majority of people do.
I doubt if that’s true since the vast majority of people no longer have printers. Not even the vast majority of online people.
Both pens and pencils exist.
I was not aware writing down a password required printers.
> 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.
I get your problem, i don't really accept it as valid. Passkeys were always supposed to be fungible. You have one in your iPhone, a different one on your desktop. A third in your significant other's phone. All stored in the hardware tpm equivalent.
You can have 7 passkeys. You can have 14.
The real failure of passkeys (emphasis on the s!) is that people think they must only have one.
> [...] people think they must only have one.
That's the real failure? I think the real failure is that people must have _more than one_. I thought so hard to add all my credentials to 1Password. Now people tell me I should use a Yubikey (or better two or three of them). What do you think, I'm going to register a couple of hundred accounts times three for something I already have (my password manager)?
The real advante in passkeys is in allowing me to log in into a service on a foreign device without typing [my password], which is (honestly) something now sane person should ever do.
Again, is this true for all major sites that support passkeys? And how do you set it up? My passwords are automatically synced between my devices, how to I achieve the same thing if I set up an account with a passkey?
In practice, because site owners know users are going to mess up having their passkeys on all devices, I've not seen any insist that a passkey _must_ be used, and you can always log in with your password (or worst case, email magic links) as a fallback.
However, this negates the primary stated objective of passkeys, removing the possibility of users being phished, so I'm not sure how long that will remain the case everywhere.
I've also encountered sites that have a login with passkey prompt that then turns around and asks for TOTP 2FA or email confirmation anyway, which to me seems to negate the primary customer benefit of passkeys...
> I've not seen any insist that a passkey _must_ be used, and you can always log in with your password (or worst case, email magic links) as a fallback.
With the exception of Github, and banks.
Did you try it? That’s not correct. I just logged into GitHub with a password (+ 2FA), on an account that also has a passkey.
No major bank revokes your password when you setup a passkey, either.
Is "passkey" only supposed to mean devices that implement specifically U2F, WebAuthn, etc.? I would have thought TOTP and challenge-response hardware tokens to count, including cellphones with apps that implement such.
As to
> No major bank revokes your password when you setup a passkey, either.
If we're talking about requiring 2FA via TOTP or challenge-response hardware tokens or banking apps implementing such, that depends on the country. It's the status-quo in some places. Some banks even put the input field for the token output as a third input in the login form on their website because all customers have them. The rest separate their login form in multiple steps, but they likely require it of all customers too.
> I would have thought TOTP and challenge-response hardware tokens to count
Those are absolutely not passkeys. Passkeys are just WebAuthn (from what i can tell).
Such a generic word. I imagine there are tons of CLI utilities out there with a --passkey option that refer to simply files with a key inside. Kind of crazy that it's being used to mean specifically devices that implement a specific protocol.
Kind of feels like "crypto is a type of currency and not all cryptography".
"Passkey" refers to a very specific authentication method. TOTP, etc., don't count.
Porkbun too
This is the main reason I've avoided passkeys. I have these exact questions and there's no a clear explanation given for these. I don't want to lose access to important accounts.
If you use something like 1Password it's very easy. It stores your Passkey and it syncs cross device. It's another thing but once it's set up it's less of a pain than using authenticator apps or having to find some random iPad that Google popped up an approval prompt on.
Agreed, it's the exact same as me, I haven't seen someone put it into such succint words before, so bravo.
I think the reason is because I've anchored passkeys into my understanding of how 2FA works, and the pain of migrating 2FA from one phone to another.
So, I don't want to bother with it.
use an app where you can backup the 2FA DB.
https://f-droid.org/en/packages/org.liberty.android.freeotpp...
oh my god, so not the point.
This is the #1 most common misconception I see about passkeys. They do not make it more likely that you will lose access to your accounts. They actually have nothing to do with account recovery. They are just a stronger primary factor than a password.
Most providers continue to offer email-based recovery in the case that the end-user loses access to their primary factor, regardless of whether the primary factor is a password or a passkey.
And email based account recovery does not make the security advantages of passkeys disappear, which are:
- credential that's guaranteed to be unique
- credential that's guaranteed to be strong
- credential that cannot be phished (due to cryptographic binding to the domain at the time of credential creation)
- changes the incentives for compromising servers (there's nothing worth stealing from the server -- only public keys)
- if/when an app/website transitions to retiring password-based authN, then it will entirely eliminates credential stuffing attacks
And if the account recovery scenario in question is your Gmail or Apple account, then you would need to go through their account recovery flows regardless of whether you were using a password or a passkey:
https://support.google.com/accounts/answer/7682439?hl=en https://support.apple.com/en-us/118574
> there's no a clear explanation
there's. it depends on how the site implemented passkeys.
I'm using multiple devices and passkeys via keepassXC. I haven't lost access or even got locked out of any accounts.
but it's like 2FA, and almost all sites have a clean fallback (backup codes) for 2FA.
> there's. it depends on how the site implemented passkeys.
so. no clear explanation.
the same is true of passwords. some sites provide password reset some don't. how is that not clear?
> some sites provide password reset some don't
I'm yet to see a site that doesn't provide a password reset (excluding websites without passwords). What inane webdev though that'd be a good idea?
I save all my passkeys in Bitwarden and they sync across devices.
Same here, also what if I lose the device?
I can safely write down a password on a piece of paper and keep it somewhere phyisically safe.
Passkeys and 2FA are a usability nightmare if you need to recover, or all the security vanishes if you put usable recovery mechanisms for the passkey or the second factor.
>Passkeys and 2FA are a usability nightmare if you need to recover, or all the security vanishes if you put usable recovery mechanisms for the passkey or the second factor.
Most providers continue to offer email-based recovery in the case that the end-user loses access to their primary factor, regardless of whether the primary factor is a password or a passkey.
And email based account recovery does not make the security advantages of passkeys disappear, which are:
- credential that's guaranteed to be unique
- credential that's guaranteed to be strong
- credential that cannot be phished (due to cryptographic binding to the domain at the time of credential creation)
- changes the incentives for compromising servers (they're nothing worth stealing from the server -- only public keys)
- if/when an app/website transitions to retiring password-based authN, then it will entirely eliminates credential stuffing attacks
password managers do the backup for you based on how you set them up (eg. to your google drive, or to a simple SFTP/FTPS/S3 URI)
those that don't have this built-in (eg. KeePassXC) recommend using Dropbox or some external sync mechanism
but the keys are stored in a file, which you can back up.
> all the security vanishes if you put usable recovery mechanisms for the passkey or the second factor
no, not at all. it still gives you better UX, because when you use the passkey you know it's the site you want to log in to. (because there's mutual authentication.)
2FA secrets can be backed up, and everyone should do that, for the same reason you'd want to do it with passwords.
Passkeys can too, but there it's even more obfuscated than with 2FA.
You do the same as you do when you lose your SSH key. Restore from backup and move on with your life.
Why is there so much misinformation nonsense around passkeys?
How do you use a restored passkey from backup? Aren't they locked to the device?
That's all I want to know. How do I restore from a backup? Specifically, a backup that I make to a medium I control, like a piece of paper or a burned CD-R in a safe deposit box. If I could get a good answer to that, I could be onboard. But from the conversations that I am getting here, it looks like only certain managers allow it, and with device attestation, they could be banned at any moment by any website with no recourse.
> * and with device attestation, they could be banned at any moment by any website with no recourse.*
Isn't this true of any authentication method? It doesn't seem unique to Passkeys.
Now that I think about it, you are right. But if they could ban my use of written passwords as easily as banning my use of a particular passkey device, why go through all the extra hoops to just be as vulnerable as before? This seems like a whole lot of extra work to do that gains me nothing.
If you use Safari, they're locked to all of the devices on your iCloud account, not to a single device.
How? Where are they stored? Which password protects them? How do I back them up? How do you move them to another device? Can I print them out on paper as a last resort measure?
Nobody fucking knows.
it depends on which password manager you are using. if you use Google's then it gets backed up to your Google account.
BitWarden, KeePassXC, and probably a bunch of other password managers have very thorough support for import-export, automatic/periodic backup, sync/merge, etc.
Sounds like something security services would love people to use. Instead of using wrench to extract the password - and distressed person may lose memory, they can just locate the passkey.
Nobody is safe from a nation-state "attack" they'll just go threaten your providers to give up your data. Passwords written on paper are probably safer than a centralized password manager for almost every circumstance other than a government coming after you.
Papers: Safe - yes. Easy to lose/misplace: also yes.
Humanity having millennia of experience securing them: also yes.
I’d like to see them threaten Apple or Bank of America.
My issue is that they're touted to the consumer as secure, and they're not really doing much more than a complex password.
How do you generate a new key if you need one? Same process as a password reset. Does it prevent session stealers? Not at all.
Its "benefit" is grandma can't read it to an attacker. OK, well can grandma click a link and have a session stealer bork her life instead? Yeah, and attackers know that and just shift methods. Session stealing isn't a sophisticated attack, and so all that's being done is shaving a cost on PW resets in the interest of shareholder value, at the cost of security theater and locking up your keys in a single domain that holds control over our access to everything.
There is security value. A passkey will not work anywhere except the actual website. Fake look a like sites can't get the credentials. Evidently they can trick you into authorizing their device.
That's also how any good password manager works. You'd have to manually copy-paste the password to get around the same-site fill restriction (whether it's autofill or manual fill).
Sure? MitM isn't a new kind of attack, and I'd be surprised if the ball-of-wax-and-javascript that is WebAuthn isn't vulnerable to that...
This is one of the key security features of passkeys. I did a little searching and the work around is to do a standard fake website that prompts for your standard credentials. That should be a fairly simple fix. Require access from a new device to be authorized from another source with an explanation that they will never request this info.
I think the intended workflow is you login with your phone and that device is now the authority that allows other devices to issue their own passkeys.
In my opinion it's a bad plan, because it elevates certain devices to privileged status, if you lose your phone you are hosed.
Passkeys should be allowed to be synced between devices and stored on password managers in the cloud. I am making my own password manager for my personal use, but have not delved into passkeys.
Yeah that's all hackery I think, if you read at the specs there is always a device involved, bitwarden and company just pretend to be a device or have an extension that just ignores the spec.
Listening to Yubikey and OnePassword talk about this, they actually say "One Person, One Device". Which really speaks to their failure to understand their users.
Because the original FIDO/WebAuthn standard was built for device bound credentials. They imagined unique keypairs tied strictly to a specific piece of hardware. Synced passkeys were a compromise, mostly driven by Apple and Google, because per-device credentials are too much friction for general use. It's not that they failed to understand users, it's that they incorrectly assumed the level of inconvenience people are willing to tolerate to be textbook secure (the answer is almost zero inconvenience).
The device bound model also completely falls apart in the enterprise, fails to address shared devices and shift workers where employees share the same PC under the same OS profile, now you're back to needing good old fashioned SSO w/ physical MFA (Yubikey) to attest who the user is in addition to attesting the device itself.
Before synced passkeys, the actual standard is a unique key pair per device. The key pair on my phone shouldn't be synced to my laptop, my laptop should generate it's own key pair.
That is odd, I regularly use my Yubikey on multiple devices, that was the biggest draw.
The Yubikey is the "one device". But most people don't buy Yubikeys so the "one device" is, in practice, a smartphone.
Even then, unless you use one for work, where work can issue you a new one if you lose it, you're going to need (at least) two Yubikeys if you want to go that route, because not having a backup is a bad idea.
I would love to see what you’re referencing, can you provide a link or citation to that quote?
the video requires signing up for Yubikey spam. https://app.livestorm.co/yubico-y/securing-trusted-actions-a...
>If I accidentally set up a passkey on my phone (let’s say I use Safari one day instead of my go-to, Brave), can I still log in without that passkey on other devices?
Yes, but you can also add the passkey to your password manager so it's available on all your devices.
>Can I add another passkey on another device?
Yes.
>How many passkeys can I set up for a particular site/app?
I haven't really seen a specified limit on any sites, but also if you're using a password manager it's only 1 passkey for all your devices anyways.
> For now, I’m going to stick with LastPass and use Passwords; because no matter whether I lose my device or not or whether I’m on my own devices or not, I can be sure I’ll be able to get into a site/app.
Your passkeys would be in LastPass as well like your passwords, so arguably the same result regardless of which you use.
>Edit: One final consideration, my spouse and I share user/name passwords for some things (notably Pandora and our Amazon Prime account) since they don’t handle things like family logins well; how do both my wife and I use amazon or Pandora with passkeys? Do we each set up passkeys? How do I get her Pass if that’s not an option?
If it was me I'd add a second passkey to my password manager for your wife under a new entry, and share that entry to her lastpass account.
Or if she's not on lastpass, you could just copy the data from the passkey over to whatever she does use.
> Edit: One final consideration, my spouse and I share user/name passwords for some things (notably Pandora and our Amazon Prime account) since they don’t handle things like family logins well; how do both my wife and I use amazon or Pandora with passkeys? Do we each set up passkeys? How do I get her Pass if that’s not an option?
Lets say it is a android phone. Open amazon app. login in the usual user/password + 2FA (like with QRcode or phone). create passkey. done. This passkey would have been now synced to your google account.
Take next spouse phone. Open amazon website or app. try login it will try for passkey but cannot find it. so
- login in the usual user/password + 2FA (like with QRcode or phone). create passkey. done - Now this passkey would have synced to spouse google account.
In future, assuming you have apple or windows laptop. assume you have signed into Google (chrome). Now go to amazon. It will ask - shall I sign in with passkey. Yes, give your macos fingerprint or windows hello or password of that laptop. login Done magically. You dont even need to remember username or password.
Assuming you both have iPhones. You can sync the passkey to icloud account. And for every new iDevice it will be available.
The main bottleneck of passkey would be that all 3rd party sites will have another non-passkey way as backup to login. I have never seen a website that would say - remove all other methods and keep only passkey.
In a way passkey is 99% convenience. If a hacker would some how get your sms and password they can by-pass.
Thanks. One glaring issue I see is that right now police can’t ask you for your password in the USA (a violation of the right against self-incrimination). They can however get a search warrant for your device and your biometrics, and wouldn’t need your password if they can gain access through your pass key.
If you save it via Passwords app, it'll be iOS / macOS mainly, but you can unlock with any Apple device that supports Passkey / Passwords app (so likely modern + reasonably updated) the easiest. If you want it to work "everywhere" then you CAN use your iOS / MacOS Passkey, it will show you a QR code, some places poorly support this, I believe both devices need bluetooth, and then it will authenticate it.
Linux is the only oddball here, I had issues getting this flow to work.
If the UX for Passkey improves, I will go all-in on it, I'm at the point I'd love to just completely block passwords from accessing my account, unless I explicitly enable it temporarily by logging on via passkey, I wish some sites would let me lock my account to this level, it would be better. Passwords feel like they just wind up all over the web.
Weirdly enough you can store multiple passkeys for a given domain, which can get confusing in some cases if they dont have normal names tied to them.
Edit: Originally I thought Passwords from Apple was iOS / macOS only, but its not! So I have been editing my original message, sorry for the confusion, I had forgotten that I can login on Windows with my Passkeys from Apple's ecosystem.
As another poster noted, you can transfer them out of Apple's ecosystem too!
> Linux is the only oddball here, I had issues getting this flow to work.
Take a guess why.
Passkeys are just a trick for vendor lock-in disguised as a security practice.
They are, however, completely unphishable, which is a big plus IMHO
Firefox just didn't support it cleanly, I think Chrome did, I don't remember. Apparently it's just due to Linux not having a native passkey implementation. Dang.
Edit:
Apparently BitWarden should work, but my particular passkey was not on there.
> Apparently it's just due to Linux not having a native passkey implementation.
Excuse me? The infrastructure for "an apps is trying to login with a private/public key pair, and right now it needs the private key to encrypt some part of the transaction" has existed on Linux since it began.
The problem, as best as I can understand it, is that some/all browsers are not treating passkeys as an extension of the key system that began with ssh(1), even though technically speaking, they are.
Unpopular opinion but correct the whole thing has been designed to lock you to devices they make and have themselves be the arbiter of your authentication.
If that wasn't the intent they could have make the thing work like ssh keys, encrypted at rest, you can take them wherever you want.
It is not Apple's job to implement Passkey into Linux, that is up to the Linux community to build up and figure out, and then for Firefox to implement it on Linux. On the other hand, Chrome just works with it, so maybe Firefox either implements it for Linux in-house, or figures out an existing initiative they could invest resources towards and help to prop up so they can integrate against it on Linux.
My issue is not the lack of Linux support, my issue is the dependence on hardware components, that are distributed by a small group of incumbents, that is pretty much baked into the spec.
What they want is to lock your identity to your android and/or iphone devices.
What are you talking about? I can literally export all that data to another OS or password manager. Takes a whopping single click.
Only to other proprietary systems within the FIDO Alliance that you don't own or control.
Additionally passkeys allow services to detect and ban specific password managers, so have fun when the only approved managers that works consistently across all services are Google/Apple/Microsoft. There is already a list of "bad" clients here https://passkeys.dev/docs/reference/known-issues/
I didn't realize this was supported, I'm kind of favoring Apple's Passwords app since you can lockdown your account and they are very on top of someone accessing anything of yours. Any time I power on an iPad I havent used for months they tell me a new device can read my texts type of thing, which is a nice paper trail.
I wouldn't favor an application that is locked to a big player account (Microsoft, Apple, Google) where a ToS violation for something unrelated may lock you out of all services, passwords/keys included.
Also note this from the spec:
> A Public Key Credential Source’s generating authenticator determines at creation time whether the public key credential source is allowed to be backed up. Backup eligibility is signaled in authenticator data’s flags along with the current backup state. Backup eligibility is a credential property and is permanent for a given public key credential source. A backup eligible public key credential source is referred to as a multi-device credential whereas one that is not backup eligible is referred to as a single-device credential. See also § 6.1.3 Credential Backup State.
* https://www.w3.org/TR/webauthn-3/#backup-eligible
Windows also has the Apple Password app.
https://support.apple.com/guide/icloud-windows/set-up-icloud...
I use bitwarden[0]. It covers all cases and devices in question.
As a bonus, I self host using the open source vaultwarden[1] server implementation, which is packaged in alpine linux.
[0] https://bitwarden.com/ [1] https://github.com/dani-garcia/vaultwarden
I think the point is that Passkeys are not supposed to be as precious as passwords. You're supposed to have a brand new one for every device/application combination. So they are just login cookies at this point, and haven't even come close to replacing passwords because you need to know your password to get a new passkey every time you log in.
Now, is that the official stance? I don't know; but it's _absolutely_ what every current implementation suggests the companies deploying this stuff want.
You can make passkeys better. Like me, you can install a well-funded password manager (well-funded, because it needs the engineering effort behind it to keep up with the ever-changing passkey apis on every platform in the world; screw up and oos, can't log in today!). Then you have one passkey per remote service, and just have to make sure 1password is _always_ installed and perfectly integrated. Easy!
There are a couple of problems I have with that. 1) Many websites limit the number of passkeys I can link to my account. Some only allow 2 or 3. I have more devices than that. 2) If I am supposed to create a new passkey for every device, how do I login in the first place? Most websites currently fallback to password login which defeats the security benefit of using passkeys in the first place.
I currently only use passkeys for a few websites that have awkward password login workflows or do not autofill properly from my password manager. I just have a single passkey for each that is synced via Bitwarden. Currently, I see passkeys as using an electronic biometric lock on the front door while passwords are still regular locks on the backdoor. The biometric lock on the front door does not do much for security when the backdoor still exists and I have come across very few websites that support only allowing passkeys. And those that do still run into problem 2 listed above.
Yeah, I agree. My policy is much the same as yours: set a passkey only when a site makes logging in with a password such a PITA that the PITA of a passkey becomes the easier option. Google comes to mind. They seem to actively not want anyone to log in. At some point sites will start to 2FA you even with a passkey, but we don't seem to be there yet.
For me, it is "how many passkeys can I have for the same site?", and "how do I revoke them?"
Worse, I'm still using LastPass -- but migrating over to Chrome password storage as it syncs between phone and laptop. LastPass doesn't give you the option to not use it for passkeys. It might be the thing that causes me to finish the migration away from it.
I can't speak to all of your browser combinations, but most desktop browsers can present a QR code when logging in with a passkey. I keep my passkeys in a password manager synced between my phone and personal computers. On my work computer, where the password manager is not installed, I can still use passkeys by scanning the QR code with my iPhone's camera app.
(small parenthesis, please consider to _not_ use lastpass given they have had so many security incidents https://en.wikipedia.org/wiki/LastPass#Security_incidents )
It makes sense for a work device that is off network/domain, but then it is your primary/only means of interfacing with services. Then you can consolidate under a Windows Hello passkey or something else.
The second you have a second device to log in from they are useless. The second you want or need to share a credential (smart or not) they are more work than a password.
The passkey trend seems lead by platforms that want to make it easier to get or stay logged in, Netflix type companies that want to prevent account sharing, and those that value convenience (if one device) over security.
I find it abjectly terrifying. Like if I log into your site with a Passkey what happens if my device breaks? What if some big tech company decides to nuke my account for no good reason?
You can store your passkeys in Bitwarden or Keepass vault. Then you can use them through Bitwarden or Keepass apps on any other device. Been using passkeys like this for several years, and it works pretty seamlessly. With Keepass vault, I even have an offline copy as backup.
If you store the key in Bitwarden or Keepass, what makes it different from a password?
The difference is you can't just copy and paste the private key into a phishing website. The login process validates your private key and logs you in.
Also since the service does not store your private key, it is more resistant to data-breaches as that is one less potential breach source.
They are bigger. Not as easy to guess. More like pretty impossible. It's like not letting the user choose the password. That way they can't have a bad password.
But these same services are the reason why my passwords are as short as they are. They made me use 'short passwords' by putting upper limits on them.
Main difference is that my banking website doesn't make me use SMS 2FA if I use a passkey to log in.
> If I accidentally set up a passkey on my phone (let’s say I use Safari one day instead of my go-to, Brave), can I still log in without that passkey on other devices?
N=1 and I'm sure I'm holding it wrong, but I can only log in to ADP to request PTO from my personal laptop because I set up an iCloud passkey, work laptop does not allow access to iCloud keychain, and you can't request PTO from mobile.
Although that's more a failure of your workplace's security policy than of the Passkey itself. It makes sense that the passkey doesn't work if you can't access the place the passkey is stored.
The thing I find burdensome is managing all the keys in a secure way. I think I would want a hardware token to store the keys on, have separate keys for every site, need to back up my keys onto a second token in case the first one is lost, etc. It gets burdensome. At least with passwords you can store them in various ways that are not hardware or software dependent.
Answer to almost all of your questions is that it entirely depends on the service what kind of auth implementation they offer. I personally have completely adopted passkeys and use them with every service that allows it.
I use ProtonPass and have made it the default password store on every device and browser. This way all passkeys get stored in proton and I can login from any other personal device with proton setup.
> ...it entirely depends on the service what kind of auth implementation they offer.
I think that's exactly the problem. These are all answerable questions, but getting those answers is confusing for most people.
Also from experience, most sites will implement it in every wrong way possible.
For example, all the major sites that allow the total of 1 active TotP authenticator app - trying to add one forces to delete the other. Which is fine while you have only one phone and aren't in the process of switching to another one.
With foresight you can get around this since you can reuse the TOTP seed values.
The annoying thing is so many services don't even support TOTP. They either want their own proprietary app, still insist on SMS, some of them even try to get you to use voice prints!
> These are all answerable questions, but getting those answers is confusing for most people.
It's the same answer when someone asks 'how am I supposed to have a different password for every site' and 'how am I supposed to remember a password of X+ characters.' Use a password manager. Pretty sure every major one supports passkeys by now.
So passkeys achieve nothing if you can already use strong, secure, random passwords stored in a password manager?
Write it down on a sheet of paper and put the paper in a safe place. As a bonus, I can have multiple copies in multiple places. It is simple, easy, and I have been doing it all my life. I see no reason why it has to be more complicated than that.
Password managers are themselves cross-device footguns and I could easily write the same headline for them myself. I've been working in tech for 20 years now, and I don't use them.
ETA: Well I do use auto-fill in browsers/mobile, but funny thing about this, I have three running on my phone[0], they all activate at the same time, and they contain mostly non-overlapping set of credentials, and I got tired of trying to sync them together, so I just look up passwords manually one by one in each and use clipboard to transfer the credential once I find it.
And I had to stop using passkeys because they interact with this split-brain system in unpredictable ways.
--
[0] - Specifically: Google Password Manager / Google Autofill / whatever they call it, Samsung Pass / Samsung Wallet (they're sort of but not the same?), and auto-fill built into Firefox.
Password managers for passkeys have a huge problem when dealing with any kind of remote support or working on someone else's hardware - you can't just copy/paste or type in the passkey so you're forced to install the password manager on a family member's/stranger's/employer's PC or do what? I'm not even sure. At least SSH keys have forwarding when you ssh to a remote machine, how do you "forward" a passkey?
With Apple's Passwords app, you can create "groups" for passwords and passkeys and share them with people. Once shared, the passkey/password automatically fills as if it was that person's own.
I have a "Family" group in my Passwords app where I share passwords and passkeys with family members for exactly this purpose.
Don't think it's any more confusing than e.g. logging in with an email address and password, or logging in with email + code, etc. A website's auth is usually a black box that they don't explain, and the only reason people find passkeys confusing is because they've been conditioned to enter passwords instead.
Totally in the same boat, passkeys seem to massively increase the risk that I will lose access to my data.
I've taken up the strategy of telling any less-technical person who asks me about passkeys that they are the mark of the beast, intrinsically evil, and should be avoided at all costs, and I encourage all y'all to do the same.
Maybe, at some distant point in the past, there was a plan for a whole system of intercommunicating implementations of passkeys. That is no longer the case. The moment that they decided to include the information necessary to only allow the use of certain passkey vaults in the protocol, and then use that capability to threaten to lock out certain vaults that dared to let users actually be in control of THEIR OWN DAMN CREDENTIALS, it invalidated the entire project in my eyes. Passkeys cannot be trusted, they are designed to let entrenched powers hold your authentication hostage, and should under no circumstances be allowed to take root in the computing ecosystem.
I use ProtonPass and afaiu it just syncs the passkeys private part everywhere you need it. So it “just works”. This is better than just old fashioned credentials because the passkey only “triggers” on the correct domain, so they can’t be phished by other domains… Right?
Copying / syncing passkeys between password managers is still work in progress, but you can usually work around it by making multiple keys. For important websites, I recommend saving additional passkeys to Keychain, etc, as backup, assuming the website allows that. (It should, but some websites might not have a good implementation.)
Also, nothing says you have to delete passwords (or alternate means of logging in) if you already have them set up. Having multiple ways in will help prevent lockout.
Unfortunately probably implementation specific, but you don't always need to have multiple passkeys. There is cross device passkey login. I had this occur in the last couple weeks. Evidently I had created a passkey on my phone. Logging into that site on my PC, it identified that I had a passkey and allowed me to authenticate using my phone.
I’ve just been operating under the assumption passkeys are gonna lock me out unrecoverably in some way at some point, and have been avoiding them for anything important while allowing them for low-value accounts so they’ll stop nagging me.
I hate that I can’t just put a value in a plain text file somewhere (encrypted, let’s say, to preempt the inevitable and low-value response) and rely on that to work when I need it on any device and interface that can accept keyboard input.
I avoid using them altogether for the same reason. I won't use them for low value accounts because it signals that I think they might be acceptable to eventually require for high value ones. And of course low value accounts have no value so I don't even care about phishing on most of those.
Haha, this thread has prompted me to follow some of the discussion about stupid bullshit like requiring "user is present" attestation and banning passkey programs (LOL wut?) if they lie about it, or resistance to allowing exports and portability.
I'm now on team "I am outright anti-passkeys and hope they fail and everyone pushing them cries a whole lot about it and never gets over it".
I’m 90% certain most of the push for passkeys is to prevent paid account sharing.
You can add as many passkeys as you want and you can still have password logins too.
I have come across many websites that limit how many passkeys I can add. Some have only allowed one or two.
Yeah, it's bad implementation on the websites but the protocol doesn't have a limit.
I recognize the point of your post is more about the lack of clarity and details around passkeys. That's real, and I don't really have an answer for that - other than, I think maybe the quest for making them simple and "just work" has maybe made them nebulous enough that we've wound up in the current situation where a lot of even technically savvy people don't really understand them. But I feel like answering your questions might sort of help explain why that's the case, so I'm going to take a stab at it:
> If I accidentally set up a passkey on my phone (let’s say I use Safari one day instead of my go-to, Brave), can I still log in without that passkey on other devices?
Assuming you have LastPass set up to be an iOS password manager, and it fully supports iOS' passkey implementation: when you create a passkey in Safari, it will ask you if you want to store it in LastPass or in the iOS Passwords app (previously known as iCloud Keychain). If you say LastPass, then it's up to them, but I assume it'll sync to all your devices - it's how 1Password works. If you were to accidentally say Apple Passwords, it'll sync to all your Apple devices automatically, and you can either use Apple's password browser extension on Windows, or you can use the "another device flow" I'm about to detail.
> Is there a way to ensure that passkey can be used on other devices?
As mentioned above, passkeys are intended to sync via your password manager of choice as the primary use case. If for any reason you don't have that passkey synced to that device, _and that passkey is on a mobile device with a camera_, most browsers will give you the option to scan a QR code with your phone. This kicks off a flow that will authenticate you via your phone's biometrics or passkey, then use Bluetooth to first ensure device proximity and then handle the authentication exchange. In the case of iOS, this includes any passkey-supporting password manager, so the passkey itself can be in 1Password; it doesn't have to be in the iOS password system for this to work.
When I first read the above, my hackles were raised given how well Bluetooth operates at times; but every time I've used it so far, it's been fast and flawless. Still, I can see a lot of scenarios where this might not work - e.g., the first one I thought of was a public computer at a library where Bluetooth might be locked down; corporate computers or remote servers could also be troublesome. As far as I know, passkeys don't yet have answers to those scenarios; other than to just use your password + 2FA as you would without a passkey.
As far as I know, both of the above apply to every passkey-consuming site.
> Can I add another passkey on another device? How many passkeys can I set up for a particular site/app?
This touches on your last paragraph, where it indeed could change based on the website. In my experience, every website where passkeys are fully supported - e.g., not ones that are using passkeys as a substitute for FIDO/U2F keys - has let me add multiple passkeys and have not _appeared_ to have a limit. I typically will create a passkey in both 1Password and Apple Passwords just to have a backup, and I can't recall any cases where that's been a problem. Still, I can't say for sure that isn't a problem on any website.
I went all in on trying passkeys when they started to be an option, and I don't have any notable regrets. For me, passkeys have generally worked well when the site is designed to use them well; and at no point have they been a _major_ hindrance. That isn't to say there are _no_ annoyances, though:
- Most websites that support passkeys tend to use them as a replacement for both the password _and_ 2FA, which makes them more convenient. However, a few - Amazon being the most notable I can recall - only use them as a second factor, which just makes them feel a little useless.
- A passkey can _also_ be used as the proof of identity, meaning you can log in in one fell swoop and don't need to enter a username or email address, which is IMO the best showcase for passkeys. Like above, this makes websites that ask you to enter an email address before letting you use a passkey also feel annoying.
- Most web browsers I've used support the QR + Bluetooth flow I mentioned above (otherwise known as Hybrid Transport or caBLE) without issue; Linux has been the odd duck out. Firefox doesn't seem to support it at all on Linux, and Chrome-based browsers do but sometimes are missing what they need and in that case don't show it as an option. Since I sync just about every passkey with 1Password this typically isn't a problem; the exception is the passkey for Apple Accounts, which Apple creates automatically, and (AFAIK) doesn't allow you to enroll your own. Apple Accounts are the only service I've found that does this, though.
- Some websites seem to only offer passkeys as an option if you're on a mobile device, or at least did so at the time of enrolling. eBay and PayPal I think are the two that jump out at me as having done this. Why they did it this way instead of simply detecting if the browser supported passkeys, I have no idea.
All of the above issues have gone down over time, so it's generally been a net decrease in friction over time. And, at least as far as I can recall, passwords themselves continue to be an option in every instance I've enrolled a passkey. So if you like your passwords, generally speaking, you can keep them :P
> passkeys are intended to sync via your password manager of choice as the primary use case.
The sync was actually a compromise to the standard. The idea was unique, device-bound credentials. One person, one device. The private key/passkey on your phone should not be the same one on your laptop, or your tablet, etc. Each device was supposed to have it' own unique credential.
Allowing sync is a security downgrade to the standard, in terms of threat-model guarantees. Pure WebAuthn credentials should be sealed in hardware (TPM or Secure Enclave or equivalent) and be mathematically non-exportable which guarantees zero remote blast radius, an attacker must physically posses the device.
Allowing sync and storing passkeys in a password manager reintroduces cloud account compromise risk and recovery flow hijacks. You lose non-repudiation.
Still more secure than passphrase + TOTP, but doesn't eliminate account takeover attacks against your cloud credential vault, which purely hardware based, per-device credentials do.
I don't get it. How does every device combo having a unique key pair help with security? They can all log in, right? So all you need is to compromise their session and you're in, whether they share the same passkey or not.
And if you're compromised in such a way that an attacker could steal your password then wouldn't they be able to just hijack your session instead?
Passkeys protect against credential theft, not session hijacking, two different parts of the stack. Passkey's only concern is initial authentication, it was never meant to provide any sort of protection against session theft. RFC 9449 Proof of Possession is how you prevent session hijacking, or session binding with a client-side TLS certificate.
Device-bound passkeys take care of non-repudiation. With synced keys (e.g., 1password), an account compromise of your vault hands the attacker all your credentials, the private keys are in the vault.
Device-bound keeps the private key sealed in the TPM (or secure enclave), the key cannot be exported, so it cannot be extracted remotely. Even malware on the machine, can hijack your session, but it cannot exfiltrate your private key, TPM won't release it to the service without user verification via biometrics, yubikey, or a PIN. There's also an attestation chain that breaks with synced passkeys. The attacker has no way to get your private key, so the only way to compromise the account is, yes, session hijacking, or physical access to the device with the user present to pass the biometrics check.
> Still, I can see a lot of scenarios where this might not work - e.g., the first one I thought of was a public computer at a library where Bluetooth might be locked down; corporate computers or remote servers could also be troublesome.
None of my desktop computers support Bluetooth. Neither do my wife’s.
Why not use passkeys in LastPass? Then the passkey travels with you to your devices/apps.
oh good I thought it was just me who didn't understand them
I'm using bitwarden, but it's possible to use passkeys from multiple devices and if it's not available for whatever reason, you can just login with username/password/token/biological probe/whatever you used before. As an example: GitLab gives you both options right from the start, so you can use whatever you fancy in that particular moment.
Did [someone from the Working Group] ever back down from their implied threat to blacklist Bitwarden for allowing for the sharing/export of passkeys?
That really rubbed me the wrong way, and smacked very heavily of "the big players (MSFT, AAPL, GOOG) can do this - you can't".
I know KeePassXC faced the same threat. I don't know whatever became of it.
Passkeys basically MITM the 2FA process so that they can track and deplatform you with a single click across all your accounts.
The biometric verification also allows to confirm that a certain person is holding the device, and they can easily be matched to existing passport/travel databases.
Great system if the good guys have it, a bit problematic if it's abused by nepo kids to hide their crimes.
> Passkeys basically MITM the 2FA process so that they can track and deplatform you with a single click across all your accounts.
I use passkeys with a physical authenticator. How do "they" track and deplatform me with a single click? Can you explain?
The service can use the use the attestation feature to block passkey providers that are deemed undesirable for whatever reason. Hard not to see eventually only major providers being accepted, even things like Microsoft services requiring Microsoft Passkeys using the Microsoft Passkey App which you're now required to have on your phone. Or worse you now need Symantec Passkeys to login to Symantec services (using that example since I believe Symantec had a ToTP App you needed to reverse engineer to extract the ToTP seed from if you wanted to use a different Authenticator)
If a service wanted to do that they could already do that, you even point to an example with a platform requiring their specific app to use the account. I've had banks which required me to have their own time-based code physical security tokens to log in, isn't that in the end the same?
This thing you're talking about isn't inherently a thing about passkeys. If a service wants to remove your ability to log in to their service they can do it in a million different ways.
Also, the above poster said:
> deplatform you with a single click across all your accounts
"They" could do it across all your accounts with a single click. If service A decides to require attestation, how is that now affecting all my accounts?
It’s really not that hard.
Most of your devices are in the Apple ecosystem and when you are prompted to create a passphrase it will ask you to put it in your iCloud Keychain. Boom, now it is available across all of those
This is how it will work for most people who don’t care about security and just casually use their devices. My boomer mom does this. It’s better than the notebook full of handwritten passwords she was using.
You have chosen lastpass and a multi-ecosystem environment with windows and multiple browsers on each. You have chosen complexity and this is not a limitation of passsphrases as they have been designed for a more common use case.
I use Linux and apple. I have chosen protonpass for my vault. I just tell my OS to save the passkey there and everything works pretty well. If not, my password is right there as fallback. It’s really not that hard.
Proton Pass is on the official Passkey client naughty list[1]. I hope the services you log in to don't choose to ban it because of those big, scary X's.
[1] https://passkeys.dev/docs/reference/known-issues/
The fact that services can ban passkey providers is a major red flag in the protocol and the real issue that nobody talks about
well, people are talking about it but it's not making a difference https://lucumr.pocoo.org/2025/9/2/passkeys/
This is why I am so concerned about passkeys. They could be a good improvement, but in practice I already see how it's going to result in Google/Apple/Microsoft/whoever seizing even more control.
The document there is laughable too, because KeepassXC is listed as "not performing User Verification" when it demands manual authorization per request. But this isn't good enough for the passkey people. Ultimately, I see any FOSS option being effectively banned from most services and all important ones. It's a parallel to how you must now be on Cloudflare's nice list or be banned from the majority of the internet.
Yeah they're really trying to solve problems that should be solved at a technical level with soft solutions in porcelain. See also this issue asking keepassxc to disable plaintext exports, which is completely technically feasible
https://github.com/keepassxreboot/keepassxc/issues/10407
The author of this ticket seems to come across as an arrogant know-it-all that thinks "the threats i thought of (or personally face) are the only threats that are significant, fuck anyone in a different situation."
I proudly print my entire KDBX file including passkey private keys and I encourage my elderly parents to do so too.
Lightning strikes (and assisting people with cleanup and repair from them) have taught me that there are definitely a class of threats that will leave me with paper but possibly no technology until I can go buy a cheap laptop to restart my digital life, SO BEING ABLE TO BACK EVERYTHING UP IS ABSOLUTELY ESSENTIAL.
His website says he's in Boston, so I seriously doubt he's ever seen what lightning can do or dealt with a hurricane or tornado.
In general, if you're in the FIDO Alliance and had anything to do with the kind of micromanagement that passkeys can allow, FUCK YOU. Go get a job at Walmart as a greeter. We'll all be better off.
That issue was exactly why I took up my "Never use, under any circumstances" stance on passkeys. It is an indictment of the entire passkey project. I now routinely tell the less technical folks in my life, when asked about those weird passkey options, that they are the mark of the beast, and should be avoided at all costs.
(I might be wrong, please correct me if I am) What I'm gathering from this page is that the Passkey spec can specify whether the app handling the passkey should prompt the user for biometric scan, PIN code, etc. but some apps simply ignore that flag. This makes sense though. I've already logged into my password manager and it hasn't timed out yet, so why would my password manager prompt me again? I'm glad that they don't prompt me again when I'm already logged in. I don't see this as a problem.
Your understanding is correct and I agree with you. The Passkey spec authors, however, think services should be allowed to ban your client for behaving this way:
> [When UV is required, KeePassXC must request user verification or not handle the request]
> This implementation is not spec compliant and has the potential to be blocked by relying parties.
https://github.com/keepassxreboot/keepassxc/issues/10406
> > This implementation is not spec compliant and has the potential to be blocked by relying parties.
The only conclusion I can come to when it comes to this and the earlier kerfuffle regarding being able to export the plain text of passkeys is 'the spec is bad and you should feel bad'.
Right, not only are you authorized, but you are also prompted to manually complete the request, which will fail if you do not accept. However, this isn't considered sufficient by the passkey people, who do in fact want you to retype your password at each prompt.
What if I lose all my apple devices? House break-in and they steal my mac and my phone?
You're basically fucked even if you buy a new one because you need one of the other two to log in.
Then you'll login to your Apple iCloud account using your password.
Passkeys are just passwords that require a password manager; you can't login to a password manager without something outside the password manager, usually a password. (That's why they call it "LassPass" and "1Password"; there's one last password you'll still have to maintain.)
No password manager tries to get you to login with a passkey without setting a password, for precisely that reason. Apple, Google, and Microsoft do invite you to login to their password managers via passkey, because it's convenient and unphishable, but they always also allow you to login via password (or "backup codes", which are just backup passwords).
No technology in the world can protect you against every threat model and unlikely scenario.
What if the robber hits you in the head and you get brain damage and forget your password?
That is not a rare threat model. Many people use iPhones and Windows computers. Fortunately, Apple has released iCloud Passwords which lets you access passwords and passkeys from a Windows computer.
That's the point: passkeys, and even 2FA, address rare and unlikely threat scenarios, while defeating most common use cases (delegation by sharing credentials), and making people vulnerable to most common threats (like, losing or breaking your phone).
A password has the best recovery process. Period. Write it down somewhere. It's up to me, no third party.
I had more trouble with a failed 2FA than with a password.
Master password to password vault stored on metal, buried in my backyard and I tell a family member where it is in case I ever get brain damage
Family member gossips "that crazy [deejaaymac] always burying secrets in the backyard..."
Or straight up betrays you (you slighted them at some family event)
If you marry someone you don’t trust, you’re going to have a lot more problems than password compromise.
these questions all have easy answers that could be quite easily discovered by simply trying to use passkeys, instead of trying to find reasons not to use them.
You shouldn't be forced to discover what capabilities exist by brute force. Just freaking explain it.
But since there's a potential nonzero risk of permanent account loss, I don't want to experiment, and since I can still log in with email/password I'm going to keep doing that.
It’s quite the opposite. Passkeys are phenomenal for a lot of consumers. Based on this thread, it’s the engineers who understand authentication in the first place and have their own system (eg password manager) that are confused.
Consider a user in the Apple ecosystem: you are already conditioned to just do Touch ID or Face ID when asked. I was on Amazon the other day, it prompted randomly for “want to set up a passkey to sign in easier”? I set it up and now I can easily sign in to Amazon on my mac or iphone with zero friction.
For the normal consumer this is not a replacement for “dig out my password manager and copy-paste/autofill my password”, it’s a replacement for “oh it’s prompting for my password again” -> proceed to type your shared password for all sites.
A password manager let's me use my service specific credential from any device, securely and decentralized.
Passkeys lock into a specific device and seem easy until you need to use another device.
But instead of being a credential you own and control, across what could even be a local password manager, it's one password to everything. Maybe it is more secure than a regular password in some cases but it largely seems like a worse fix than existing tools for a problem that has better solutions.
Passkeys do *not* do that. I use 1Password to manage my passkeys and they are all synced across all my authenticated devices where I installed 1Password.
You can choose either if your password manager supporte Passkeys
1password and KeypassXC both support passkey syncing across devices and operating systems.
I put my passkeys in my password manager and it works fine.
I keep all my passkeys in 1 password. So magical
The moment my mom needs my help to login to something because she clicked the button but now it's expired / she got a new phone / raison du jur, I will be totally unable to assist her. It's a horrible concept being foisted on unsuspecting victims.
I refuse to be part of an "ecosystem".
The first time I got asked by a site if I wanted to use a passkey I immediately googled what they were and... never really found the answer, not in the 5mins I devoted to being distracting from my task at hand anyway.
"magic fairy dust to login to apps." is the most accurate description I've seen.
Unlike a password or a TOTP token, I know how those work, I know its my responsibility to keep track of them. If my passkey is on my phone what happens if I lose my phone? Do I need a unique passkey per device? How do I rotate them? What if a device gets stolen?
I'm so glad I'm not alone in thinking these are so poorly explained.
Think of it like SSH authorized keys but automated for the web. Instead of storing the keys in a file; it stores them in a hardware security module (yubikey, or TPM).
Registration generates an asymmetric key pair between your passkey, and the website. Login is the usual challenge/response process. The biggest step forward is phishing resistance. A fake login page can relay a TOTP code, but not the passkey challenge/response.
100% had said something to the tune of this months ago in another thread on passkeys
> Passkeys need a marketing campaign and UX overhaul. I’m a technical guy, but I really don’t understand what the fuck is going on when I use a passkey. All I know is one day it appeared as an option and it let me login to things. I don’t really understand where it lives, what device it’s tied to, how scanning a QR code on Google Chrome on my phone magically logs me in, etc etc.
The user was not educated on this. Hacker News is the top 1% of computer power users. You gotta understand to someone’s grandma or mom or brother who works in real estate none of this makes any sense nor will they educate themselves on what it is.
https://news.ycombinator.com/item?id=46301585#46303892
You can use both hardware bound passkeys (where you may not even be able to read the secret so you probably would want to add multiple device passkeys to a site)
or shared passkeys (where the private key can be synced through something like a cloud service across your devices, see Bitwarden, iCloud)
> hardware based
Sounds good until you realise theres no way to transfer/back them up and you are limited to 100 [1] (previously 25?).
Personally my password manager has almost 4x the entries so hardware passkey solutions are a joke leaving users with single option - upload their keychains to ms/apple/etc clouds where they can be requested by any gov under the sun for x reasons.
[1] https://support.yubico.com/s/article/How-many-accounts-can-I...
Like some folks already commented here, even as someone who has been working in tech for 20+ years, I find Passkey confusing. I understand the key aspect in computer science term, but I don't know how to use it across devices. Another big worry is that if I tie that to a physical key, then I might lose it (because it's physical) and never get it back.
Exactly, I always refuse to add a passkey because I'm afraid I won't be able to easily login again. Also, I don't want to be locked in to a vendor.
use an open source password manager that supports them.
as others mentioned, there's BitWarden (cross-platform, self-hostable), but if you want something simple there's KeePassXC (and you can put the store file on a dropbox shared folder)
The cabal of evil behind the passkey project actively have KeePassXC on their naughty list fore deigning to allow users to access their keys, and specifically included in the standard the means to discriminate between different passkey vault providers. It is the opposite of an open system, and cannot, under any circumstances, be trusted. Do not use passkeys, tell other people not to use passkeys, and make sure to not let shills astroturf conversations about passkeys unopposed.
You can use a passkey that's tied to a Yubikey.
The problem here is i want to have more than 1 yubikey, so if i lose it, all is not lost... I can't do that with the current implementations unless i present N yubikeys to every new account i make. Which makes an off-site backup yubikey impossible. With my current yubikey usage with password store, my "offline" yubikey can be brought in whenever i want to decrypt the passwords, including ones inserted while the key was in storage.
Also yubikeys have limited passkey slots (100, 25 with old firmware)
Also, where do I store the backup Yubikey, or any other pass key owning device for that matter? It has to be easily accessible to set up the pass keys, but also safe from accidents like house fire.
There's a strange tension where I want to use pass keys because they are easy to use but also they are easy to lose, so I choose a KeePass synced over cloud and deal with a bit of a hassle by having to copy/paste my passwords.
I think technically you can just register the public key of the passkey and only need it on-hand for login
You can register multiple passkeys for a single user, there is no lock in
a big problem with passkeys is that there is a lot of flexibility in how it is rolled out with a given site or app. Some sites ask your browser for a passkey as soon as you hit the login page. Some sites you need to enter your username/email address first before you're prompted. Some sites a passkey satisfies both password + second factor. Some sites you need to enter your password and the passkey is the second factor. Some sites you don't need a password but do need the passkey + a second factor (usually SMS)
This is on top of the confusion around enrolling passkeys in your device and synchronizing them
I am a big passkeys fan, and use them on every service I can, but they leave a lot to be desired in terms of user experience. Not sure all of them are solvable, either. The platform vendor side can be fixed: vendors can better integrate with each other to make your passkeys available on every device. But, the issues with how they work across sites and applications is probably not solvable
FWIW: I find passkeys to be a very simple and easy to use concept.
Simple: it's like a password that I don't have to type in
Easy to use: because I use 1Password and just have it installed on everything. On Android, it can be set as the default passkey provider so, even on mobile, I am using passkeys shared across devices.
Is this "less secure" because I'm sharing the keys through 1Password. I suppose, at some level. But before that, I was simply sharing passwords through 1Password in the exact same way. So, I don't think my security posture has changed any.
What has changed is the UX and IMO for the better. Now I don't have to generate/fill/copy-paste text strings for user names or passwords. 1Password knows what site I'm on and usually responds automatically when I'm in a passkey context. If I have more than one passkey available, because I have multiple accounts (for something like Google Workspace), it shows me options and I pick the one I want.
Honestly, it's mostly a "just works" system and I like it a lot better than passwords.
YMMV, of course.
My problem with passkeys is that "don't have to" is actually "don't have to, and couldn't if I wanted to".
OK now say you're on a work/library/friend's computer and you want to look up an account in 1password on your phone so you can type in the password. Passkeys don't support this very basic and common workflow. Meanwhile there's no real security benefit over password manager generated complex and not reused passwords.
I use a passkey with discord on my phone. If I want to log in to discord on a computer it shows a QR code on the page/desktop app and I scan it with my phone to log in. I could see this become a pretty common pattern.
I like it because I can use discord on even a pretty untrusted computer without providing it any credentials or access to my passkey, and then later when I'm done I can revoke the session.
Ok but now do a service that doesn't support that, whether or not it might in the future 'become a pretty common pattern'.
so you need to have discord installed in your phone.
now multiply it with every web site you want to access.
This is why you should use physical tokens like Yubikey.
But don’t log in to important accounts on a public computer, like ever, unless it’s a dire emergency.
If I'm on someone else's computer and I want to use a passkey on my phone, the computer will display a QR code. I scan the QR code with my phone, the phone signs the login request and posts it to the service's callback. Then I'm logged in on that new device.
If my phone's camera is broken but both devices have bluetooth, it can do the handshake over bluetooth.
If I'm on someone else's computer and I want to use a passkey on my authenticator on my keychain, I'll just plug it in and then tap the button on the authenticator.
Meanwhile, if I logged in with the password and the account only has a password then they have a full copy of my entire authenticator to the account. With the passkey, once the session is invalidated the access is gone.
This is good in theory but in practice doesn't always work. It isn't just a QR code like I would like it to be, its a QR code and you need bluetooth. Maybe there is a hypothetical world where bluetooth drivers actually work on windows machines and can connect to a mobile device seamlessly but that is not my experience. Across multiple windows machines i often have a problem where windows just decides the machine doesn't have bluetooth, and will refuse to display the QR code without any explanation. It doesn't tell you that bluetooth is the problem it just says "insert a hardware token to authenticate".
I would love for this feature to actually work but every time I've needed it to it hasn't. Literally this week I only had a passkey on my phone, but at the time I was in Linux with Firefox, and afaict the qr code workflow basically requires either chrome or windows 10.
I use this feature a bunch across dozens of different Windows and Mac devices from various device vendors with multiple Android phones and seemingly never had an issue.
But I'm also a person who generally never experiences the issues some people have with Bluetooth in general. If I ever have an issue with Bluetooth on a computer, I swap out the wireless chipset with an actually good one. Its almost always just bad hardware. I've only had to do that a few times in the last decade though, more modern WiFi/BT chipsets are generally pretty OK. Its the old ones that are near worthless.
Although I will say most of the time I just plug in my USB authenticator. I normally only fall back to the QR code if I don't have my keys on me.
And as an edit, I wasn't aware fully that the QR code is to help assist the BT handshake, I had assumed it was posting a signed request back to the service. My bad, my above comment isn't completely correct. Thanks for cluing me in to the BT requirement for the QR code path.
From what I understand the Bluetooth is required to ensure proximity. It isn’t actually used to transmit anything of vital importance. The QR is doing most of that. It’s just there to prevent scanning the QR through a video call and logging in from elsewhere.
Which I’m sure is great in theory. But IMO just adds even more complexity to a system that already has several moving parts and is more fragile than it should be.
Does the apple passwords app work this way (log in to a public machine by scanning a QR code?)
Passkey on an iPhone, logging into a public-ish terminal by scanning a QR code? Yes.
In fact, if you have your Apple Passwords app set to sync through iCloud, you can:
- Make a passkey on your Mac for a site in the Passwords app
- Go to a different computer (a friend's or whatever)
- Attempt to log in, choose use another device, it'll show the QR code
- Use your iPhone to scan that QR code and sign in, as the iPhone has the passkey synced through iCloud
Note, the same kind of thing is also possible with other password managers as well.
This is a big problem I have with "just works". Everyone is used to services only allowing a single password. I know the answer to this, but it's not clear in the marketing or how it's explained to normie end-users: Won't creating a passkey erase my password? How do you sign in on another device? Won't that change the passkey and lock me out from the first device?
it just a lot of complexity and i don't want to deal with it but i have to because of all these dark patterns. sometimes i enable pass key and don't even notice.
I try to use passkeys when possible as I'm also a 1Password user, but this hardly "just works". Firefox on Windows often triggers the Windows password manager for passkeys (some how this is only on some sites), making it impossible to use 1Password.
I've seen the same on Android too, and I think there's a difference in how Chrome and Firefox are handling the requests.
Then you get in to cases like a Microsoft Account. You need to use your account to log in to the device that has the passkeys, so the workflow never works properly and you have to fall back to another method.
Amazon is another one. If an app like Libby redirects to Amazon, I get a different, passkey-less password prompt, so I need to have a password readily available.
It's great when it works, but honestly 1password with straight up username/passwords is probably just a better UX in the end.
Everything you said is _also_ true if you use a password manager than can interact with the browser (which you're already doing).
Plus, that doesn't have the negatives/limitations of passkeys.
But you still have all the negatives/limitations of passwords, of which there are tons.
This. Honestly, most of the arguments I read against passkeys just sound like “old man yells at cloud.”
It’s not that difficult. Spend 10 minutes researching the topic and you’re fine. Passkeys are so much more convenient than having to use passwords. When implemented right, it’s literally one click from opening the login page to being signed in. On all of my devices.
With physical U2F key, I could explain to my 78 year-old-parents "this is a physical key needed to access your account. Think of it like the front door key to your house. Don't lose it or lend it to anyone. We should have a couple of backup keys too." And they got completely understood and added it to all of their accounts. This was not hard. People assumed consumers were too stupid to do this without even giving them a chance.
> Don't lose it or lend it to anyone. We should have a couple of backup keys too.
Honestly, this is one of the two things that make me hate passkeys. The key management is a high-friction pain in the ass.
I never found a comfortable way to ensure all of my accounts had more than one U2F key associated with them. I always wished there was a way to have 2 physical U2F keys, one on me, and by adding one to an account, both would work.
As is, I had to either:
- Keep both on me, and add both - I am at risk of losing both at the same time
- Keep one one me, one in a safe - I have to keep track of which device I've added to which service, and periodically take the backup one out of the safe and iterate through the "new" services
I was never satisfied with either approach, so I ended up with an OTP app with backups.
And/or maybe the vendors were annoyed that people would lend the keys anyway, refusing to accept that it is normal because that's how delegation of authority works in real life too. House keys are also things you often lend to a third party that you want/need to access your house in your absence, and in fact making extra duplicated for trusted third parties is normal.
Software vendors continue to refuse to support, or even accept the existence of, this entire class of use cases for regular consumers (they are, however, more than happy to milk enterprises on convoluted implementations of those).
Sure, but i would never want a physical key to something important. Physical keys get lost, so the front door spare is under the flower pot.
And now I have another thing I need to carry everywhere.
I still can't even get a physical key anywhere in person. You can certainly get phones just about anywhere, but you can't get any FIDO keys at brick and mortar, last I checked.
Until I can tell Grandma to "go down to Walmart and ask the man at the electronics counter for a Yubikey", we still have a few issues.
(No. Ordering online is *not* a valid option in this scenario. If I want to order a Yubikey to this address at this exact moment in time and space, Amazon won't deliver one to me for at least six days at the earliest, based on their rural delivery estimate. Replacing a key is basically impossible.)
UX is not the problem with Passkeys. Passkeys were designed to align with the interests of BigTech, who are bent on stopping the abomination that is general computing devices in the hands of consumers and forcing them into their walled gardens. The language that is used for taking away freedoms is the same as always, safety. Where we ended up with Passkeys is an operating model that is suitable for corporate devices, i.e. the user can only do what the owners of the device allow them to. Suboptimal UX is downstream from that problem.
I think about this a lot when using our corporate SSO tool.
When I hit the button to log into Slack, there are like, 3 popups in succession - the last one ultimately asking for my fingerprint. Then when I give it, there is a flurry of web pages that get loaded and redirects that happen until finally Slack pops up again.
There isn't any realistic world in which I check each window to make sure everything is happening right and I am not being MitM'd.
I'm a fairly technical person, and I would be unable to perceive the difference between a really tight security environment and my computer being hijacked.
Aren’t passkeys intrinsically resistant to those attacks? With hardware security keys, the private key remains on the device, never crosses the network, and is cryptographically bound to the site being authenticated.
The point of passkeys is that you don't need to. Unlike passwords, your session cannot be hijacked because the thing that you give your fingerprint cryptographically verified the requester.
The website for my HSA required me to set up a passkey last time I logged in. I set it up on my work laptop and my work password manager, which means I can now no longer access my account from my personal computer. This is fantastic, just what I wanted
And then you call them up, and they allow you in after asking some identity questions, and you learn there's no real security.
This is exactly a scenario that worries me. Proponents of passkeys imply you can setup a bunch of passkeys. Evidently that's not always the case.
"But that's just a bad implementation, many other sites do it right!"
And many sites block paste from password managers. Passkeys have so many ways to do them wrong that we're going to see all kinds of new and exciting failure modes that lock you out of your account in the future.
Are you also using HealthEquity for your HSA? I'm the same boat, they're forcing passkeys on me. I can still login using my employer's SSO but I've been putting off setting up the passkey until I have to.
yep
I think the irony here is missed.
I mostly love passkeys to be honest even though I use multiple browsers across multiple devices and OSes (iOS, Chromebook, Linux, macOS, Xbox, etc). Bitwarden’s support is (finally) pretty good.
My problem is that I manage a lot of accounts for my family which makes passkeys a nightmare. If I’m out and a kid gets chucked into a login flow that happens to require a passkey, I can’t text a password and TOTP code to the adult with them. I know that’s terrible opsec but the reality is people share accounts and passkeys are designed to thwart that.
My take: (1) I've had passwords handled pretty well for a long time now: same password manager for something like 15 years; (2) companies are pushing pretty hard to get me to use passkeys instead.
From (2) I assume that the companies see benefits to themselves. I don't care about benefits to them. I don't see much in the way of benefits to me, so I'm not changing anything if I don't have to.
I'll admit to not having looked into passkeys all that much. Someday, I might. But for the time being, I don't see much point. I imagine that eventually I'll be more or less forced to deal with passkeys in at least some contexts. Will leave that for later.
For now, it's all a big "no thanks" from me.
I think portability is very confusing: they rolled out passkeys with no device portability (device-bound) and only recently added it (CXP). So for anyone with multiple devices it was a relative disaster - why should my Windows PC hold a device-bound passkey to anything? How do I login on Linux or macOS? Picking a password manager to do portability also means another kind of lockin, though maybe you can live with that kind if you really trust the company. Even so, the password managers all seem to be competing to have relaxed security, so that vault and account passwords are the same, or you are asked to type your master password into a webpage - surely we didn't replace per-site passwords with this?
Yes, a bit of a mess. As the only practical way for most to use is with a password manager. So essentially, all your accounts still have a real password, just you enter that into your password manager app. So if your device is every compromised and someone has your master password then you are screwed.
And of course, passkeys on most all sites don't really improve security since someone can just choose to login with user/pass instead since presumably very few sites allow you to have just passkey.
Also if you use a password manager you may get locked into using that platform. Or ideally using a third party one but then having to pay a subscription, or using an open source option that is not ideal for the average person.
If one uses a passkey as intended and without a password manager and the site truly only supports logging in via your passkey, for all the touted benefits of passkeys, that would be a nightmare if a person loses access to their device, etc.
Throwing my hat in the ring, I think passkeys were also invented by engineers with zero understanding of the average developer: https://etodd.io/2026/04/06/passkeys-are-too-hard/
Reminds me of Yishan Wong's description of OpenID's failure:
https://www.quora.com/What%E2%80%99s-wrong-with-OpenID-Why-h...
> I run a tech company and I have no idea what a passkey is and at this point I’m too afraid to ask
I thought I was the only one!
I find passkeys.. ill say interesting.
I can have the most complex password and create a passkey, but a windows machine could allow a 4 pin digit to access the passkey.
lol it seems a good technical writing opportunity someone should take on.
also appreciate your attitude, better than "I work in tech for xx year, i don't understand yy, so yy must be bad."
This comment section is the best example of all time of the arrogance of Big Tech and its employees. Please try to take a second thinking outside of your bubble before commenting ridiculous stuff.
Yes, as a wealthy American, you "live in the Apple ecosystem". 99% of the world doesn't. And guess what, they're affected by passkeys all the same. They use a Windows laptop, and either an Android phone or iPhone. A lot of people even have an Android phone and an iPad. And no laptop at all. But at work or school they have to use Windows.
It's quite simple. Besides people "living in a single ecosystem" (discussed above, this is almost nobody), passkeys are only viable (i.e. not very painful to use) if you use a dedicated cross-platform password manager. Yet people who use those - which too is a globally negligible percentage - are exactly the people who tend to have near nothing to gain from passkeys, and only to lose. The majority of them is tech-savvy and they use auto-generated unique passwords. In that scenario, the minuscule improvement in security is meaningless and not worth it.
Ironically, this comment section shows exactly why passkeys are a shit show. Half the people here are exactly those who are coming up with this shit in their FAANG jobs, happily part of the global 1% (of which their tech-illiterate grandma too is part of), and they have no idea or care in the world for the remaining 99%. Unless of course this was simply a land grab for lock-in, which is about as likely.
Passkeys are just SSH keys in how they work. We've been doing this since the 90's. The only people that use SSH keys are the Linux savvy users and those who are forced to via an enterprise solution for vaulting.
The average person doesn't know anything about this stuff nor do they care. I also have yet to see a Passkey solution that didn't also have a password on it and a nice little box letting people choose to use the password instead of the passkey. They just added a new layer on top of all the old ones and created confusion. Now people use password and passkey interchangably in conversations and no one knows what they are talking about.
I can find my ssh keys in `~/.ssh`. No such place exists for passkeys.
Thats because the people behind passkeys are paternalistic and don't trust users. I had an argument with one of them a few months ago.
https://github.com/keepassxreboot/keepassxc/issues/10407
https://news.ycombinator.com/item?id=47189749#47193048
My read on it all is that FIDO is stuck in some sort of groupthink. They don't feel the boots on the ground confusion around passkeys being opaque. They only care about phishing and being called "insecure" and don't care about anything else. Hence why WebAuthn has additional weird anti features like AAGUID for provider authentication.
Another one of those ridiculous threads is saying you gotta have support for nonsense like user presence verification.
https://github.com/keepassxreboot/keepassxc/issues/10406
> Thats because the people behind passkeys are paternalistic and don't trust users.
To be fair, trusting users with passwords/credentials is how we got into the mess of phishing et al in the first place.
The phishing resistance on fake websites is largely a function of the fact its an ssh key and you can't man in the middle those after first setup because you have known_hosts, which in the case of passkeys gets replaced with the website certificate technology.
The baking in "which authenticator is storing this passkey" and "require user to provide biometrics/pin to verify presence for this passkey" and "don't make it easy or possible to export passkeys" behaviour is more just control.
I guess it sort of helps if the threat model is complete remote code execution inside the victims brain because you got them to export their keys to you, but it seems more useful for websites and governments whitelisting what hardware and software they deem acceptable.
> I guess it sort of helps if the threat model is complete remote code execution inside the victims brain because you got them to export their keys to you, but it seems more useful for websites and governments whitelisting what hardware and software they deem acceptable.
Reminder that Facebook has warnings and prevention mechanisms to avoid users pasting malicious JavaScript into the console on Facebook.com (which would exfiltrate session cookies).
Preventing users from accessing these keys directly makes sense!
It depends on the app you’re using to save passkeys. Use Keepass and it saves the passkeys into kdbx file (similar to SSH keys).
Aren't they effectively locked in the database of whatever password manager is used? I know you can export them, sort of, but that feature may blacklist your password manager and make it useless. Are they portable? I thought passkeys are locked to the device.
I was answering to the storage part. Blacklisting is the attestation part which is definitely a concern. Again, you can use passkeys as a yet another way to login. You can still use passwords. It doesn’t have to be one or other.
I can pull up all my passkeys in 1Password or Bitwarden without issue.
I thought your "with issue" typo was quite pertinent to the whole discussion lol
I would feel a lot better using SSH keys rather than passkeys. At least those are understandable.
They're literally the same thing, what are you on about?
Apparently not: https://news.ycombinator.com/item?id=49007750
They might be the same thing cryptographically, but passkeys remove your ability to manage, move, or back them up at will. I can trivially move any single SSH key I want between my Mac, my iPhone, my PC, my Raspberry Pi, and my backup media. Can I do that with passkeys? It seems to depend on which storage mechanism I choose, and even then it's often a matter of dumping the entire password database to plaintext first.
Edit:
Oh yeah, I can also share SSH keys with friends and co-workers. I can freely choose which SSH key to use when authenticating and I can have an arbitrary number of SSH keys for a given server on each machine. Some of this stuff is esoteric, but some is not. Most of the stuff I can do with SSH keys I can also do with passwords but not with passkeys (or at least not always). Finally, as many others have mentioned, the attestation stuff is really ugly and takes control away from the user entirely.
SMS 2FA was also optional everywhere until it wasn't.
It is still optional most places.
Stop thinking of them as alternatives to passwords. That is something they do, incidentally. Really, they are an alternative to normal TOTP 2FA (and shudders SMS 2FA). Those were already dependent on an app on a single device, or a password manager. And now, you can have the security of that, automatically used with biometrics. It is only because they are so secure, due to being a cryptographic key, that they can replace passwords.
They really should come up with a way to transfer them across devices/password managers though.
If you want a consistent, and seamless authentication experience, then one party has to own that experience. Go federation/SSO. Sign into everything with microsoft, or google as your identity provider, and live with the privacy implications.
Passkeys are great, and they take a significant amount of work away from the user, and make them much less prone to phishing attacks while also not turning their entire online identity into the property of google. I've had much more luck with onboarding non-technical people into a yubikey vs a password manager. Platform authenticators tend to trip people up. However, the process of adding a new key is getting much more consistent, and legible to people over time, and things will settle on platform authenticators rather than external physical keys for most use cases.
I really don't get passkeys and how they are supposed to be safer.
Currently I save all login tuples to Bitwarden and store OTP secrets onto Aegis. Could have been 1password and authy, it's irrelevant. The thing is, I only get pwned if both are compromised.
Now with ubiquitous passkeys in Bitwarden if someone has access to my vault unencrypted it's already endgame.
I keep seeing people working on Passkeys get real defensive when told they don't make sense to people.
I've worked in tech 12+ years and I _hate_ when a Passkey prompt comes up, its only ever slowed me down.
But the devs who work on them are quite rabid, and keep dismissing real criticism of their implementation.
Passkeys are a political play aimed at bolstering government support. They’re the privacy sabotaging arm of Digital ID. They go hand in hand with “age” verification. It’s all the same play. Get your identity, get your access credentials, give it to the prying eyes.
Passkeys work well when you have password managers with multi-device sync. While it is indeed trivial to get one, consumers don't like password managers in first place. And it is very hard to make person use password manager, instead of his john1988 type of password
My biggest issues with Passkeys is how inconsistently they are implemented and how opaque they attempt to be.
I understand SSH keys, I've been using them for decades, I know where they live, I know how to secure them.
Passkeys are murky as fuck. Is your PW manager supported? Do they sync? Where are they stored? How can I move to another PW manager if I want to in the future? Can I have more than 1 passkey per site? And the list goes on.
I _know_ some of you out there can answer some/all of the questions above but it's mostly on a per-site basis. Passkeys take too much of the control out of my hands and I don't like that.
Even more than that, I hate how they are trying to be pushed on me at every turn. Login -> Want to save a passkey (but they never call it that, they use some other confusing euphemism)? I click "No" and then it proceeds to pop 1Password's UI, then I dismiss that and it opens Chrome's passkey save UI, I dismiss that, and then it opens the OS's passkey UI. It's incredibly disrespectful and unclear.
I never use anything but 1Password but somehow everyone (OS and Browser) try to reach their grubby hands in. This is what scares me, I don't like having to be on high-alert to not accidentally save a passkey in Chrome or Safari and not realize until I'm on a different device and notice it's not in 1Password.
Lastly I trust the developers implementing passkeys... none, I trust them none, zero, zilch. I don't trust them to pick the right defaults, I don't trust their recovery options, and I know they will always pick the configuration that benefits them and not me.
No, for now I'll stick with my as-long-as-you-let-me-make-my-password random passwords which I never copy/paste into random website and be perfectly safe, thank you.
I like the authenticator option. I literally cannot understand if that's the same thing as passkeys.
Passkeys are a vector for locking your logins to Big Tech ecosystems. They support device attestation, which means the service you are logging in to can require you to only use certain Passkey clients such as those provided by Google, Apple or Microsoft. The Passkey spec authors also maintain a list of "naughty clients"[1], which are clients that allow the user to manage their own data how they want. Services could choose to block those clients for "security reasons," justifying the decision to force you to use one of the Big Tech providers.
Until device attestation is removed or strongly curtailed in the spec, I suggest you do not create any Passkeys. Which sucks, because it's otherwise a pretty cool tech.
[1] https://passkeys.dev/docs/reference/known-issues/
More sources here: https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
I find Google Password Manager makes passkeys pretty easy to use. As long as you don't accidentally create a passkey some other way. Hopefully websites will adapt to the reality of how people use passkeys in practice and some of the UX weirdness around them will disappear over time.
One annoying thing though is that while they recently added password sharing, they don't allow sharing passkeys. Basic passkey sharing would be nice, but it also seems possible to implement fancy sharing features that wouldn't be possible with password sharing. Things like sharing one time use passkeys or time limited passkeys or limited access passkeys or secure revocation of shared passkeys. I hope people are thinking about this.
Considering Google's track record of locking people out of their accounts it'd be very risky to trust them as your password manager.
Security people don't care about usability. They genuinely think we are all CIA field agents.
Look I remember my PIN everything else is in Firefox password manager.
> Security people don't care about usability.
I spent a long time working in the network security field, and you speak truth. The perverse thing about it is that security people should care a lot about usability. If the scheme isn't usable enough, people will figure out how to bypass it or aspects of it.
The technically weaker security scheme that everybody accepts is more secure than the technically stronger security scheme that everybody tries to bypass.
Obligatory https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
It's a shame, because WebAuthn is really great technology. But tech companies are botching the rollout.
I will never understand how a small group of tech savvy people are heavily confused and against a simple and more secure system.
You want anecdotes? Ok. I’ve had elderly adult relatives who aren’t good with their devices tell me unprompted they’re using them and like them when I mentioned the word out loud to myself using my phone around them.
These are people who don’t know the difference between apps and the web. Who have 200 tabs open because they don’t know what tabs are so a new one just gets opened automatically all the time. Can’t tell some websites apart. Who change their passwords on every login to some sites because they can’t get sign in right.
Yeah if you want to write them down or refuse to save passwords outside text files or demand they live on a security key on your keychain you’ll have a hard time. You’re being 0.0000001% of the user population. You’re not representative.
They are a MASSIVE UX win. A MASSIVE security win.
I’ve logged into my work computer with a passkey on my personal phone, no issue. It’s fine. They’re backed up locally. It’s fine.
The biggest problem, which is getting better and somewhat a transition problem, is sites using terrible UX to trigger the workflow. Those that follow the suggestions or close to it are great.
I love passkeys. I just don’t get the confusion.
I've yet to meet a non tech person irl who uses them. I went through the laborious process years ago setting my parents up with 1Password. They find passkeys very confusing addition. I have yet to see the massive UX win. If that were true I don't think we'd be having this conversation. Good UX becomes the natural state of things and we don't even notice. I've had trouble myself setting up passkeys correctly with my 1Password. This never happens with traditional passwords and 1Password
The win for passkeys is login with faceID. That people actually use.
My usernames and passwords auto-fill with faceID already. Lots of forms even (somehow?) auto-submit after that, don't even have to press a button.
My elderly mother accidentally created a passkey (in Chrome) for one of her accounts. Normally, I try to keep a copy of her accounts and passwords in case she forgets them so I can help her out. With the passkey, this is impossible.
She doesn't know how she created one, she doesn't know what it is, and I don't know how to explain to her that if her PC dies I won't be able to help her log back into her account. I'm not even sure how I'm going to migrate this thing to a new PC for her.
I’ve read all the answers. I still don’t get it. I find it WAY more complicated than copy/paste or a browser extension that does that for me.
I hope it won’t become mandatory. (I honestly doubt).
I think the problem was that there wasn't a "Best Practices" way of using them when they were launched, which really prevented describing them in a consumer-friendly way.
And web site implementors couldn't follow that golden path, or describe the golden path, so there's fragmentation in usage and meanings and practices, making it far more confusing.
I love passkeys, I want to eliminate any and all password-based logins and switch entirely to passkeys. It's such a better experience, it's a "physical" key that can be backed up to multiple devices, and thinking of it like a key for a physical lock really gets at the core of its capabilities. But locks can be used in many many ways! Maybe you need to open the lock and still tell the guard a password, which is weird, but how most websites still operate.
I don't use passkeys because I can't tell if they're a one-way door. If I use it once, can I still use passwords to log in in the future?
I also don't understand how the system works when things go wrong (someone hacks your account, etc.). I don't even understand all the ways things could go wrong with passkeys.
Seeing the comments here makes me realize I'm not stupid or ignorant for not understanding these things. Some people do understand them much better than me, but there is no universal answer that emerges after sufficient study.
I will continue to stay away from passkeys.
This is mostly a complaint about bad copy/explainers in Google's UI. Passkeys, properly implemented, can be perfectly consumer friendly (e.g., Apple Touch ID is delightful).
I don't know everything there is to know about passkeys or anything, but my reaction to most of these comments is "You're passing yourself off as someone who has relevant opinions about security, and you can't possibly imagine how these things work or how they're useful? Come the fuck on."
Passkeys are basically session cookies that are signed by a secure element in one of your devices at the time you log in. That's it. They cannot be phished because there is no password to steal. If I had to guess, the basic flow is something like this:
1. When the passkey is created, the device's secure element coughs up a public key or something to the server representing itself as a trusted device
2. When a user logs in, the server issues a challenge (basically a random number) to the device and says "sign this with a private key that corresponds to one of the trusted public keys I have"
3. The secure element signs the challenge and sends it back
4. The server goes through its list of trusted device public keys until it finds one that verifies the challenge response. If it finds one, it logs you in. If it doesn't, you don't log in
Step (1) is probably bootstrapped with a username/password and second factor like SMS 2FA, OTP, or email 2FA.
Even if this isn't exactly how they work, it's a plausible implementation. Nothing about this requires vendor lock-in. The various secure elements that can produce passkeys come from many different places, so I'm sure sufficiently motivated open source people could create a firmware TPM that is certified for use with passkeys or something if they cared enough.
At Caution we -exclusively- allow passkeys. The entire database is user ids and public keys. If it leaks, it would only be mildly annoying.
If you are confused about digital passkeys, you can use a physical yubikey or nitrokey and tap it when it blinks. You can treat them like a credit card or house keys.
Asking people to keep up with and remember passwords is and always has been the thing that was invented with zero understanding of the consumer brain.
> -exclusively- allow passkeys
Isn't that just a euphemism for "we mandate passkeys"? Saying 'exclusively allow' draws the reader's attention to the positive (allowing!) while de-emphasizing what's not permitted.
Regardless, I think it's a lot less of an issue for services exclusively oriented at people in tech instead of just everyone. Even then, there is a barrier to adoption besides just understanding it, which is relying on new software or owning a piece of hardware. It's a lot messier, while text remains universal and has no dependencies.
I only use pass keys by storing them in 1password. Then I don't have to worry about the whole "lose/broke/replace a device" thing, which is inevitable. Then just be really good about keeping your backup codes etc with 1pass solid.
We've all been through at least a couple rounds now of the security industry pressing us to change how we log in, ostensibly in our best interest: impractical complexity requirements, 2FA, "magic links," ridiculously short session expiry, whatever this bullshit is with the username and password on separate pages that make your password manager less convenient.
The only observable outcome of each of these changes has been making these products less convenient for us to use. At this point I don't think I am alone in being knee-jerk opposed to any further "improvements." I have yet to see a website make a case for a passkey being more convenient than what it is replacing, so I will continue opting out of them as long as I am allowed to.
the real achievement of passkeys is making people nostalgic for passwords
I just stick with TOTP.
Passkeys are so, so, so bad. One of the worst things our industry invented. The sooner sites start leaving them on the wayside and just go back to TOTP, SMS, and Email codes/links, the better. These work. We solved auth. Its fine.
I don’t understand this point at all. I think the author has himself confused with the average consumer. For the first time in a decade or so you can buy a PHYSICAL key and use it to sign into websites. I can explain this to any grandma out there. Likewise, I’m an Apple user. Once you’re in Apple universe passkeys are extremely easy. Tap your thumb on the scanner, done. Now we can put on the tinfoil hat and say how this fosters vendor lock in yadda yadda but the last thing I would say is that it has terrible user ergonomics. LOL
> Once you’re in Apple universe
And there's your blocker. Being limited to only devices from a single vendor is horrible, and a firm no from a lot of people.
> Now we can put on the tinfoil hat and say how this fosters vendor lock
The fact that you call it a tinfoil hat type issue is just insane to me. Literally every person in my household has some apple devices and some other ones (android, windows, etc). And some of them have switched back and forth.
Plus, the "ergonomics" of logging into a website on a random device to check something are awful.
> Being limited to only devices from a single vendor is horrible, and a firm no from a lot of people.
Maybe for a lot of tech people, I don't think the general public understands the risks enough to care.
I literally presented you with the solution in the sentence before. Buy a usb c dongle key. You pay 20 euros to NEVER have to remember a single password ever again. Seems like an ok trade off to me. Likewise you can register multiple passkeys for multiple devices, so long as you do it in sequence (first Apple, then Android) etc. Really it takes very little getting used to. Ever tried to fill out a crap password form which wants 7 special characters but no dashes but uppercase but not uppercase Y and so forth.
How does that USB-C dongle work on my corporate computer that has USB blocked? How does it work with my iPhone or my iPad or my Kindle?
Maybe it is easy to explain, but passkey promoters have clearly failed to do it. I don't think a single person I know in real life uses one.
> For the first time in a decade or so you can buy a PHYSICAL key and use it to sign into websites. I can explain this to any grandma out there.
What would you answer if grandma asked you what happens if she loses her physical key?
You’d think a head of product at a tech company would embrace a “it’s literally impossible to have your password stolen if you use this” technology.
You can still get your session cookies stolen. If you have good password hygiene passkeys only protect you in extremely niche scenarios.
if you have good password hygiene is doing a lot of work here. such a large population of the world does not have this, credential stuffing is a huge class of vuln
Another noteworthy annoyance is the increasing number of services that try to aggressively push you towards passkeys, without you ever asking.
Every other time I open the Costco app (needed to walk in to the store, since I don't carry my card and they refuse to provide Apple Wallet integration) I get asked to switch to passkey, without a way of saying "don't ask me again".
If you're in any position to determine this in your company/software, please stop this pattern. Give users the option to say "stop asking me about passkeys".
I find it difficult to explain how to use password manager to non-IT person. Whatever I say, they say it is not secure. No amount of explanation will change their mind. They prefer to keep their passwords in their physical note book hidden in the safe (yes, they open the safe etc each time they need to log in somewhere when they get logged out).
As someone with ADHD a passkey is something I can lose easily and I don't want my accounts to be tied to any specific device. What if I have to upgrade my laptop tomorrow because one I use got bricked? Sounds like an absolute nightmare.
Password on the other hand I can remember for dozens of services, each very long.
If the person you describe really is doing that for all their passwords, then they are correct. Their password store is more secure than a password manager by nearly every metric that counts.
The one thing I would ding that approach on is recoverability, though. If a fire burns that down, it's gone.
They should buy a Yubikey (a physical key) and keep their passkeys resident on that. Then they can truly keep that physical key locked up in their safe. And it is truly safer than their physical notebook because they are safe from being tricked into entering their password in the wrong place.
How do they tell their significant other how to logon to a shared account when they aren’t together? How do they use the Yubikey with their phone, laptop and tablet conveniently?
I mean, they're right. I wouldn't trust any online password manager even if it was iCloud.
It just so happened that Microsoft sent an email today to our M365 tenant administrators that SMS and voice for 2FA is being removed 1-Feb-2027 and that automatic enrollment to passkeys starts 1-Sep-2026. Bring on the passkey overlords. Although, LLMs say that passkeys are superior to passwords since it includes a public/private key setup with the private key saved to a device that requires a PIN or biometric to access the private key.
That's if you're using Authenticator.
The use of a passkey doesn’t require Authenticator or other OTP app. Gemini said that an OTP app can be used as a vault for the passkey, but it’s not the mechanism that permits the check of the private key. Rather, that’s the PIN or biometric. Now, perhaps I don’t understand your statement and you can clarify if that’s the case.
Clarification: Microsoft Authenticator.
You can’t use any random password-manager with passkey support.
I use Bitwarden for everything and have to have MS Authenticator installed just for this 1 login.
Super annoying.
I have Duo in our environment. Authenticator not required.
How is one supposed to let an LLM log in with passkey?
Why not use SQRL instead?
I do not understand all of the drama surrounding passkeys. They work flawlessly for me on all my devices. Maybe that’s because I’m all-in on Apple devices, but I have yet to have a single problem with passkeys.
Ah! Like Pgp
I find it annoying that gmail has simply decided that my unlocked phone is more secure than my computer.
Passkeys? That shit that's not a password or a crypto key that I never use?
The cumbersome and poorly designed workflows surrounding passkeys are a significant hindrance to their adoption as well. It surprised me how bad they were when they emerged -- it was as if the UX was intentionally designed to kill passkey adoption.
One of the worst technologies I've had the misfortune of being forced to use honestly. It's always confusing and always breaking or not working as I expect across my devices?
The fundamental blind spot engineers have had with every authentication protocol for 30 years is forgetting that trust must be mutual. The lone exception has been phishing prevention with user-selected avatars, and that didn't last long.
Every advancement in "security" has assumed the service needs to more strictly identify the customer, without caring about the customer's trust for the service, or experience with performing the identification ritual.
So when your bank asks you for a code or your mom's maiden name, they never offer anything to verify they are who they say they are. whenever I ask they say "of course we're from chase, we just called you", without realizing how absurd that is.
Now Passkeys suffer an even worse dilemma. Now the customer has 4 dimensions of tools to record & use in order to log in. Did I use email, google, facebook, apple ID to log in? Did I save this code via phone, text, authenticator app (which one, there are multiple incompatible ones)? Did I use a passkey ? where is that passkey located? my phone, my browser storage, my authentication extension.
We started with a single dimension of email + password to log in. Now it's an entire decision tree that has to be recorded. How do you even record this?
This is absolutely absurd!I thought engineers were tested for scaling during the interview process. This protocol doesn't even scale to a single site.
I'd like to try passkeys out. I actually tried again on Amazon in response to reading the comments here. But it just.... doesn't work?
I'm on a laptop running Ubuntu, I use Firefox as my browser, and I use 1Password as my password manager. I have both the browser extension and native Linux application installed, and they sync/communicate with each other (so if I unlock the native Linux app, the browser extension also unlocks).
When I open my Amazon.com item in 1Password, it has a helpful link to https://passkeys.directory/details/amazon which tells you clearly, step-by-step how to set up a passkey. Great! I love clear directions.
But when I get to the step when I click the "Set Up" passkey, Firefox gives me an address bar pop-up saying "Touch your security to continue with www.amazon.com".
Huh?
I don't have a security key. My laptop does have a fingerprint reader, which I use to unlock my screensaver (and it's integrated with some KDE keyring thing), so I tried putting my finger on that. Nothing. I opened the 1Password extension. Nothing there, just normal view of my login info. I opened the 1Password native application. Nothing there either.
Maybe it's a Firefox issue, or a Linux issue? So I tried setting it up on my phone (running GrapheneOS and their Chromium-based browser), which has the 1Password app installed. I logged in, and this time got far enough that 1Password brought up a prompt asking "Do you want to save this passkey?" I tapped Yes, and it then immediately told me "Unable to save passkey: For security reasons, 1Password did not save this passkey. The associated URL for this passkey does not match the selected app." So... does that mean 1Password is refusing to touch the passkey because it didn't come from the com.google.chrome Android application?
This whole experience has re-affirmed my skepticism of passkeys in practice. I think it would be awesome to have public/private key security on my online accounts. I think it would be great if I could log in without having to copy/paste passwords (when autofill doesn't work, or for TOTP codes). But I have zero confidence that this opaque stream of bytes will actually work to get me logged in to my account. When the 1Password input field detection fails, I sigh, copy/paste my username and password, and then forget about the mild inconvenience after about 30 seconds. I don't even want to think about what would happen to an account if the only way to log in to an account was via passkeys.
Passkeys do have drawbacks and tradeoffs, as has everything, but my god did I feel the energy of „lol I’m so bad at math” in that tweet and a lot of „lol smelly nerds” in replies.
> Imagine you’re a boomer and you just figured out how to store your passwords
i'm gonna stop you right there
I don't know how to rationalize it: is passkey so good that even the banking apps start pushing it, or is it all a big conspiracy theory with a hidden agenda?
Passkeys were invented so hacked sites could brush off their leaks with "no credentials were leaked" and minimise any regulatory fines. This is the reason why its being pushed by the big players.
Additionally this puts the same players in control of your logins - want to sync your passkeys? - enable "iCloud Keychain", or some other 'trust me bro' app that will 'securely store/sync your data' - no thank you.
In perfect world users should be able to generate a certificate, upload it to a couple nfc capable ubikey like devices that blow a fuse afterwards preventing from additional writes/reads and use that to login to every app ever. You would buy such devices in packs of 3, upload same cert to all, hide the other, burry the third.
My tinfoil hat take is that there's significant interest to keep everything digital, always-online and connected to the major providers, so it can easily be snooped by five eyes using their omnipresent backdoors.
Passkey biometrics also allow you to confirm certain person is holding the device right in this very moment, and not receiving a TOTP via walkie-talkie. Especially important for kinetic sanctions.
If you check out their Terramare group of companies those guys are still using typewriters. Unless you're US/UK millionaire I recommend to stay as analog as possible with physical password book and TOTP/yubikey.
Same with the push for "post-quantum crypto" and elliptic curves. I feel my systems get significantly more attention when using 8k RSA than any of its modern replacements. While I love wireguard the transition to ED25519 felt way too smooth..
the fact that some nebulous "group of companies" still uses typewriters does not mean that all modern cryptography is flawed
Diversity is resilience; no need to standardize on curves or "post-quantum" IBM bullshit if other approaches still work perfectly fine.
And if the pros are using typewriters in 2026 it's not a signal for me to put even more eggs into the US-megacorp dominated basket who treat me like an NPC who can be droned at will.
An important skill to develop is determining whether somebody is bullshitting you. Because it would be impossible for any one human to perfectly understand all of these concepts, right? So when I read this person's blog post, I felt I could trust him, based on what I know about work he's done previously. I'm not saying you should trust me on this, or even blindly trust him, but look at his body of work, and the sources he cites, and make the call for yourself: https://words.filippo.io/crqc-timeline/
What the hell are you talking about? What pros use typewriters for what (to write code?)?
I get reluctance about being dependent from the US but your reason seems a bit off
I think there are probably sinister motives behind some of the push to pass keys, but you'd think that if that were true, they would make it really quite easy to add one and to use.
That is not the case. The entire setup/enrollment/add a passkey to your account processing is DMV inspired.
Its a lot easier to track email and phone numbers used across multiple sites than it is passkey used on multiple sites.
Consumer passkeys are just an extension of the OMB Policy Memorandum M-19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access Management (dated May 21, 2019). It is ultimately part of anti terrorism efforts with regard to banking and fraud. Think of this as consumer computer version of the scene in the movie The Baader Meinhof Complex when the cops are discussing a proposal for electronic data processing. "According to a poll by the Allensbach Institute, one in four Germans under 30 sympathizes with the RAF. That's nearly 7 million people. That amounts to an enormous pool of sympathizers, which makes the search for perpetrators extremely difficult." It signals the end of publicly available general computing. This was always inevitable, the mob cannot be trusted with weapons of mass destruction. Computers = Guns
Passkeys are a mitigation against users being bad at password hygiene and phishing being a real issue to users.
You can't phish a passkey, and you don't rely on the user providing you 'hunter2' on every site.
As for vendor lock in? No. The specs are open. You can run the code on a microcontroller, or, you can keep it in your arm with something like the Vivokey Apex. Note that the FIDO2 for the Apex is an open source Javacard applet.
The UX on the other hand is not great. If you have a password manager, your OS may prompt you which target to store the passkey with.
> As for vendor lock in? No. The specs are open. You can run the code on a microcontroller, or, you can keep it in your arm with something like the Vivokey Apex. Note that the FIDO2 for the Apex is an open source Javacard applet.
That is not true. Passkeys support device attestation, enabling websites to lock you out if you don't use their approved devices. Which is happening with all the big platforms right now.