hckrnws
Passkeys were invented by engineers with zero understanding of consumer brain
by ksec
by ksec
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?
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.
"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.
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.
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.
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.
Those of us who are not comfortable with that and want to keep our credentials offline and sync/backup them ourselves have questions about how the registration/backup/sharing flows work exactly.
I see this as part of a trend together with remote attestation, age verification, CSAM scanning, restricting sideloading, etc that will lead to most interactions over the internet only being allowed if big tech and/or government can verify the participants, the contents, and the hardware and software used.
Even among techies, many support these developments, so it is just a matter of time before we have no choice but to join the former group.
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.
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.
Later I tried to sign into my Playstation account on my computer and I couldn't. It said I needed to use my passkey.
I went back on my phone and deleted my passkey.
FWIW, Nintendo seems to have nailed the concept of passkey. I can sign in anywhere. If I'm on a new device, i just use my email password and 2FA.
I dont know why so many vendors find the need to complicate this. A secure solution implemented poorly can potentially be worse than an insecure solution.
One more anecdote on that front — I worked the help desk at a medical school during college. The IT department had their fun password requirements (number, special character, blood of a virgin, change every month, etc). Every single person who came to the help desk had their password written down on a sticky note on their laptops. These were med students , doctors, staff... everyone.
At some point these admins have to ask themselves whether they're actually helping people be more secure or if you're just making them jump through hoops.
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.
I thought I was the only one!
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.
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.
For that use case, they work fine, and they create enormous lock-in, because now moving out of that ecosystem breaks everything. One might argue that that means they're perfectly engineered for what they are meant to do...
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.
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.
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.
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-...
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.
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.
All my passwords and SSH key are already in Bitwarden. When a site starts supporting passkeys, I add that to Bitwarden as well. Now, instead of logging in by auto-filling my username and password, I just press the passkey login button (that hopefully exists) and click on the Bitwarden popup to select the account. It's less button presses for me, and I cannot be phished, nor can my passkeys be leaked on the dark web. All thanks to some fancy cryptography.
Okay, sure, if someone steals my Bitwarden vault by snatching my laptop while it's unlocked or something, I end up pretty screwed. That security aspect did not change, so I still use TOTP for all important services.
Also, I've made one invite-only web app where single-use invite codes and passkeys are the only ways to log in. It was not too hard, it was fun, actually. And I get the peace of mind that account sharing is pretty much impossible were a bad actor able to get their hands on an invite, as is hacking other people's accounts.
(Okay, I concede that I've had to help multiple people who find passkeys confusing as a result of this whimsical decision, and that it just might be that nobody is using my web app for real. So I'm just speaking from nerd privilege here... But it works well, trust me!!)
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.
Haphazardly implementing passkeys also has big problems - one vendor I use implemented them rather badly and randomly one day, completely removing the previously-solid password/MFA setup they had, replacing it with a "you are required to confirm on your phone with no other alternative" passkey, which was really annoying. I don't like my logins messed with. Passwords/MFA, while not perfect, work very well for most people, myself included. Passkeys still feel like they are in a very immature state.
https://www.quora.com/What%E2%80%99s-wrong-with-OpenID-Why-h...
however, lately the anti-bot/spam shenanigans from big tech has ruined any ux work they have spent trillions on.
<rant>
one fine day, i was trying to log into my google account at google's office. for some reason their internal wifi was serving the internet through a corporate vpn, which was based out of the US. this tripped their security system, which then made me jump 3-4 hoops to log in back to my account. i recall sms verification (where you send them a code), some part where i had to scan a qr code and open on my phone (not logged into google btw), and the usual 2fa, among others.
likewise ticketmaster asking for verification for a decently used account over the years out of the blue. this is when booking a new ticket from a residential internet without any shady business. was made to reset my password three times in a row, and still got blocked!!!
</rant>
the false positive rate of these systems have reached a boiling point at some instances. yet they don't seem to stop the spammers and scalpers, but cause great pain to regular folks who don't pass the sieve. passkey-based verification is just a symptom of the larger problem.
PS: don't even bother using a non-normie browser, as it is a sure-shot way to get restricted, even on this website. it is as if we are all using tor browser if it is not the latest chrome.
Yes, you still have your 2fa and password, but you create a fast path in addition to it when you get in.
It became even more useful once I stopped insisting they have to go into 1password
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.
Also I find it a bit frustrating when people say password or otp just works. No they absolutely do not work. Even technical people on here get phished all the time even with otp.
Passwords+TOTP have that universality going for them that you can always move away to a different password manager/do without one if you ever want. With vaultwarden and that dependency/liability cut off, passkeys have phenomenal UX, especially coupled to a SSO/identity provider like pocketId.
I think the confusion with passkeys comes from that fact that everyone wants to own you so you have to be mindful if this passkey is being stored on the OS, the browser, sync'd between devices through google or apple, etc.
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.
Because of this, I will not use passkeys. It's a slippery slope. Once we're all on passkeys, website devs won't resist enabling the remote attestation bit, locking out linux users.
They really should come up with a way to transfer them across devices/password managers though.
I hope it won’t become mandatory. (I honestly doubt).
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.
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.
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.
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 think my problem with passkeys is the same as with almost everything today: if I lose my phone, my digital life will be almost as difficult to recover as if I lost my ID and my birth certificate at the same time. Yes, that's why you don't create one passkey (phone), but maybe two or three (browsers), but that's mental load on myself -- I don't even try to explain that stuff to my parents, even something as (somewhat) easy to use as a password manager is out of their scope. Add TOTP and passkeys on top of that and you've got perfect security that no-one in their right minds is using. No idea how to resolve the problem, but it's not by shoving a solution down our throats with a vengeance.
Whoever makes these boneheaded decisions (SMS 2FA only, hardware/cloud passkeys only) should not be allowed around engineering authentication for the public!
Yeah, I went there! Back off! Get off your high horses and eat some humble pie!
Look I remember my PIN everything else is in Firefox password manager.
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.
The only confusion I have with them is around when they are used just as a 2fa (most cases) and when they can replace passwords completely (just one click and you're in)
Unfortunately very few services offer #2 not sure why
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.
Love: I truly have redundancy for most critical accounts, meaning I have 4 separate passkeys assigned, each not tied to one SPoF -- one in 1Password, one in iCloud -- both synced everywhere I logged in and if I'm ever banned/locked out of both of them somehow, I still have two additional USB keys (token2) as a fallback.
Hate: every fucking service seems to have different idea on how to implement them, whether to allow them as the only factor, how many to allow to have in any particular account.
On a separate note, for the hw side of things I'm kinda sad that old yubikey nano approach when the token is just sitting flush on the side of the laptop and I tap it occasionally is just dead, because every vendor moved to mandatory PIN to store passkeys on hardware tokens. I get the rationale but still.
It's a shame, because WebAuthn is really great technology. But tech companies are botching the rollout.
https://forms.gle/wmaydkzmUp2eKfJG7
Original post: https://news.ycombinator.com/item?id=47852849
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.
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".
Something like a yubikey makes sense for this until you lose it and your fucked. From what I understand you cant clone a yubi key to keep a backup somewhere safe.
In the end the solution will be some sort of cloud based storage for these keys where the NSA can have easy access.
I would be much more comfortable with passkeys and 2FA if there was almost always the option to log in with just a password as long as an email gets sent to me (perhaps relevant that I have paid email, not Gmail) stating I logged in to site XYZ without 2FA. Not a "click button to confirm you want to log in" email, just a "hey this happened" email containing a Shaggy link, "It wasn't me." Bonus points if that site's account settings (e.g. 2FA) cannot be changed as long as I'm only logged in with a password[+].
The odds of me not having a device to receive the email at the same time someone guesses my password and causes rapid catastrophic damage[++]... I would need to be specifically targeted or unlucky beyond the normal expectations of unluckiness. (Much more likely: I'd occasionally discover which sites have bad security practices or that I need to be more resistant to social engineering or more careful in public spaces; guessing a long generated password in just a few attempts when the password is never shown on the screen would be impressive!)
I've lost count of the number of times I need to enter a password using a unknown machine, log into my Bitwarden server, copy/paste the necessary password, ... "okay now you'll see a popup on your Totally Breakable Losable Connectivity-Unreliable Android phone"
-----
[+]: account info can't be changed w/ only password... unless I provide some verification ranging from personally appearing at an office with ID for money-related accounts to verifying ownership from a backup email address for low-stakes accounts like bulletin boards.
[++]: short of guessing my Bitwarden master password, which is one of the carveouts for "always always 2FA" and "several alternative, secure backup login methods, at least one which does not require technology"
2. Profit
So Amazon did not understand FIDO, but J random webmaster is supposed to understand passkeys?
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.
... of the human brain.
I store passkeys in a device-independent way, in KeePass using the great actively developed KeePassPasskey extension, because my threat model allows storing password and 2FA for the same site in the same place (or 1st factor when an account is passkey-only, i.e. passwordless). And I sync that between my primary computer and the phone.
I have backups of my KeePass database in a few places (that don't require a passkey to log in) so I am able to regain access to core services in case both my devices fail at the same time. Although it's easy to trap yourself in a circular dependency.
i'm gonna stop you right there
[dead]
[dead]
[deleted]
[dead]
[dead]
[dead]
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..
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.
That is not the case. The entire setup/enrollment/add a passkey to your account processing is DMV inspired.
Aside from email accounts potentially being compromised or SMS interception, this is honestly the way all sites should be going now. But more seriously, there should be a way to use only Passkeys with a backup identification method in case you lose your Passkey.
The new threat? Browser password managers are insecure. Anyone can sit down at my machine if it's unlocked and Passkey their way into any of my accounts. What good is that? Why doesn't Chrome use my Google account password before allowing auto-fill/login? (Obviously I don't use Chrome's password manager, but it's a real concern for everyone else.)
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.
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.
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?
But this went out of the window when some genius decided that usernames were too complicated, so Passkeys had to be discoverable, which means they have to be fully stored token-side. Which of course has the nice side benefit of essentially killing hardware tokens and forcing people into using their Android/iOS/Windows device for it.
This part of your comment is incorrect. Discoverable Webauthn absolutely can be used with hardware tokens like Yubikeys.
The biggest point of confusion in my opinion comes from Windows especially having lacked a way (and kind of still does) to save the private key of a passkey to your password manager, defaulting to saving it to Windows Hello, which saves the private key to your PC's TPM. In this scenario you can no longer easily copy the private key to other devices, and if you lose that Windows PC, you also lose the private key and the whole passkey as a result.
2) See #1
3) See #1
KeepassXC supports passkeys. They suggest a couple mobile apps that also do.
[dead]
Lets assume I put all the effort to explain.
I will give you a better example.
- Lets say you have a google account with pixel phone
- You are using it and added 1000 passkeys
- All are synced to your Google account
- Destroy and Get a new phone. Login to your google account with recovery code.
- All your passkeys are in your phone again.
There are plans in fidoalliance.org to make it portable. Pretty sure you are still not going to move to it.
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.
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.
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.
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.
Device bound is horribly broken idea. Credentials must be me-bound, so I and only me fully own and control the credential. I want to access the site from wherever I want to access it.
People lose their device all the time, there's tons of horror story where people got locked out because they lost their sole method of 2FA and if there is a method to bypass that then it is inherently insecure
For the layman yeah it is probably enough
If your system requires any basic intelligence or interest scrap it and go back to the drawing board because you just lost your customers.
Arguably, that's the only way forward. SSI is also nice because you get to fully control what you share and don't share (e.g., age verification, you get to only share "I am over 21" and no other information).
Passkeys were (are?) supposed to be just a password replacement though. That services are using them to replace a username AND a password AND 2FA is a problem that's turning the device into your identity, instead of keeping the identity as three parts (What you know, what you have, who you are (biometrics)). Now we've just turned the "something you have" into the entire identity stack.
1. All passwords stored in password manager. 2. Login with password manager when logging in for the first time on a device. 3. Combination of OS and site/app notice that no passkey has been created for this account and offers to create one. This is presented to the user as “setting up the current device for password-less log ins.” 4. OS negotiates with site/app to install the passkey and use it for future log ins on the device.
It’s presented to the user as a convenience clearly tied to this device.
…but you still have your text password stored in the password manager’s servers…
If you’re not storing the actual private key in the Secure Enclave but only the “access to it” what’s changed from how Apple’s keychain already manages password syncing to iCloud?
The only benefit (and it’s still a decent one) is that some random website breach can’t disclose your private key.
Which in and of itself should already be a super obvious total no-go. Every device will eventually go out of service or will be decommissioned, for a multitude of reasons. Then what, I lose all access, because I went from an iPhone to Android? WTF?
How would it look if it wasn't corrupted?
(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.
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.
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.
https://f-droid.org/en/packages/org.liberty.android.freeotpp...
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.
so. no clear explanation.
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
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...
With the exception of Github, and banks.
No major bank revokes your password when you setup a passkey, either.
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 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.
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.)
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
Passkeys can too, but there it's even more obfuscated than with 2FA.
Why is there so much misinformation nonsense around passkeys?
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.
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.
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.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.
Let's say I have a new account and a single Passkey in the TPM of PC1. I want to log in from PC2, too. How can I do that? (I know there is some trickery with Bluetooth, but I haven't seen anything supporting it, and desktop PCs usually doesn't have Bluetooth connectivity.)
AFAIK some browsers can do some magic to use a Passkey from your smartphone on a PC, but you need to log in to the same browser-sync account from both device (which brings back us to the same issue).
Also the whole thing becomes a mess when you change devices. You need to log into all the services you have ever used to delete the Passkeys from devices you no longer have, and you need to add a new passkey from a new device you bought to all the services you use.
If you don't want to downgrade security, how about requiring confirmation from another session that is already logged in using a passkey? e.g. You try to log in on PC2. A prompt appears with something like "confirm this login from [PC1, etc.]". You log in on PC1 using your passkey. The service recognizes that the login id definitely you, or at least someone in possession of your physical device and login method for that device. Therefore, it then allows PC2 to register a new passkey. Kinda similar to how google confirms new logins by sending a notification to your phone.
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.
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!
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.
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.
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.
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.
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!
Take a guess why.
Passkeys are just a trick for vendor lock-in disguised as a security practice.
Edit:
Apparently BitWarden should work, but my particular passkey was not on there.
> 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://support.apple.com/guide/icloud-windows/set-up-icloud...
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 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.
I think that's exactly the problem. These are all answerable questions, but getting those answers is confusing for most people.
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.
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!
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.
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.
That's basically my recommendations to people.
1. Avoid using them if possible.
2. If you have to use them, make sure you have a password login to fall back on.
3. If the site forces you to use them, make sure you don't use it for any thing you rely on.
You know how many of my passworded accounts got hacked in my lifetime? Zero.
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.
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.
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 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'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".
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.
> 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
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.
Oh! No. Please switch to something else. Last pass has had so many breaches, at this point it’s just not worth it.
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.
well, people are talking about it but it's not making a difference https://lucumr.pocoo.org/2025/9/2/passkeys/
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.
You're basically fucked even if you buy a new one because you need one of the other two to log in.
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).
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.
I use passkeys with a physical authenticator. How do "they" track and deplatform me with a single click? Can you explain?
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.
> 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'd also add: How do I login on a device or browser that I've never logged in before? If I'm on a public computer that I trust enough for quickly logging into my emails but (say, the local library or university PC pool), do I have to install my password manager first and then login with my master password? This seems backwards.
And to answer your additional question, yes, I suppose you would either need to install your password manager or use whatever alternative 2FA login you have.
> Do I need a unique passkey per device?
If you store it in the device itself (passkey isn't moveable) and not a password manager (you can move the passkey around) then yes.
> If my passkey is on my phone what happens if I lose my phone?
Delete the passkey using another device. If your phone is the only trusted device/only device that had a passkey, begin account recovery (e.g. via email).
> How do I rotate them? What if a device gets stolen?
You shouldn't need to, if they are properly stored in the device (in hardware) and not a password manager they should not be extractable. But if you lost your device/it got stolen and you have no lockscreen password you would need another device that also has a passkey that you would use to invalidate the other one from the account settings page similarly to how you would change your password (you are logged in with another passkey, that is your "existing password" in the password model and you don't set a new password but instead delete the other passkey and create a new one). If instead you use a password manager and it gets breached, either rush in to create a new passkey (e.g. on device temporarily) and then delete the old one, or if they got ahead of you begin account recovery, similarly to if your password got extracted from your password manager.
> How do I login on a device or browser that I've never logged in before?
Similar to steam and discord's Qr code login system if you've ever used that. Ideally when you visit the website would generate a login session and you could then login from a personal device you have on you by scanning a qr code or manually entering a code (for devices without a camera). Probably also tick a checkbox that you are logging in on a public device and that you only want a short lived session, but such a feature doesn't generally exist in login systems that use passwords either, even though it would be convenient to have.
---
All these answers above depend on the login system being well designed. If the people writing the website don't let you register multiple passkeys or don't make it convenient to register a new one whenever you login on a new device, or don't offer the aforementioned Qr code login system or don't offer good account recovery - you will have a bad experience.
For example, passkey on iPhone and on the same account register a second key such as a yubikey.
That’s how my github is configd, for example: my phone and MacBook can auth w OS passkeys. If I need to login on another host, like my windows host or in your example at the library, the yubikey is another registered hardware authenticator.
Worth adopting/looking into imo
[deleted]
> 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.
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.
[1] https://support.yubico.com/s/article/How-many-accounts-can-I...
> upload their keychains to ms/apple/etc clouds where they can be requested by any gov under the sun for x reasons.
If a HSM module (TPM, Apple/Android Secure Enclave) is used the private key is impossible to extract (and upload to a cloud) anyways
Do you know who offers more? I deliberately chose Yubikey as example as their limit was the highest. Others like Nitrokey etc. support even less.
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.
I moved all of them from my iphone to a selfhosted bitwarden in two minutes.
[deleted]
it's one password to everything
You are entirely mistaken. Passkeys involve a third party storing a public key on their infrastructure, while you hold the private half of the key, somewhere.Passkeys are never reused. Even for the same person, they are always unique across websites, and across devices.
All password managers support passkeys.
Both apple and google allow exporting your existing passkeys to third party password managers too.
Also each website gets it's own unique public key with passkeys. It isn't a single credential
You're literally arguing a strawman
[deleted]
Already you're off-base. Of course it works when your devices are homogenized, but very little folks work that way. Some people have a Windows computer using Brave, an iPhone using Safari, an Android device using Chrome, and a work computer with its own hardware/software limitations and partitions.
Of course it works when your ecosystems are not diversified. Problem is, most people are.
A cross-platform password manager like Bitwarden handles passkeys (and passwords) across multiple operating systems, browsers, etc.
It already falls apart for regular interactions like "Can you send me the Netflix password?"
And Windows, you need Bluetooth enabled on both devices, on Linux you need Chrome (and presumably bluetooth enabled). It makes you scan a QR code.
On Windows, I hate them. They always push me towards using a PIN instead of my Yubikey or password.
No need to be a part of an 'ecosystem' to use a password manager or passkeys.
KeepassXC was threatened to be blocked.[1]
[1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
Also, remember when one of the maintainers of the passkey standard warned that KeePassXC users would get blocked by relying parties [0]? Would you allow tech companies to determine what password manager you are allowed to use?
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)
Also yubikeys have limited passkey slots (100, 25 with old firmware)
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
how to use cross-device? either use some password manager that supports it (apple/google/1password/keepass/etc support it), or use device that you have on hand most of the time - phone. when the passkey pops up - point your camera and scan the qrcode - you are done. otherwise use dedicated device like yubikey or similar.
really not sure what is hard about that to understand. i'm using android and chrome, so i can use the password manager in chrome, or my phone to scann the qrcode.
my country is using similar authorization for government "profile" (mobywatel - poland) that has similar to passkey implementation. you download the app on your phone, login via login+password (or other), download the certificates, and from now on you can point your camera on qrcodes to login to government websites; it requires pin/code or biometric confirmation on the phone - same as passkeys.
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.
You scan the QR code, click the confirmation button, and you're signed in. It's part of the standard UI of normal operating systems.
Might not work (well) if you're on an old computer without decent Bluetooth but everything has Bluetooth these days.
now multiply it with every web site you want to access.
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.
But don’t log in to important accounts on a public computer, like ever, unless it’s a dire emergency.
(...and I’m pretty sure plugging my yubikey into a locked down public terminal is not going to solve this, either.)
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.
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.
Exactly the sort of behavior that will suck in the unsophisticated user, and then leave them with no options when it fails.
Plus, that doesn't have the negatives/limitations of passkeys.
I ask because I'm curious about others' practices and desires here, not with any promise of a better solution!
Honestly, this is one of the two things that make me hate passkeys. The key management is a high-friction pain in the ass.
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).
And now I have another thing I need to carry everywhere.
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.)
If I were administrating that part of her life too, then maybe, but I'm not really happy with how Yubikey has solved for this problem either. If I could buy them for nearly throwaway amounts of money, and I could make backup copies without issue, then I might even jump on that particular train myself.
That sounds like an Amazon problem. For 40 USD, yubico.com says that it will deliver a shipment on the next business day to this rather rural house I see in the middle of Foothills Road in Newman Lake, Washington.
Also:
> Replacing a key is basically impossible.
If you know that getting next-day delivery is dreadfully difficult, then order a handful to have as spares. "If you can reasonably afford it, always buy more than one." is solid advice for just about every important thing that you are likely to break or lose.
A passkey doesn't give up anything compared to a password, and is in fact much much easier to handle, IMHO. I have kept all of my private SSH keys in secure hardware for a decade, so perhaps I'm more used to carrying a physical key than others, but IMHO it's all better, all around.
We should eliminate passwords, and that has nothing to do with remote attestation, age verification, or anything like that.
For 20 years, I've only known two to three passwords at any time, and those are login passwords for separate boxes or corporate/home accounts. Beyond that, hardware access should solve everything, and I shouldn't have to type any passwords anywhere. Every account needs granular credentials, not shared credentials, but no user should have to memorize passwords beyond one per work domain.
How does this work, exactly? Does you cloud password/key manager allow syncing to the YubiKey?
Or do you register a second passkey that you store on the YubiKey whenever you create a passkey?
If it is the latter, do all services that allow passkey authentication also allow registering multiple passkeys? How many?
> could do two backup YubiKeys [...] keep one YubiKey in a safe deposit box
If you register a new passkey on the primary, do you then have to take the backup YubiKey out of the safe deposit box to put it on it as well?
I haven't seen this kind of question answered when sites prompt me to use passkeys instead of passwords.
Both passkeys are independent of each other and know nothing about each other, only the website knows that both are mapped to the same account.
It's like setting up multiple API keys for a service. Passwords are usually restricted to just one, but passkeys are (generally) allowed to have multiple backups.
When I go to login to Google, for example, it will prompt for a passkey. Currently, in Safari, it will prompt for biometrics on my iCloud passkey. I can either give it my fingerprint/face, or hit the "More options" button, which in the current list allows either 1) insertion of a USB security key, or 2) presenting a QR code that a phone device can scan, allowing use of the passkeys on the phone.
(All very good questions, BTW!)
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.
If the website didn't implement a "lost password" button then that says a lot more about the website than it says about passkeys.
So far only Nintendo has been absolute assholes about requiring specific passkeys, but that's maybe the least assholish thing Nintendo has done.
also appreciate your attitude, better than "I work in tech for xx year, i don't understand yy, so yy must be bad."
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.
To be fair, trusting users with passwords/credentials is how we got into the mess of phishing et al in the first place.
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.
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.
It's going to require a law: if you require 2FA, then TOTP or HOTP must be offered as an option.
sure there are some issues sometimes (outages and others), but most of the time they work like charm and solve a lot of issues with login+password issues.
- [0] https://play.google.com/store/apps/details?id=pl.nask.mobywa...
- [1] https://dane.gov.pl/en/dataset/2919/resource/43845,mobywatel...
The one thing I would ding that approach on is recoverability, though. If a fire burns that down, it's gone.
[deleted]
It also makes access to the app maximally unrecoverable if someone loses access to the passkey...
Yeah, there is a difference between something that is difficult to explain but ultimately explainable, and something where the correct answer is "it depends"...
Basing your security decisions on "it'll never happen to me" because there are billions of other users who will get burnt first is not a wise strategy either.
Why take the chance when there are so many other alternatives that let you own your vault or at least companies that still have some semblance of a support team.
Losing a decade of my Google Maps Timeline data even with backups enabled made me realise I may not be lucky enough to win the lottery but I am lucky enough for Google to pick little old me, hidden in the billions, to lose my data.
That's not my argument. My argument is that your evidence that Google is uniquely bad at locking people out of their accounts is not good evidence. A few stories in the news represents a beyond negligible fraction of billions of user accounts.
https://support.google.com/accounts/threads?thread_filter=(c...
How many times do you have to click "View more" to reach a post from last week? It's a problem.
The repeated advice from the "diamond product experts" says it all:
If you can't recover your account using Google's automated recovery process, the account is lost. [1]
Personally I thought I was OK because I had a recovery email set but what Google doesn't tell you is they outright refuse to even send a recovery email if you don't use a device, browser and same wifi they've seen before. [2]. At the time I was all in on Gmail so it was an especially sobering experience.
I accept it's a hard problem to protect that many accounts, but to dismiss it as a "few stories" is understating the problem and diminishes the terrifying experience all these users are having.
[1]: https://support.google.com/accounts/thread/453660883/locked-...
[2]: https://www.reddit.com/r/GoogleSupport/comments/1ps28fn/coul...
If technically-motivated individuals can't be assed to switch away from passwords, then imagine how normies feel. I fully understand why most people choose passwords instead.
> According to Google, you’ll need the following to sign in with a passkey:
> A laptop or desktop that runs Windows 10, macOS Ventura or ChromeOS 109 or later
> A mobile device that runs iOS 16 or Android 9 or later
> A hardware security key that supports the FIDO2 protocol
> Google adds that your computer or mobile device will also need a supported browser, including Chrome 109, Edge 109 or Safari 16 or later.
> [...] Do not create a passkey for a shared device if you don’t want other users to access your account, Google warns.
So much information, so many warnings. I feel nostalgic for passwords just sifting through this stuff.
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.
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.
I get reluctance about being dependent from the US but your reason seems a bit off
[deleted]
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.
Maybe for a lot of tech people, I don't think the general public understands the risks enough to care.
What would you answer if grandma asked you what happens if she loses her physical key?
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.
This
> Which is happening with all the big platforms right now.
Does not seem to be happening. Am I missing something?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.
Why not just set yourself up to be able to access her password vault? Why is copying magic strings a better solution? You could have done that to get password access without passkeys existing. So they change nothing.
Consider:
1. Password managers tie passwords to sites, so phishing-resistance is achieved. 2. Password managers allow long, complicated, individual password per web site, so compromise blast radius is 1.
The problem with autofill is it doesn’t help if the person keeps screwing up their passwords, changing them, or ends up with 5 different passwords in the password manager for the same site.
All of which I’ve seen.
On registration, a keypair is generated, then the private key is encrypted with the long-term key burned into your security key fob or hardware. The encrypted blob is sent to the server and stored there.
On authentication, after you enter your login, the server sends the encrypted blob and your security key tries to decrypt it with the long-term key it has. If it succeeds, it then request a challenge from the servers, signs it along with the server name and timestamp and sends back to the server. Server validates the signature and if it’s good, log you in.
Expanded: As long you as the user has the security key fob, you can login. You should have 2.
Yes, you do.
Whenever a website offers to create a passkey, it could end up in any of these:
- Samsung's Password Manager (if using a Samsung phone)
- Apple's Keychain (if using an iPhone)
- Google Password Manager
- Your operating system's keychain
- A bespoke password manager (e.g., Bitwarden or LastPass)
- Your hardware key
Most users do not have a security key fob. Instead, the proposal being mostly pushed is the idea that users can store keys on their own smartphones, making use of the modern TPM and chip security. Most of the discussion here revolves around that idea: "What if I lose my phone? What if I switch phones?" and that's why the problems seem so obvious to you.
I absolutely agree the best solution is to use hardware keys, but I'll admit it's cumbersome if I need them for hundreds of accounts (which I do have), having to register both for every website and praying that I never lose both at the same time in the case there's no viable recovery flow for some of the accounts. Also, most of these hardware keys are limited to 25 or 100 resident keys, which again makes them unable to substitute passwords. Observe the usage of the term resident keys: passkeys do rely on the private key being stored on the hardware key, as that allows discovery.
[dead]
Yes, you don't use Gmail so it does not matter. You may be don't know. And often even average Joe some how has a oldphone or iPad that has oldgmail account there or logged into wife's phone or phone based SMS whatever.
it is ok to hate passkeys or google or love only self-hosted but let others do what they want.
I have been user of solokeys (since the first one) - only opensource hardware keys. works for me...
But if you go to the local highstreet then there are tons of people doing this screenrepair etc just to recover the account. Average Joe doesnot mind paying for that. Even will give the repair guy full password to transfer all data from old to new phone.
At the end, passkeys are built not for the tin-foil, (I hate Google Apple fellows), I want to keep every single locally, RMS fans. No.
A majority will benefit. End of matter.
A majority don't change platforms (I have not seen them do it).
And lets be honest - even if they were portable are you privacy person that is going to do it? No.
People break their phones. That is normal experience. Entirely unsupported by passkeys as they are today.
I'm actually surprised we didn't have more pushback for ubiquitous 2FA, as they have similar threat profile - i.e. addressing the tin-foil threats of cybersecurity aficionados, while entirely ignoring the common threats to real people, in particular the one of broken or lost mobile device.
People break their phones less often compared to telling them keep their keepassdatabase in sync across devices.
Even recently my friend fixed his iPhone XR (10 year old) 3rd party. Everything including passkeys work fine.
All these doom mongering of suspension happens so rarely that majority don't care.
There are countless reason to DIY. Agree. But passkeys will help the majority.
Also note that the kind of people - like journalists etc - that need to use DIY/local are the ones that are likely to use passkey. Reality.
These privacy zealots fail to realise that majority of population does not have time to setup bitwarden server or lineageos or zfs storage etc.
Another way would be auto-enrolling passkeys from other devices you own through a standard API. Enroll your trusted Apple device in your Google Account's settings, or your Bitwarden/KeePass, and vice-versa. When your iPhone creates a passkey at a site, iCloud notifies Google, which issues a new passkey and sends the public key to iCloud, which auto-enrolls it at the site alongside the iCloud passkey. BitWarden gets the same treatment. When you open your KeePass vault it checks Google and iCloud and picks up any pending offers for passkey enrollment and completes them.
Simple, secure, opt-in, and users control their devices and passkey vaults with minimal hassle. If a device is lost, the other services can help you automatically delete the compromised passkeys and set up your new replacement device.
Matter does something very similar with cross-compatibility between Apple and Google (and the rest of the ecosystem) when new devices get enrolled with the user's choice of PAA; the only thing missing is roughly cross-PAA enrollment but that would be just one additional trivial trust relationship in both ecosystems.
The high level UX of this idea feels very compelling to me as a "yes and" -- aka a world where vendors continue to offer end-to-end encrypted syncing within an ecosystem, but then this idea gets layered on to solve the cross-ecosystem problem. I think the trickiest part would be how to do it in a privacy-preserving way, but that's solvable.
This is my issue with passkeys. Either we lessen security to improve UX (syncing across devices implies extracting private keys from secure enclaves, at which point it’s no different to password syncing), or we have a proliferation of different keys per website across devices (assuming the website supports multiple passkeys).
Perhaps this trade off is not resolvable in a way that happily satisfies both the security constraint and the UX requirement.
Stranding private keys in clone resistant secure enclaves has unacceptably bad UX for the average user, which is why very few implementations try to do that.
Yes, that is a feature and a normal use case that has equivalents in meat space, that security aficionados refuse to recognize even exists, much less support.
You still get the phishing resistance, though!
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.
No end user wants to export and store a keychain. So they hand that off to somewhere else.
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.
Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors.
Also they decided they should be cloud-synchronised, so the something-you-have second factor doesn't impose the burdensome requirement for you to have something, which was apparently a big usability problem.
They obviate the need for a user identifier as the key is itself unique, but removing the 2nd factor is a choice of the service, not the designers of the Webauthn standard.
> Also they decided they should be cloud-synchronised
The earlier versions of the spec required that the keys be resident in hardware, but it was updated to allow "roaming" keys. The important part is it's up to the service to decide on whether they want to require hardware resident keys (which cannot be synced via the cloud). Most do not.
The usability problems are actually larger than that, see sibling comments for why. Passkeys, even when cloud synced, are still better than cloud synced passwords and still give the option of hardware backed keys for those whose threat model warrants it.
From what I know, Apple ignores `platform` and `ResidentKeyRequirement` claims and always creates cloud-synced key pairs.
Moreover, the strongest claim value allowed for the `ResidentKeyRequirement` is “discouraged”, which per spec is treated as SHOULD in RFC 2119 since. In other words, browsers are free to ignore it when “they know better”, which Apple always does.
And that's exactly why the technology should be rejected while we can. It's no business of a particular service how I use my devices.
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.
Having spare Yubikeys is more of a hassle than both of those (and more expensive!), and the worst case scenario of losing them all is much more catastrophic. If I have no house key, I still get into my house. If I have no car key, I still get into my car (after a fair bit of hassle). If I have no Yubikey, I have permanently lost access to the accounts it was tied to.
If physical hardware tokens were as cheap as house keys and not much more difficult to set up and copy, then it would be kind of reasonable. As it is, it's unworkable. Even password managers manage to make this work. You can throw your database on every storage device you have and write the master password down on paper, and the chances of you not being able to have access to it are pretty darn close to zero.
We are talking about the rest the people that want convenience.
In a way that is the reason passkeys synced with Google or Apple just work. No need of hardware keys.
As a consumer, I don't give a shit. I use my driver's license to apply to jobs, my passport to fly, and a password (with 2FA depending on how much I / my employer cares) for everything else. I prefer whatever I use for 2FA to not be device-bound, because that's obnoxious, error-prone and constraining.
As a consumer, I don't see any reason for my auth to be more complicated than that.
Yes? I mean, that's what literally is there by default in every country. They're not either/or either, they're part of a chain.
Most importantly, none of that is device-bound. Or even person-bound. Which allows for delegation, which is a feature that cybersecurity people keep insisting is not real.
Until we find a way to securely implant a Yubikey in people's brains, it isn't going to happen.
Your master password to your cloud PW manager's vault is also phishable (hence why passkeys were ideally device specific, non-exportable).
Its phishing resistant not phishing proof
Not true. The original concept was always for them to be cloud synced.
This has nothing to do with their anti-phishing capabilities. The anti-phishing capabilities come from the fact that the password manager authenticates the application before handing out the passkey. It doesn’t matter if they are synced across devices or not.
You are correct that other login methods might be weaker than passkeys. I’m not sure how that’s related to passkeys though. In real security sensitive applications the recovery process is “go to the bank’s branch and show them your driver’s license”.
> Your master password to your cloud PW manager's vault is also phishable
No, it’s not. You would need to steal my yubikey to get access.
It was not. The original U2F spec was created before that idea was around and it talked about hardware security keys as means to store the primary key pair.
> Your master password to your cloud PW manager's vault is also phishable
... which is why all sensible cloud vaults have a separate enrollment key, requiring an explicit action to grant a new device access.
In the US, only about 34 to 36% of adults use a password manager. Of the ~64% that don't, an alarming 20% reuse the same password across almost every service, and a ton just rely on browser autofill.
If you use a password manager, you are in the minority. Hell, even if you don't use a PW manager and you at least use a different password for different services, you are ahead of most people.
The general population is largely computer illiterate, and have a staggering lack of basic security hygiene.
UX usability is far better. With password and 2FA you have at least 2 steps. Here
Open the app: device like phone or laptop just asks your fingerprint or facial and done.
That is a great benefit for average Joe. Some one trying to scam remotely cannot access the account. The 89 year old grandma will say - I just give fingerprint. Done.
Yes, it won't cover all situations. Like if there is sim swap or bank employee does fraud.
It moves to the account recovery flows, but that can be much more difficult to phish.
[deleted]
This changes by banks, some send code to our phone number (thought WhatsApp or SMS), others send SMS+email + face ID. All of them require at least the face ID. Some biggest banks requires you to go to ATM to authorize app access. You insert your card, password and authorize there.
There's Mercado Pago, which supports passkeys and standard MFA too. So you can store on bitwarden even.
Errr, no.
You can transfer a password from one manager to another. Those very same password managers won't let you transfer a passkey they hold.
And if you know the password, you can use it anywhere by just typing it in - no complex technology or protocols involved. But using a passkey involves your secure computer talking to another computer, using a complex protocol that can't go via eyeballs and fingers. If you don't have a way to connect the device holding the passkey to the computer wanting your id - say your USB A Yubikey isn't recognised by your phone, then you are out of luck - you can't use that passkey, even though it's sitting in your hand.
And you can't work around that by copying the passkey to a device that can communicate with the service you're using, because you aren't allowed to copy.
It's an unworkable mess. The mess is not created by passkeys themselves, because, as others have said elsewhere the protocol is pure elegance. The mess is created by vendors choosing lock in over transportability. I'm hoping it's a passing phase.
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_.
>instead they have a mixed Windows + Apple setup with 3rd-party password manager
Why do I feel like this scenario is entirely fabricated.
What fucking "senior citizen" is confused by a passkey, but has multiple devices and password managers?
[dead]
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.
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.
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.
Honest question: If the main issue is phishing, why wasn't something like Yubikey adopted more widely - or dongles, or the venerable chip cards we have since the 80s?
Everyone knows what a key is - I mean the thing you open doors with. Most people know the basic security implications as well as what to do if you lose one.
The simplest way to translate that to "electronic keys" would be a dongle or chip card - that lets a device use its identity as long as its plugged in, but is not physically locked to that device. A user can unplug it, take it home with them or plug it into a different device. What a user can't do is copy them, so the same phishing protections as with passkeys are provided.
But for some reason, this never caught on except for niche solutions. Instead, the industry is increasingly moving to systems where the keys are fused with the devices themselves, using TPMs or similar technologies that can't be removed from the device. Which gives you all the well-kniwn hassles if keys have to be moved or devices get lost or stolen.
But I don't understand why this is done.
I’m a little afraid that hardware tokens are getting lost in all the passkey marketing BS. At least they continue to work for now.
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.
(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.
>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/
With the "cloud password manager" angle there is some hope of being user friendly, although we're certainly not there yet for most folks.
> 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.
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.
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.
There. You just violated the premise of his point, that you use a password manager that syncs to all your devices.
The passkeys sync just fine between iOS and Android on our devices using 1Password.
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.
You're right that all of the major password managers like their lock in. The Credential Exchange Protocol is just barely good enough that OS vendors can say they "support" it, but tricky enough to find that ordinary users probably will never try it. (Not to mention that it doesn't even work yet on Windows or Android.)
As for attestation, the good news is that Apple always returns 0s for the attestation ID (because Apple, like you, opposes it as a side channel), and so any public site/app that insists on attestation would reject all Apple devices. This gives smaller password managers like Bitwarden sufficient cover to 0-out their attestation as well.
The bad news is this could change.
If we want this to be usable by consumers we need to prevent this kind of thing, not thank Apple for their restraint.
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.
Doesn't work well in office environments, but at home the local threat model is largely fine with this.
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.
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.
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.
[deleted]
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.
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.
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
Cool. So can I write down my passkey on a piece of paper and put it in a safe?
> you'll reset your passkey the same way you reset your password, probably with a "forgot my password" email
Cool. But what if I lose the passkey to my email account?
> and the passkey will be stored there and synchronized to all of your other devices
Cool. Surely backups and synchronization never fails.
> The weird part is that password managers provide no way for you to copy and paste your passkeys
Uh oh. So you are saying passkeys are not like passwords? Last time I checked, every password manager lets me copy and paste my passwords just in case.
> To present a passkey, you have to use a password manager
Uh oh. So you are saying passkeys are not like passwords, like at all? Last time I checked, I can just type in my password using a keyboard on all websites I visit.
> This makes it impossible to copy and paste your passkey to the wrong person
Uh oh. So it means I can't just give my password to a family member sitting in the opposite side of the room? Sorry mom, corporate has decided that you are trying to trick me.
> Major password managers don’t even allow you to export your passkeys to a file that you can read/backup yourself
Uh oh. So is there a registry of Major League Password Managers that are guaranteed to implement Corporate Strength Cybersecurity Measurements? Will I be blocked by services if I happen to have landed on a minor password manager?
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.
If I have to go get the backup out of "secure" storage each time I want to add a new Passkey it's not really a backup.
The design should have allowed, even if it was just within only the purview of a single manufacturer, a method for the device to export an encrypted dump that could be reloaded onto a factory-new device. Heck, make it a value-added service that the manufacturer has to initiate and tie it to some real-world identity verification.
The idea of having to put backup devices in-hand regularly is a bad design.
Phone apps. get around this idiocy by backing-up the encrypted Passkeys to a hosted service.
Yes.
> even if it was just within only the purview of a single manufacturer
> Heck, make it a value-added service that the manufacturer has to initiate and tie it to some real-world identity verification.
No.
[deleted]
This is why I don't bother with these if they have a weaker workaround, which will be open to remote hacking.
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.
Passkeys are passwords which allow a relying party to control what password manager you can use.[1]
Either your password manager will automatically synchronize for you, or you can transfer your passkey to another password manager that will do the synchronization, via the finicky app-to-app transfer system (Credential Exchange Protocol). You can transfer from Apple to Bitwarden and vice versa.
The family sharing question was added later, but the answer is: all of the major password managers have finicky family-sharing features for passwords and passkeys.
For passwords, most people don't bother with formal family-sharing features, and just share passwords via copy and paste. For passkeys, you have to use the family-sharing features, which means you and your family member have to use the same password-manager vendor to share those passkeys.
It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.
Until a relying party uses attestation to decide this for you.
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.
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
Yes - the kerfuffle is broadly I think the fact that it negates the main advantage of passkeys: people can't be tricked into pasting them into a fake login screen.
> It's an impossible design. It's all just obfuscation, most of which is confusing to users.
I agree - they're explained in a really odd way, and I think that's because they're a technology with multiple interaction patterns, rather than a single thing like a password. E.g. your fingerprint on your Mac is implemented as a passkey, or clicking on a browser passkey is also a passkey, or using a password manager via a different UI is also a passkey, or touching a Yubikey is also a passkey. The underlying mechanism (passkey) probably has been surfaced more than it should've been.
How come I log into my corporate Windows laptop by typing a passkey instead of a user/pass combo?
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?
Those are absolutely not passkeys. Passkeys are just WebAuthn (from what i can tell).
Kind of feels like "crypto is a type of currency and not all cryptography", or "SQL Server is a specific product of Microsoft".
Wonder if how it happened this time was people read the specs and explanations of WebAuthn, saw "passkey", never seen that word before and assumed it's only ever been used in the super narrow context of WebAuthn so it can only mean that. Maybe "header" can only ever mean "HTTP header".
Thinking about it like that, it may be more like how "latte" is specifically espresso with milk (it's really just milk), or "queso" is specifically cheese dip (it's really just cheese of any kind), or "masa" is specifically made of corn (it's really just dough of any kind, or it's mass like atomic mass is masa atómica).
[deleted]
Isn't this true of any authentication method? It doesn't seem unique to Passkeys.
In security, you identify reasonable threats. You can't protect against all of them, and some may even be contradictory.
When I get a call on my phone that says "Potential Spam", I have never even once in my life decided to run over to my list of passwords and hand them over to the President of the Spanish National Lottery. Not even once.
But on many, many occasions I have dealt with a simple system that was replaced by a more complicated one and something in that Rube Goldberg machine broke down and deprived me of access to money, email, even a parking permit to my office.
Passkeys seem to protect against the former case that has never happened to me, while increasing the chances of the latter that has happened way too often.
The OSes I use where that works fine:
- Android - Windows - Linux - macOS - iOS
Nobody fucking knows.
BitWarden, KeePassXC, and probably a bunch of other password managers have very thorough support for import-export, automatic/periodic backup, sync/merge, etc.
Also it could be vulnerable to MFA fatigue attack, if people would constantly get new "confirm this login" popups, they would press anything to make it go away.
So you would need something that is explicitly initialized from a trusted session, then you need something to connect the trusted session to the new login. If you want that to be user friendly you need some short codes and can't rely on QR code / Bluetooth, or two-way interaction. And that brings up the phishing / MitM attacks again.
How can I do that, if Passkeys are the only option to log in?
If I can just use a password to log into a website without Passkeys, then Passkey is useless and doesn't add any security benefit.
> Why would you need to delete invalid passkeys? You wouldn't.
I sell my old (and no longer updated) phone or PC and don't want someone to get access to my account by getting access to the secret keys.
An non-revocable authentication mechanism is just stupid.
It is not feasible to remove password login or some other recovery login method.
> If I can just use a password to log into a website without Passkeys, then Passkey is useless and doesn't add any security benefit.
It isn’t useless, point is you don’t get to type in your password on a device that has passkey generated already, or get phished on a fake web address for example.
> I sell my old (and no longer updated) phone or PC and don't want someone to get access to my account by getting access to the secret keys.
Passkeys are meant to be protected by either PIN or biometrics, however they are also meant to be revocable on the web, at least they are for services i’ve been using with passkeys.
Finally, if it is easy to register a new device, how does the anti-phishing still work? Can't an attacker just convince me to use whatever means I would normally use to register a new device, instead of an existing secure passkey?
Heck, the company could easily say that your password needs to be 128 characters long and use multiple types of characters - and tell you to use a password manager (that both generates and fills in that information for yet).
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.
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.
What they want is to lock your identity to your android and/or iphone devices.
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/
Also moving the goalpost. The post I replied to said I couldn’t export it. I absolutely can, and have, with a single click. To another provider. It’s really not a big deal.
KeepassXC was threatened to be blocked.[1]
[1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
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.
I have a "Family" group in my Passwords app where I share passwords and passkeys with family members for exactly this purpose.
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.
> Approximately 90% people never go out of their country...
I am sure > 90% will happily love to have the convenience.
Yes, people like you can setup bitwarden etc. Nothing wrong. Passkey works for majority of people.
BTW, passkey can also be used without biometrics. It needs only the authentication of the device.
Once you talk about privacy/security then - I am not even sure you should do it here in HN - a bastion for encouraging Silicon valley practices.
In principle, you can remove biometrics and still use passkey (by using phone password only).
If you see my text, I wrote clearly - passkeys are great convenience + security - For the majority. People don't need to waste time in searching login names.
TBH, I was in a few Free Software Foundation Europe and linux conferences in the last year - in my view - at least half of them were using - passkey with iPhone or Android (including Playservices). So people have accepted the reality.
Hope they don't see your HN post. It is visible even without login.
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?
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.
I haven’t ever looked at the APIs for passkeys; is there any semblance of those types of keys being an option, or did opening the door to syncing basically let anything happen with the APIs and lose those guarantees?
None of my desktop computers support Bluetooth. Neither do my wife’s.
(In thinking about it, it’s possible that the motherboards I bought did have non-wireless alternatives that weren’t stocked at my local Micro Center - lot of digging required to figure that out, though :) )
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.
Do you mean you print the raw values to paper or some encoding that would let you reconstitute the file (some giant QR code or something?)?
On macOS I use Strongbox's Print Database capability. On Windows, I'm testing a KeePass plugin I created that does the same thing and more (not quite ready for public release).
If I'm still around and coherent, I can re-type it into a KDBX-supporting app by hand (or maybe if I'm lucky only enough entries to get to a backup in cloud storage).
If the worst happens and I'm no longer capable of using a computer, it's an obviously-important document for whoever is cleaning up after me (I bet most people would understand the importance of a document with a bunch of usernames and passwords). They won't have to somehow break into my computer first to be able to figure out what online/digital matters of mine need to be dealt with.
EDIT: My current printout is 46 pages long.
>I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
They 100% will lock it down to "secure" options you cannot control. I suppose if there's any hope, it would maybe be the official keepass submitting to their demands, while keeping them easy to bypass with a recompile.
> [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.
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'.
Passkeys are a convenience and as I stated above I always have a password as a fallback
What if the robber hits you in the head and you get brain damage and forget your password?
I had more trouble with a failed 2FA than with a password.
Or straight up betrays you (you slighted them at some family event)
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?
Further centralization on US services for something that already works fine (like 2FA) is unnecessary risk.
Once again how does this relate to passkeys? You don't have to use US companies to use passkeys. There are European providers of authenticators. What country is Yubico based out of again? Just picking one example, there are others.
But this is one of the points being discussed here. All of depends on a large number of choices that each site owner will have to get right. You could always argue "well, it's the site's fault for not doing it better", but the matter is that the site owner has to decide those things at all - and if course they will make their own tradeoffs or simply don't bother with certain features.
So you will always have a wildly inconsistent mix of different functionalities and constraints depending on the preferences of the individual services.
Whereas with passwords, implementers don't have to do any of those choices, the basic implementation already supports all those usage scenarios.
The QR code login flow is one such example. I probably have some bias that I don't like the thought of making my phone the sole authority for all my accounts, but even if you accept that, it's an exotic technically complicated flow for the exclusive usecase of "login on untrusted device". There are probably few sites that weigh that usecase high enough to implement the flow - whereas with passwords, there is nothing you have to implement, because the functionality is just a natural consequence of how passwords work.
Sure, in that sense the usability is better, but now we are dependent on the website makers to make choices on security (offer good 2fa, don't limit passwords to 8 characters and store it on an ancient mainframe, etc.) and even then the usability can take a hit if the website is ignorant of or actively hostile to password managers (breaking autofill and such). Neither system guarantees a good experience.
With my example I tried to paint what a good passkey system would look like for OP, I am aware that leaving the usability part up to the website will result in such a mix.
Once 1Password supports proper single export when I make a new passkey I'll store it there and later export it to Apple.
Meanwhile I simply make two passkeys. I've only run into I think two sites that supported passkeys but would not let me make two.
On most sites making a second passkey is as simply as going to your security settings, finding the passkey settings there, hitting the "add another passkey" link, and pointing your phone at the QR code it shows, and then on those phone choosing the password manager that you did not use for the first passkey.
I'm surprised selfhosted services would be allowed in that list. Isn't there the "risk" that you can then extract the raw key from your selfhosted instance?
https://bitwarden.com/resources/passkeys-are-phishing-resist...
However, I won't give it things which are meant to represent devices.
People who designed the 2FA model designed with the intention that a password is something you know and a device is something you have.
By putting storing both together you're breaking the assumptions of the people who design these systems.
So I store all my passwords on KeepassXC, everything else has to be elsewhere.
[1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
This mentality that the user is an attacker, and the software must protect its data from the user. Isn't a passkey ultimately supposed to be my data?
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
Here's the most readable reference to playing favorites on passkey vaults I could find from the FIDO Alliance (the previously mentioned 'cabal of evil').
See Section 2.2: "Validating FIDO UAF authenticator attestations against the configured authenticator metadata to ensure only trusted authenticators are registered for use. "
And Section 2.3: "Verify attestation assertions made by the FIDO UAF Authenticators to ensure the authenticator is authentic and trusted. Verification occurs using the attestation public key certificates distributed via authenticator metadata. "
https://fidoalliance.org/specs/fido-uaf-v1.2-ps-20201020/fid...
Basically, Relying Parties (the sites you are logging in to) are expected to allow/disallow certain passkey authenticators (the devices or software that hold your passkeys), based on registration and trusted lists. The FIDO Alliance can use entry into those trusted lists as a cudgel to force compliance with the standard. Effectively, the standard is that users must be locked into to proprietary ecosystems, unable to escape.
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.
The Bluetooth connection is how your phone exchanges the key and authenticates you through the computer. In its most secure phone, the key never leaves the dedicated security hardware/trusted execution environment that protects your key from snooping, the same way you cannot get a physical U2F key to give you the private key bits.
You scan a QR code to set up the pairing/connection process (if you haven't already), then a Bluetooth Low Energy exchange happens. You confirm you want to sign in on your phone (so you don't get tricked into scanning a QR code), then the cryptography happens that authenticates you.
You can find the protocol here: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-cl...
It should be noted that, at least on Android, any credential manager app will support this exchange. The passkeys in the Bitwarden app on my phone work just like the native Android key store when scanning a QR code, for instance, and other apps will also work. You can switch authenticator apps in the pop-up, or set a dialog in the Android settings if you want to switch the default.
Furthermore, there are also CTAP2 implementations for smartwatches (at least for Android smartwatches) that let you authenticate with a tap on the watch. That flow doesn't use a QR code for obvious reasons, you would need to manually connect your computer to the watch before it works. I believe https://github.com/fmeum/WearAuthn is the prime open source example of this feature.
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.
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.
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.
Now, if only Windows, macOS, and Linux can get together and fix whatever needs fixing to get headsets to connect properly automatically, that'd be grand.
in poland we have similar to passkey implementation for government profile, that is then used to login to most/all government websites or to sign government documents. you point the camera on the qrcode, confirm it on the phone and you are done. this same app has your ID, which can be used in most places (shops, banks, police etc).
and btw im using linux (main box), macos, android and ios - no issues so far with really cross device usage
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.
You're 21 miles from Spokane. I'm over 120+ north from Syracuse, NY. That's not rural, not one iota. Our Walmart isn't even a Supercenter.
> "If you can reasonably afford it"
I mean, at nearly $40 for shipping and something like $40-50 a key, I'm not sure I can reasonably afford to buy more than one on the average blue collar American IT worker's wage of sub-$30 an hour. If you'd like, I can give you my CashApp for donation purposes?
As you noted in your original post, next-day shipping is a shipping method so expensive that Amazon only offers it in select locations. An honest reader notes that three-to-seven day shipping is 4 USD, and the one-to-four day rate is 8 USD.
> You're 21 miles from Spokane.
No, I'm zero miles from San Francisco. But all sorts of places offer effectively-next-day shipping to SF, so I had to find somewhere by dragging around on Google Maps.
> I'm over 120+ north from Syracuse, NY.
Okay, is
Beaver River Air Field, Eagle Bay, NY 13331
sufficiently rural for you? That's ~200 miles from Syracuse as the crow drives and about 90 as the crow flies. If not, how about 9340 Long Pond Rd, Croghan, NY 13327
or Forest Lodge Sports Club, Honnedaga Lake Rd, Cold Brook, NY 13324
?All of these are still the same price to next-day, one-to-four-day, or three-to-seven-day ship.
I'll take some of your money now, please. I'm scraping together what I can in what some people called "America's Siberia" and am forced to take care of elderly family and have zero escape plan except for working a horribly underpaid IT job here :)
> Amazon won't deliver one to me for at least six days at the earliest, based on their rural delivery estimate.
That sounds like an Amazon problem.
But perhaps even 4 USD is too much for you to pay for faster shipping than what Amazon can bother to provide you. If that's the case, then I offer my condolences.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!
Not in the case of Keepass, since you can export them.
> I know you can export them, sort of, but that feature may blacklist your password manager and make it useless.
Yes, and this is why passkeys are flawed.
> Are they portable? I thought passkeys are locked to the device.
There's nothing preventing you from syncing your passkeys and using them on different devices. This even seems to be the happy path in the locked down eco systems (You can create a passkey on an iPhone, which is then synced to iCloud, and now you can use that same passkey on a Mac).
You don't have any accurate data to support your suspicion that Google is worse than others, only anecdotes and vibes. The true source of your fear is a generalized mistrust of big tech relative to other institutions, which while common and popular these days is not a sentiment I share.
[deleted]
In non-resident keys scenario you don’t store anything and from what I see there is no security downside of using non-resident keys.
Loosing both (or multiple) security keys is like loosing all your car or home keys. Very inconvenient, agreed.
Anyway, I think we can agree that FIDO authentication protocol implementation is a mess. Apple and Google made it messy because they wanted to lock down users to their platforms and then password managers followed. As a result, the current implementation is not more secure than “login with Apple” or “login with Google”.
Indeed, the only advantage to Resident Keys (i.e., Passkeys) is the discoverabillity of them, so you can login without even using a username. It's a shame all of the terminology around WebAuthn/FIDO2 and Passkeys is so loose and badly defined.
Honestly, I think OAuth logins are still an ok option for the average user, unfortunately, as I would never recommend someone I love to use Passkeys and put them through the burden of having to understand and deal with all of this mess.
Then, Chrome got an update and started hijacking the enrolment process from the operating system and created keys synced to Google Account. This resulted worse UX because authentication now required pulling the Android phone (for those unlucky ones who have it) and confirming the login there instead of doing it right on the computer, uninterrupted.
Then, Apple followed with cloud-only key pairs and then so did the password managers (including Bitwarden Enterprise we were using) and everything become a mess.
The only solution would be to use the key attestation and to only allow specific security keys. Both Chrome and Apple have config knobs to simplify enterprise attestation (a strong assurance, which FIDO authenticator has been used), but neither Windows nor macOS support key attestation for hardware-backed keys (and macOS ignores “platform” claim altogether).
It sucks.
Remember that your average user has no idea what a passkey is, doesn't remember half of their passwords and has no idea what a password manager is.
I actually do have a Google account, but do not link my (Android) phone to it. I don't have WhatsApp or any other spyware on the device. I do use Telegram, Ankidroid, and a few other apps that I trust. I'm not a fanatic, but I won't enable and abet anybody to follow me around and report all that I do. How my position is considered an extreme position today eludes me, and frightens me as well.
Let's say eBay asks user to login. With passkey. Press and hold fingerprint etc. login done. Even with laptop.
And average Joe doesn't want to maintain a keepassdatabse sync it. Yes, you can always use your own server etc but others have life.
That is the reason: for the average Joe not having exportable passkeys is good.
Average Joe doesn't have to do backup. It is all automatic.
Password managers make it easier to avoid those pitfalls, but passkeys make it nearly impossible to fall into them.
[deleted]
If the passkey is not accepted by the service, it can use the signaling API to indicate that the passkey was not registered validly.
It is too bad they ignore that though. That's really disappointing.
Just absurd.
Nobody hacks because that's illegal
Of course it is conceivable to want to directly access the plain text password for reasons you mention, although that would be exceedingly rare (at least for me). In those cases I agree that passkeys don’t work, although I might argue that if the average user thinks they need to access the plain text password, there’s a significant chance that they’re being phished!
It's a daily occurrence for me, because especially because of going through steps A) and B), step C) which is copy-paste is needed to actually transfer the unwieldy, unmemorizable password from the password manager that stores it, into the app that requires it, when the autofill service refuses to communicate between the two.
But it isn't always that simple. I have a work laptop. It has a MDM installed, so I can't trust it. I don't run my personal password manager on it, ever. But occasionally I go to a web site I don't care too much about, whose credentials are stored in my password manager. It's not an issue; I just type that password in. That doesn't work with passkeys.
Then there is backup. If I lost my password store I'd be toast. Which means if the company that manages my passwords took a dislike to me and banned my account, I'm in a world of pain. I deliberately choose a password manager that makes that unlikely, but not everyone knows to do that. Many people use Google, Apple or Microsoft as their passkey manager. These companies have seen fit to ban accounts without warning and no recourse.
My password manager lets me export all my passwords as plain text, so for my passwords this potential for lock-in is a non issue - I just export, encrypt, upload the result to a few places, I'm safe. I can always upload the data to a another password manager. As that doesn't work for passkeys, I don't use them.
Passkeys will become acceptable to me once multiple independent storage providers become available for passkeys, and they allow me to freely choose other certified others as a backup. Until that happens, they only solved half the problem. It looks to be the half that locks their customers into their platform.
PS: this doesn't require much. Just Google/Apple to implement CXS along with government providers, and we are there. But it won't happen any time soon.
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.
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.
Setting your preferred password/passkey manager on Android 17 to 1Password works fine in Chrome and Firefox to log in to any site, presenting passkeys managed in 1Password. It also works in all of Meta's native apps. (I'm pretty sure it works the same in Bitwarden.)
Whatever issue you're having, it's not an inherent limitation of Android passkeys. It might be a bug in your passkey manager…?
So yeah, this is cross platform on iOS, macOS, Windows, and Linux.
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.
They want to close even them because the only services they have now is ingesting cash, which is getting less and less anyway.
But yeah, any time I've gone into a branch, which they made me do a few months ago to "validate" my documents for a mortgage. Which was just scanning and uploading to their internet..., they've made me sit on the phone to their call centre.
You forgot about the endless frustration and annoyance.
[dead]
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.
In the UK at least, there are very few brick & mortar branches anymore - banks expect everything to be done online.
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.
Which would make the whole scheme unworkable (at least for me).
[deleted]
Too bad for Yubikey. I don't need them any more.
1. This can be subjective, Unfortunately Customer identity is not on the highest priority from security perspective, its all about ease of product use when it comes to customer identity. For customer identity, most account recovery methods still fall back to email or SMS even if you have 2FA configured. The real money lost with phishing is with enterprise identity, when some one poses as an employee. The recovery of these accounts can be managed. If a customer account gets hacked then the business is not really on the hook to make it even.
> Usability of passwords
This is the biggest point of contention as per my interpretation. The industry did a very poor job of securing their infrastructure leading the massive leaks of password databases. Instead of fixing that goal post changed, with the by introduction of PASSWORDLESS. The passwordless works just fine for enterprise identities, not the customer identity. Even for enterprises, you cannot get rid of passwords if you get into AAL concepts (guidelines provided by NIST for authenticator assurance levels)
4. I was working on WebAuthn when the term passkey was not there, I was there when the term was introduced, I saw how every one was trying to map their existing definition/understnading with the new terminology specially the part where Apple just announced them to be syncable. Enterprise companies had to actually disable the Apple Passkeys for this reason to begin with. I found it interesting to see how Yubico changed their documentation overnight, they switched every instance of WebAuthn keyword with Passkey. It took some time to settle on how to categorize discoverable credentials (where meta information about user is on the device in addition to credential) and non-discoverable credentials (hardware keys, they are limited in space so they did not store user meta information in earlier versions). Eventually google took the lead in calling the credential where private key cannot be synched as Security key and everything else as Passkey. Resident key, syncable, synched are all different bits of the WebAuthn assertion
5. Thats an interpretation of how I read things based on the overall play going on.
> Passkeys protect against phishing attacks, and you get that protection regardless of whether the credential is hardware-bound or not. That protection comes from the cryptographic binding of the credential to the domain at the time of credential creation.
The security aspect is tightly coupled with the authenticator implementation. The phishing aspect is the only default good in here, it just means that the credential is strictly tied to a particular domain, the one on which it was set, that too is highly dependent on the client (browser) doing the right thing. Additionally you have to count on the server to not get compromised as well (There is a a feature to support multiple domains).
Most importantly, when you make something this hard and complex to understand then be advised that people are going to make mistakes in implementation and leave gaps in security.
- 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.
In fact WebAuthn is explicit that you should allow multiple tokens. But every time I see an HN thread it has people who insist this doesn't work or at least isn't common. When asked for examples, if they give any answers...
1. Most often these are sites where you can't use this technology at all. They'll have TOTP or something and apparently "I don't know anything about this" == "I know everything there is to know about this topic" in the increasingly LLM-crazy world we inhabit.
2. Usually otherwise it's AWS. Which is pretty annoying, but it's one site. I have like a couple of dozen places where I use WebAuthn and in all of those two (or three, or in a few cases four) tokens are enrolled. I don't have an AWS account, my employer is a Microsoft-only shop in this respect.
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.
Yes, it's pretty common.
Paranoid password printing with a Raspberry Pi
https://7402.org/blog/2020/paranoid-password-printing-pi.html[deleted]
[1] To be more accurate, although it was always proprietary, 1Password was also local-only at first, with syncing only supported by putting it on something like Dropbox. They only added native cloud syncing later and eventually made it cloud-first.
Passkeys only work on the domain they were created for. Password managers usually default to providing the password of the current website, but nothing stops you from pasting that in at any site.
There is no danger to the credential db being stolen. The website only has your public key.
A website using passkeys can support cross device authentication which allows you to login to on a computer without it ever seeing your credentials.
I'm sure that isn't a complete list. My last point, despite all the comments here, there is no vendor lock in. Bitwarden provides an open source self hostable option. On both Android and Windows 11, you can change your passkey provider to Bitwarden. A proper passkey implementation, should allow multiple passkeys to provide access. My bank does exactly that.
Considering how my bank has changed the sign-in domain three times (as well as some other sites), I consider this a feature, not a shortcoming.
Then passkeys doesn't provide any real value if you have other less secure recovery option.
Let's say I have a bank account, going to the branch and doing an in person ID check is a valid recovery option, but nobody would want to do that just to log in from a new device.
> It isn’t useless, point is you don’t get to type in your password on a device that has passkey generated already, or get phished on a fake web address for example.
That's solved by letting the browser to remember the passwords.
> Passkeys are meant to be protected by either PIN or biometrics, however they are also meant to be revocable on the web, at least they are for services i’ve been using with passkeys.
PIN and biometrics doesn't have any inherent security. They rely on some hardware (or software separated from main system) feature, and even those can have vulnerabilities.
Also PIN or biometrics verification to access passkey from device bound TPM or security enclave solved the problem you implied might happen, such as losing your device. How do you protect your password manager, if any?
> even those can have vulnerabilities.
We shouldn’t just give up because everything is inherently insecure.
True, but no sane way to mass revoke Passkeys from stolen / lost device is just bad design.
This is not some conspiracy, and again has nothing to do with the fact that I can export my key passes
I don’t get the activism here
Wow. Roughly how many entries do you have and how do you handle updates? I'm often being asked to change passwords and of course create new login entries.
I don't reprint for every password change. I will for major accounts. I will also immediately print for certain new accounts but not all (e.g. I didn't reprint for my HN account).
The Strongbox printout has the last printed date on it and my KeePass plugin even includes the SHA256 of the KDBX file just to be sure.
The main point is the average Joe it works seamless. And average Joe won't have to remember things.
Yes, it does. Not everyone wants to maintain password database.
I went to `github.com` in chrome (not my default browser) and firefox and tried to sign in with pass key. I never even got a prompt from 1password to unlock to use the pass key, just a "no pass keys available" message from what looks like the system UI.
When I go to passwords & passkeys, 1password is the only item listed under preferred service. Google shows up under additional services but I have the toggle set to off.
so yeah, I just auto-fill my username and password like it's 2018.
Which approximately no one is using yet. Maybe in two weeks, when the new Samsung flagships roll out, to two months, when they start updating current generation devices...
> to 1Password works fine in Chrome and Firefox to log in to any site, presenting passkeys managed in 1Password.
Perhaps. But does it work with System Web UI, which I imagine is Chrome but have no clue how it's accessed?
Use this then totally offline
I don't have a citation for you just recent experience, do you have a citation?
My credit union has people who can help with any online banking/website login issues. They aren't tellers, but they are there. You just need to ask to speak to a customer service rep.
Yubikey tried to solve this, for obvious reasons. Their proposal was DOA.
[deleted]