Not so easy.
I've worked at places where we use a password manager to manage lots of passwords for random services that we subscribe to. The engineering manager always says "you can put your own passwords in for free" and I say "no thanks, they're going to get hacked" and then six months later... they get hacked.
I use the password manager on my iPhone because it seems pretty secure and it is so miserable to type passwords in on a phone but my other solution for passwords has used cryptographic generation with the database playing only a secondary role and it is fine for passwords but does nothing for passkeys.
most will come with free personal accounts for employees, if they want and choose to set them up. those are separate, and have smooth offboarding for the no-longer-employee.
"free" because im not sure if your employer pays for it or if its like a free benefit to a bussiness licence
- User account with access to the SaaS password manager was compromised.
- User account with access to the SaaS password manager was compromised.
- User account with access to the SaaS password manager was compromised.
- Password safe file (keepass) was compromised/leaked and its (medium-strength) master password was presumably brute-forced.
EDIT forgot one:
- Password manager was used by a user-facing web backend, which unlocked it with an unscoped read-everything master password. Web backend was hacked, predictable consequences ensued.
Ideally you should be isolating your passwords across the company so that one user doesn’t compromise every login, no?
If I had to trade off the risk of a password manager being hacked versus password re-use, I'm going to strongly recommend to people generally to use a password manager. Yeah there's a lots of "if this, if that"--but that's almost a universally better risk for most people.
Can you help me figure out some things?
1. One time when I was abroad in Poland, a thief walked into my room at night and stole my wallet, phone, and laptop.
(The thief was eventually caught 6 months later, but that's another story).
Question: what to do in that case if I were using passkeys?
Is there a solution that doesn't require trusting a cloud provider?
2. Currently passkeys are offered as an alternative to passwords. What are the mechanisms that require passwords to be available as well?
I.e. what stops my bank from simply giving me a passkey at a branch and offering no other option?
3. Clouds are currently the easiest way to use passkeys. Last time I checked, you were locked into that cloud, but things move fast.
What ensures the ability to move the keys out of the cloud?
And what do I need to do to have my own "cloud" like that?
4. What protection does the passkey ecosystem offer for physical threat to the user?
With passwords, there's no way for anyone to know which Hacker News accounts are mine, or whether I still have access to them. I don't remember has plausible deniability (who hasn't ever forgotten a password?).
With passkeys, getting detained with your device means surrendering all your passwords, to my understanding.
What am I missing?
Thanks!
Until we change our laws in the US on this front, I will continue to use passwords and hardware keys separate from my phone box.
no thanks, passwords are not a burden to me
Do passkeys have issues? Sure. Most of them are UX and are being worked on. As a user, I 1000% immediately register a passkey when a site or app offers it as at least on iOS and macOS, it is a superior user experience IMO and more secure. I never worry if I'm getting prompted for a Passkey, am I on the right site?
Also the remote connect functionality of modern browsers and mobile operating systems makes it trival if I need or want to sign into a personal account on my work PC where my personal passwords are not sync'd. Need to get into my personal GMail in an incognito window at work? No problem at all.
Anti-Passkey folks are just people who want to be against something to be against it
Plus, none of the sites that I use passkeys for would I be locked out. They all have account recovery procedures just like if I forgot my password. And, finally, for the important ones like my Google account (where my email lives) I have other non-Apple devices like a Yubikey setup as additional Passkey/FIDO authenticators
> If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that?
Any of them? All of them?
"Starting next year, only Google Authenticator and Google Chome passkeys will be valid for gmail logins. Help us keep your account safe by limiting access so ONLY YOU can read your emails"
"Good news! Your Instagram account is getting safer from hackers and spammers. As of next month, you'll use your Meta Metaverse token for all logins to Instagram, Facebook, Theads and WhatsApp"
Google already forced OAuth2 on Thunderbird [0] and the rest of the email-client universe.
[0] https://support.mozilla.org/en-US/kb/automatic-conversion-go...
The whole point of OAuth2 is to allow logging in to some untrusted 3rd party site via an authentication provider without having to key your password into the 3rd party site.
a) Local client software like Thunderbird is/must be trusted, it's not a random 3rd party website.
b) App passwords remove the risk of Thunderbird stealing your password, even if for some reason you didn't like typing a password into Thunderbird.
c) Google is both the Authentication Provider and the Resource Server in this example, so it adds zero security.
When a website prompts me to set up a passkey, depending on the device I happen to be using at the time it could end up going to Google password manager, Samsung password manager, iCloud Keychain, or Windows somethingorother.
What happens when I go to the same site on a different platform? What if I can't use cross-device authentication because I'm on a locked-down work machine or one that simply doesn't have bluetooth? What if I want to consolidate them all in one platform just for the sake of being organised? What if I lose or simply don't have the device with a certain passkey near me?
I don't have the time or patience to work out any of that, which might absolutely be a 'me' problem, but TOTPs are pretty sodding frictionless in comparison. Scan QR in my chosen manager; type number into website; done. Why are passkeys better?
I think passkeys make a messy credential situation even messier, but make a tidy credential situation even tidier.
I still prefer a good password written down in a paper book, with multiple methods of 2FA. But I know there are attack vectors for that.
The problem to me is that passkeys assume the user owns the device and CAN choose to make a single store authoritative for their credentials. The only professional environments I've encountered that haven't/wouldn't hit this issue are ones small enough that they don't really have device or security governance in place which you can't use as a secure reference baseline.
It's true that passkeys do not require hardware and OS attestation today, so all of the specific examples you cite are true. But the point remains that that passkeys can be EASILY extended to require hardware and OS attestation, and this will happen.
Banks have already done this. Before using an app was optional. Play protect was optional. It's like my uncle ted used to say, techonolgy is not optional.
Passwords are client-neutral. Passkeys aren't: you can force a certain client, and now those clients can force an OS through attestation.
It happens now with 2fa today. I have gone through college for 4 years having to use this shitty duo mobile app and we have to take out our smartphones 20 times a day to do things and re-login after every 20 minutes.
anything can happen. if your passkey stops working because you're using it from your smart fridge to access your banking app, then just use your password anyway.
Am I missing something? "Attestation tells websites what the authenticator is but it doesn't tell the website what the authenticator is".
The entire argument in this blogpost amounts to "nobody would ever turn on passkey attestation because it would require migration of people who already setup passkeys" which is a questionable argument- you could trivially imagine allowing unattested passkeys for existing users, but require it for new users. Most websites don't yet support passkeys to begin with, so this argument doesn't hold for the majority of websites.
The "biggest providers" bit at the end is odd too because the biggest providers are apple/google- who, as far as I know, do support attestation.
That's where the trap is.
This is your cue to go get your parents to add you as recovery contacts for their Apple account now, rather than finding out that exists when they lose their phone.
It is plainly obvious that the worry isn't attestation per se, it's the restrictions that attestation may in the future require when they turn the dial on restrictiveness up, that was extremely clear to me from reading the first article. If you can get attestation without those restrictions, "sure, why not", and a Yubikey seems like a way to do that which could avoid those restrictions. Most of this article makes sense, but this particular line makes me wonder how the author got it so far off the mark.
They also did nothing to quell my fears that they will in the future use passkeys to prevent people from using software they can modify themselves by saying "...the guidance for consumer sites has been to not even request attestation for years now." as if everyone always followed the guidance, and as if there aren't tens of thousands of managers that think their case is special and they really do need the extra control because they're a bank or handle copyrighted content or have PII or PCI and feel extra risk-averse today.
I don't know if they failed to do so because they can't (and this is a valid fear of the original author) or if they just are bad at reading the room at what the concern is and vastly overestimate how much people trust companies to always have their best interests at heart.
What I am getting from this, though, is "If you authenticate with a yubikey then that's attested, so they can't use attestation through passkeys to make sure your OS and browser aren't modified", and I'm not sure if that's the correct take away or even a correct statement.
Attestation is never to your advantage. To do it at all, they have to restrict you to a specific set of device manufacturers and yours may not be on the list.
Then, what does it get you? Google-approved Android phones are allowed, but any attacker can trivially get one of those so knowing it's that type of device is completely worthless. All it does is prevent you from using some other type of device.
Notice that this is different from keeping the key in a HSM, which you can do without remote attestation and without the other side having to do anything at all.
Worse, the "approved" devices often have worse security than the one you want to use, e.g. using a Yubikey as your HSM will generally be better than using a phone which has orders of magnitude more attack surface and is constantly connected to the internet, but the phone is way more likely to be on the approved list than the Yubikey.
> If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.
This isn't a rebuttal to the claim that they're a hidden dial. It's just saying that it's too early to crank the dial.
>Attestation Isn't What You Think It Is
>The post describes attestation as proving "that an approved passkey manager, operating system, and firmware are in use" which is simply not true.
>When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
This point is bypassed by websites only supporting specific authenticators and then those specific authenticators only supporting specific devices/OSs/browsers/etc via other attestation frameworks.
The big players who want to gatekeep you in their ecosystem do not want attestation - they want you to give them your passkeys for them to store under the guise of "hey, we'll sync it for you!".
A yubikey is easy to use. Buy a second as back-up. If you're clumsy and lose things all the time then set up recovery codes. Add a recovery contact. Use insecure 2fa like TOTP or really insecure 2fa like email/sms/etc. codes.
There's plenty of options for authentication in the modern world and passkeys are at the top. If users are 'too stupid' to use them then that's a user problem.
I'd rather spend the 5 minutes reading how these things work and then not hand the keys over to big tech.
Passwords just suck. If we're all going to use password managers anyway, what is the point? Might as well use a randomly generated passkey.
>If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that?
The original didn't argue that, nor has absolutely anyone else concerned, nor has that been what has happened in historical examples people were concerned about. Because yeah of course that's ridiculous, it's "boiling a frog" by throwing it in already boiling water, that's not how it works. If anyone has freedom-reducing longer term plans for use of passkey attestation, the emphasis is on "longer term", being malicious doesn't mean being stupid. Step 1 is obviously getting people into the passkey ecosystem and out of passwords at all, which could well take years. And importantly as much as possible into closed passkey ecosystems. This is indeed one of the initial danger signs, because the author:
>iCloud Keychain, Google Password Manager, 1Password, Bitwarden
Is mixing together things that aren't like the other. Quick author, what's the EXPORT story for each of these ecosystems? Of those, Bitwarden can export a passkey into a plain JSON if you want. Do the others support that too, or at best only "app to app" encrypted transfer, creating a closed ecosystem? Already, can I get passkeys from iCloud/Google/1Pass into KeePass? Or is this restricted """for my protection :^)"""?
Author doesn't even touch on the lock-in that's already beginning. And right now everyone can technically claim "oh no of course you're not locked in! You just have to use an official option, or you can merely visit hundreds of sites individually and register new passkeys in all of them". Is it hard to see how players like Bitwarden would be pressured on continuing to offer plain export?
Then when most of the population is using passkeys everywhere in a closed ecosystem, now what is the response if friction slowly starts getting added. OK, you can still use what you like, but only export to other approved players. OK, you can still use unattested, but it's off by default now, "advanced users" can go enable it with this checkbox in the settings. OK, manual is still an option, but now it's buried deep and behind dark patterns and requires a text command. Hi everyone, we have statistics to show that only 0.85% of our users still use unattested keys. The support burden and security risk is now too high."
Like, we've seen this movie before.
I know where my password manager syncs, it's on all my devices. Passkey prompts always seem confusing, I don't know if it's going to save to my browser, or my OS, or if those are gonna sync on what devices. It's just more confusing.
What would I gain from using a passkey?
This cannot happen with passkeys at all because crypto magic.
My password manager matches off of domains too, so it wouldn't suggest to autofill on a phishing site.
And the solution was: make it the user's problem.
Yay.
> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
So if I was Netflix or a bank or w/ever I'd only allow new registrations from "trusted" authenticators, which would incidentally only run on iOS and play-protected Android.
> In fact there are many different things called “passkeys” and the FIDO Alliance has intentionally named all of them the same thing. I believe this was done in order to deliberately confuse users and encourage them not to look too closely at the fine text.
Passkeys face the same problem as the USB-C rollout. Lots of different incompatible implementations and standards rolled under one name that are almost impossible to distinguish between. Very little education on how to use it and be prepared for it.
The difference is that the consequences of getting passkeys wrong for the user is significantly greater than getting the wrong cable, and while the latter can easily be fixed, the former may be irreversible.
I keep seeing major players promoting their own apps over standard TOTP, which I guess could be seen as a sort of proprietary passkey. Shopify, Google, Microsoft, and more, they all want you to download their app for MFA, instead of using a very open format.
As someone who works in IT, I just can't even imagine myself doing this. I have probably around 60 codes in my Aegis, how would it look if I had just a quarter of those in apps instead?
But the main issue I have with passkeys is the simple issue of backups. I can backup my Aegis keys, I can't backup an app, or a hw passkey. I have to get a second one, and keep signing for it or something, not sure of the details, I just know it would be a major hassle. And there is no way I'm trusting a little usb device to not break.
Right now I see no compelling reason to switch from regular OTP codes, change my mind.
The phishing potential?
Currently they aren't tied to that root of trust.
Most of those organizations have shown that they don't want people owning their own devices or being able to run their own software, and they use developer attestations, IE a revocable programming license to accomplish that.
Tools like android's safetynet makes it so that you can't run banking apps on a phone running your own software. One that bypasses developer attestations.
Passkeys are currently an open standard, but attestation is built in such a way as that it could be only usable on n approved operating system with programmer licenses.
Big websites like amazon, or websites you need to exist in society, could gradually start requiring the usage of attested passkeys.
---
There is a clear path from passkeys to the death of general purpose computing for 99% of people. Don't be a useful idiot, don't assume these corporations have your best interest in heart. See this for what it is, a path towards killing people's ability to run unlicensed software on their own devices.
True, but doesn’t actually refute the original.
I don't know when it started, I don't know who is to blame, but we've definitely arrived at a conceptualization of "the user" that is passive, uncurious, and incapable of being talked to like an adult.
Maybe it was too strong to say the were a "trap", but it is also too strong to say there is no worries here.
Me: The person who posted this post critical of The King on Facebook was totally not me!
Police: Here's "a WebAuthn attestation" that told Facebook "the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up" and it fits Evidence A.
No thanks.
I think they've been implemented well in some cases. I think they've been implemented poorly in others.
So it goes.
A defining feature of traps is that they start out good.
There are a lot of good points in this article, but it fundamentally missed the point of the word trap. The most it said on that topic is:
> If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.
I have to admit I don't worry too much about the entire internet flicking attestation=true anytime though, because the resulting support nightmare would be ferociously expensive. I wouldn't be surprised that, on its own, it would be more expensive than the cases that the companies flipping the switch are trying to avoid. Which means it isn't going to happen.
The simple truth is metaphorical-Grandma can't handle the degree of responsibility put on the user that strict hardware attestation implies. Netflix et al are more likely to want metaphorical-Grandma's money more than an incremental improvement in their ability to be sure it's an attested login, and won't want metaphorical-Grandma to call Netflix every other week trying to figure out how to log in again.
The spec requires passwords to still be an option, they say, so there's nothing to see here, move along — and avert their eyes should an inconvenient argument come their way.
Because, see, we all know that specs are ironclad, never change, and are always fully implemented.
Also, putting all your eggs, ahem, passkeys into one cloud basket (as this article recommends) to "move around" is surely the most best solution better than passwords.
Because we can always trust the cloud, right? Not like it's somebody else's computer or anything, that they can instruct to not do what you tell it.
Anyway, none of the passkey lovers ever answered me what to do if my computer and cell phone ever get stolen again when I'm traveling abroad in the Brave New Passkey World.
The best answer I got was carry a yubikey with me at all times.
One more thing to worry about losing, yay. Much convenience, very security, wow.
If there are any new developments on that front, would love to hear them.
On topic, I’m not sure I even trust my own password sanitation, and seeing service A and B hacked every other month, I feel weary. Knowing that someday my passwords might be compromised as well, so what should I do as just a person who can’t remember things? Write them down, I guess.
Which in turn makes it harder to track vs. your /64 which is approximates your old NAT'd public IPv4.
> Thankfully someone with some sense
Cannot be asserted with this:
> I saw that post title and didn't even bother to read it.
If it was easy to migrate between services, then i would be a lot more open to using passkeys.
Also, many if not all of the sites I've got passkeys setup with support multiple keys, which I sometimes take advantage of. For example I've got a passkey into my Google account in my Apple account ecosystem but I also have a physical Yubikey setup as a Passkey device, in case I were to get locked out of my Apple account
Now they expect you to always use them to login on all devices.
I had to remove my passkey from one device for these services because i also use a PasswordManager and I do not trust my local chrome installation to just manage my passkey.
I want to have a Password Manager which I need to unlock when I use it. I also want to keep my 2fa and not break it due to passkey usage.
GitHub was also super shitty with it, suddenly a passkey broke my YubiKey login...
On my MacBook with the latest macOS I still can't use them.
I use Brave and 1Password. Clicking the Use Passkey button typically results in some Chrome Bluetooth permission dialog rather than accessing my PassKeys.
I tried to look into this once or twice with no success.
I suspect macOS is at fault. Apple does not seem to care about getting basic functionality right.
To this day Universal Clipboard between the MacBook and my iPhone does not work half of the time.
Do you have bluetooth disabled half of the time?
I believe a reboot sometimes restores functionality.
One might say "just use a password/credentials manager", but all these passkey prompts don't emphasize that you should use one that is not tied to hardware, or that you should backup your passkey to a thumb drive, or anything like that.
Same reason I hate TOTP that is tied to a device. If you require me to have proprietary 2FA apps on my phone to login to your account, I don't use 2FA. Looking at you, Steam.
An app password is basically just an API token, it's up to the backend what powers it grants.
Also, is there a reason Thunderbird or other clients couldn't use OAuth? I'm fairly certain I can login to GMail on Mail.app in macOS and other clients, so they're not using that to lock people into the official app or their browser
I assume Mail.app had to do the same.
OAuth wasn't about lock-in (since any client can support it), it was about getting off shitty legacy auth
You shouldn't need a web browser to read email.
Isn't that a single vendor (or two)? How is this not lock-in?
> Store your data anywhere you like, online or offline. Sync with every major cloud storage provider or your own server over WebDAV or SFTP. Use your Strongbox database with any KeePass compatible client on any platform.
Please explain how self hosting open source software is locking me into a vendor.
There are an open standard. You just have terrible software.
Microsoft Authenticator, Bitwarden, 1Password, etc. all support storing passkeys and support multiple hardware platforms.
It also requires foresight if switching. I ran into this with 2FA as well. When I got a new phone, after setup it offered to wipe the old one, I declined. When I went to open my 2FA app for work on the new phone, it needed to be setup. I needed the 2FA on my old phone to login to the portal and setup the new phone. Had I wiped my old phone when prompted, I would have been locked out and on the phone with the help desk. This same scenario can happen with Passkeys.
"What happens when I go to the same site on a different platform?" = "If you meant device, then Chrome has a feature to allow you to use a different device such as a NFC YubiKey"
"What if I can't use cross-device authentication because I'm on a locked-down work machine or one that simply doesn't have bluetooth?" = "Good, Passkeys are doing their job correctly and you cannot export credentials"
"What if I want to consolidate them all in one platform just for the sake of being organised?" = "Then log in and add more passkeys to things rather than copy-pasting passwords everywhere"
"What if I lose or simply don't have the device with a certain passkey near me?" = "You should have multiple passkey's or use the various cloud versions that exist"
I'm perfectly happy to take responsibility — when using a well-designed system that isn't a massive pain-in-the-arse up front designed for vendor lock-in and to penalize small vendors.
Criticizing the new system isn't avoidance of responsibility, it is demanding a product that is worth using, i.e., NOT designed for the manufacturers to extract more money from us without providing more value or locking in their market position, but designed to be actually useful.
The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows, but every time I'm urged by a site to convert to a passkey, I wonder "is this site the sort that would screw this up?"
So far, it's about 30% of sites screwing it up...
I can’t adopt Passkeys if I’m not certain they’re going to work as well as my password manager and Authenticator app, which is to say 100% of the time.
When sites ask to set up passkeys, it’s usually native passkeys (especially on iOS). And figuring out how to get the flow to set up a LastPass key by default seems unusually difficult.
I also use a MacBook, windows desktop, an iPhone and iPad. I use Firefox, edge, brave across these devices.
When I say “passkeys are a trap” they are a usability trap where no one can attest with certainty that I won’t wake up in a painful situation because I decided to adopt passkeys.
Passkeys provide perfect protection from phishing attacks, since it's impossible to send a passkey to the wrong domain. That's a huge improvement over TOTP.
Re: it being confusing where they're stored, I agree. The solution is to make sure you store your passkeys in your cross-platform password manager. The experience can be confusing though. In Chrome I've found that by default when creating a new Passkey Chrome offers to store it first. But if I click cancel, I'm then given the option to store it in 1Password where I want it.
What do passkeys offer users that rand strong password + password managers don't?
They have to be transmitted. They (or their hash) have to be stored. And so so many get that wrong.
There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.
Passkeys don’t get transmitted. They’re used for cryptographic signing.
Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
You can’t store a passkey wrong on the server, it’s a unique public key. If your entire database is stolen, it’s useless. No one else can login with your credentials because they don’t have the private key.
Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
Passwords are fundamentally broken. They cannot be fixed. Cryptography is the solution in passkeys are the implementation.
Do they? I don't sign up for random Joe websites. I feel pretty confident that nobody is storing my creds in plaintext, right now.
What I am concerned about is that Passkeys will become a mechanism for enforcing hardware attestation. I don't trust the industry to implement it neutrally.
But in my opinion, the solutions that passkeys provide come with the costs that are being discussed here, and I haven't found the trade-off worthwhile.
If it gets lost for whatever reason, I don't care, I will login again with regular username/password.
So as long as you also have a regular username/password login, phone passkeys are great time savers.
Now they run "Officers are watching! Click it or ticket!" as an advertising campaign.
And I'm not arguing that seatbelt laws are bad per se, just that any time there is a pathway for more control, it will eventually be taken, even if assurances are made that it will not happen.
Like SecureBoot.
The whole point is that once everyone is accustomed to passkeys, they ARE going to ratchet it up to "you need attestation".
This is the browser wars all over again. Google spent something like 20 years winning the browser wars, and once they felt snug and secure, slowly started eroding users' abilities to control the content they see (making features adblock relies on increasingly ineffective).
At the same time the current authentication horseshit of the internet in 2026 is awful. I routinely spend 3+ minutes trying to log into a site - first it blocks logins because of my VPN, then it requires a password reset, then it requires me to login with new password, but then it needs email verification, but then I don't get the email so I have to click resend, then I type in the verification and then it asks for blah blah blah.
I am grateful that LLMs are going to be doing 95% of my browser usage very soon.
mik1998•37m ago
undersuit•26m ago