I don't know enough to argue about whether passkeys are a trap or not, but I do know as a user that they appear to be a confusing mess.
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?
So in my own experience, the same tool I use for TOTP is the one I use for passkeys, suggesting it’s at least possible for passkeys to be as frictionless as TOTP.
On the rare occasion I’m logging into a device that isn’t mine, that doesn’t have my password manager on it, scanning a QR code from a device that does have my password manager on it has been enough to get me in. Without sharing any secrets with the foreign device, incidentally
So I’d wager your concerns are valid and are likely to be addressed over time, as this stuff develops rapidly. It might even be better in your scenarios already
Lately it has been a tap-tap operation to enroll a passkey. Sweetwater.com surprised me with it the other day. I was done in seconds, and now I can log in without even having to enter a code. Face ID handles it for both iCloud Keychain and Bitwarden
I thought "Passkeys are a trap" was going to be about this usability nightmare. Some sites, once connected via passkey, make it all but impossible to connect in another way. Some support multiple passkeys. Some do not. Some support passkey or something else. Some do not.
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?"
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.
It's ironic that passkeys are most usable in conjunction with a password manager that syncs them across all of a user's devices, but this is also the scenario where they have the least security benefit over traditional passwords.
I do appreciate that passkey adoption has led to wider support for hardware security tokens for sites where I actually care about increased security over password managers, however.
The specific security benefit is that there's no way for a tech-stupid person, or a tech-literate person who's short on sleep, to copy paste their password into p4ypal.com instead of PayPal.com.
Yes but if you have a password manager that's set up well you'll never be copy pasting passwords in the first place. If the password doesn't show up you know there's a problem.
The benefit of a passkey here isn't zero but it's at the minimum.
From my experience, passkeys work great in the Apple ecosystem. Adding a passkey for a new site on my Mac results in that passkey syncing automatically on my iPhone and iPad via iCloud.
"But what if I lose all of my Apple devices in a freak boating accident?" people often ask or something like it. Apple has a procedure for this [1].
You can contact your "recovery contact" (a trusted friend or family member) that can help authenticate you to regain access to your account, especially if you're locked out or forgot your password.
On a new device, you login to your Apple account, make sure iCloud Keychain is enabled, and all of your credentials, including your passkeys, sync to your device.
I get it—not everyone wants or uses iCloud. Apparently, you can use 3rd party password managers like 1Password, Bitwarden, etc. to backup and recover your passkeys to use elsewhere.
Here's a video of an export from 1Password to the Passwords app on an iPhone [2].
So the solution to my iDevice dying is that I have to buy a new one to maintain access to my accounts and have no option to move to non-Apple hardware?
But what I don't understand is how are passkeys improving what Apple provides here. You could have just done this with passwords and had all the ecosystem benefits you outlined.
The 1password integration works great IME. When a site supports passkeys, 1password seems to offer to save the passkey, and at login time, a little popup appears from 1password asking if I want to use my passkey, and I can either enter my password, or use TouchID to unlock 1password.
I use this across iPhone, MacOS and Windows, and haven't run into any issues.
As mentioned a cross-platform password manager like Bitwarden is the way to go in this case. But yeah, the vast majority of internet users don’t use one.
I think the repeated posts and articles constantly rehashing this topic is telling. Every thread is nearly the same in terms of some people saying “here are the reasons why passkeys don’t work for me” and other people saying “you’re holding it wrong”. I don’t think many people come away with their views changed.
In my experience iCloud Passwords is a superior cross-platform password manager than LastPass today, so I’d recommend going in the other direction. (Source: I switched from LastPass to Passwords a couple of years ago.)
I’ve never seen an implementation where passkeys deleted my password or could lead to a situation where it was locked out. They usually just bypass the password+2fa dance when functioning, and otherwise just don’t matter if they don’t function. (Well perhaps except home depot, where it gets mad at me every time I use a password and tries to install a new copy of the same broken passkey as last time, for my convience)
This sounds like an iOS problem. Bitwarden + Firefox on Linux, or Bitwarden + Android, has never been anything but smooth for me when it comes to saving or using Passkeys.
If we go for anecdotal examples that are not representative, then in my case, Bitwarden passkey use ends in an endless loop with most websites. Import and export is still a promise or "coming soon." In the case of hardware keys, two devices are needed. I was a proponent of passkeys, but big players screwed that up, like every single shared "standard".
iOS has really good support for third party Password Managers. I've seen the integration with both Strongbox and 1Password. I've heard Bitwarden supports it as well. I think it is a Lastpass problem in this specific case.
If you need a tutorial for something that’s supposed to be as simple and transparent as a website authentication, your standard has already failed the usability test.
This isn't a standards problem, this is an "Apple, Google, and Microsoft made using your own software difficult" problem. They have an interest in making their authenticators the default, and the settings UX on all three platforms makes it unclear that their authenticator is active as well as your own "third-party" authenticator choice.
It’s difficult to disentangle one from another, when the companies with the vested financial interest in locking you in are the board members of the consortium creating the standard.
The standard doesn't dictate the UX of settings screens. That's entirely on the platforms which own the screens and I would hope that is kept out of already-huge standards like WebAuthn.
Exactly. I'm disinclined to cut Apple, Google, and MS the benefit of doubt for steering a standards committee to spec + real world usage that privileges themselves.
you can see in both the lastpassword and the bitwarden tutorials that the default iOS password manager can be toggled on or off, just like the other options.
you're misunderstanding: this isn't specific to passkeys, this is for changing the password manager(s) used when filling passwords, 2fa codes and passkeys.
since the person I responded to couldn't find it, I linked tutorials. it amounts to opening the Settings app, going to "General" and then "AutoFill & Passwords", so it's also not terribly difficult to find compared to other iOS settings.
you could've at least tried to understand what's being talked about before blindly complaining.
Supporting multiple passkeys should be a minimum requirement for every Passkey implementation. It's generally worth naming and shaming the websites that don't implement that correctly. People want backup passkeys. People want both iOS keys and Windows keys for the most convenience.
My general advice for non-technical users that seems to work pretty well is "sign up for new sites with passkeys on your phone" because most non-technical people trust the password manager ecosystem on their phone, have some amount of multi-device sync already established, and the QR code started Bluetooth LE flow on desktop/Windows PCs for sharing passkeys works easiest with phone passkeys.
(I run a tiny site that is Passkey Only for login and it's been interesting providing technical support for it. One of the biggest recurring issues at this point is nothing in the Passkey flows themselves but the fact that the Facebook in app browser does not support Passkeys for a number of presumably security reasons, plus Meta being jerks, and having to remind new users to "Open in External Browser" before signing up/logging in when posting links to the site in Facebook.)
> The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows
It's still just biometrics as "device PIN". The crucial difference remains that the biometric data never leaves your device. To support Passkeys the remote website only ever sees your Passkeys' public keys, they never see biometric data, they never have a chance to store biometric data in a database to violate PII/HIPPAA/etc standards when it inevitably leaks to "hackers" (or gets sold to the highest bidder).
My takeway from “Passkeys are a trap” is that there are like four different approaches to something that everyone just calls “passkeys”, and they are not the same. For example, some are portable and some are not.
> Some sites, once connected via passkey, make it all but impossible to connect in another way.
That's the issue I had with Okta a few years back. I used a password then later added a passkey through Bitwarden on my work laptop. Bitwarden hadn't yet implemented passkeys for mobile.
I went to authenticate through Okta on my work phone. It prompted me for the passkey. Since mobile passkeys didn't exist, I got stonewalled. I had to make a blood sacrifice just to get Okta to allow password access again.
This is why I don’t like passkeys. I’m surprised the “use site from multiple devices” use case isn’t more common.
Am I nuts for accessing a site from both my mobile phone as well as from the multiple computers I use?
This also gets super messy when combined with multi-site auth services like id.me where I need to use the same login to access very diverse sites and services from multiple computers (eg, irs.gov, treasurydirect.gov, disburser.treasury.gov).
Same. I don't understand it, and there is enough conflicting information (See this article pair as an example) that I suspect it's not something where I just need to do more reading. I suspect there's something fundamentally confusing, and subjectively-interpretable about this.
My suspicion: There is a significant chance I will lose access to one or more account by doing this, so I'm not going to until the air clears. I don't trust the motivations of the services pushing it.
This may or may not help depending on how technical you are, but at the core a passkey works through public key cryptography, like SSH keys work. Setting up a passkey with a site involves sending a public key to the site, which they store as being owned by your account. Then, to sign in, they use your public key to generate a challenge, you use your private key to solve the challenge, and you respond proving you have the corresponding private key.
This means you never send your private key to the site, so if their database is compromised they only get a public key, which can’t do anything (it is public, after all)
No amount of phishing can get you or your client to hand over your private key, because there is no use case where that is required. There is no possibility of MITM, since your private key is never sent anywhere in any situation.
As for getting locked out of your account, losing your passkey would be the same as losing a password. You would need to follow the site’s password reset flow, and if you can recover from a lost password, you can recover from a lost passkey.
This is a fantastic explanation and analogy. Thank you!
I will poke at this a bit:
> As for getting locked out of your account, losing your passkey would be the same as losing a password. You would need to follow the site’s password reset flow, and if you can recover from a lost password, you can recover from a lost passkey.
Do you think this is one of those scenarios that sounds reasonable at first, but can get torn apart by unknowns, edge cases etc? To use an analogy from a recent HN thread that is stretched a bit, is this like saying "If you use a crypto hardware wallet, you're safe", then reading about compromised hardware wallets due to something outside the assumption set.
The threat models here are often very similar to existing Password Manager threat models. If an attacker gets access to your Password Manager they get access to every password you have stored there and can do what they like with that information. The same applies to your Passkey Manager, which in many cases (including for your own peace of mind) is/should be the same app/vault as your Password Manager for other types of passwords.
A lot of the same Password Manager requirements and best practices apply to Passkey Management such as using strong master passwords or biometric unlocks or device PINs. Using Password Managers that support device bound hardware security enclaves, etc.
But even more so than average Password Management, because Passkeys are public key infrastructure the benefits you get out of the box exceed those of ordinary passwords. One of the factors in most Passkey implementations here is that sites (defined by hostname) all get different public keys. (Users are suggested to use different passwords for every site, but are not required to. Passkeys do that technically and are generally enforced in that effort by browsers and Operating Systems.) Leaking those public keys is no longer an issue (they truly are public keys), and leaked public keys aren't generally useful to other sites and apps. (Passwords that leak and even sometimes salted and hashed passwords that leak are liabilities and can be useful for rainbow table attacks or social engineering attacks or password reuse attacks.)
There are certainly edge cases to Passkey Management but in general the threat models follow Password Management threats: does someone have physical access to your device? Do they have access to your biometrics or device PINs?
But also the blast radius is reduced compared to usual Password Management threats: a single leaked private key generally only impacts a single website/app. Being able to sign a Passkey challenge once doesn't mean unlimited access (a password can be used forever after finding it), because challenges have timestamps and random entropy and generally don't support replay at all.
Passkeys also open up other use cases like using a mobile device or hardware security token to log into sites from public computers, which, while not risk-free (targeted malware could still hijack your session while you're logged in), is still significantly safer than giving the public computer a password.
This is roughly analogous to the difference between swiped/card not present and chip/NFC credit card payments. While a hacked chip/NFC credit card terminal could display a different amount than actually charged, it can't subsequently make additional charges after the card or device is withdrawn.
If you own only one device—a mobile phone, like the majority of people in the world—and you lose it, how do you get back into your passkey-protected email account?
This is site-specific, but typically by using the same mechanisms used to reset forgotten passwords.
Also, sites can and often do support multiple passkeys, which opens up the possibility of allowing for reliable account recovery using one or more backup devices (one or more YubiKeys, for instance) that is still siginificantly more secure than reset flows using SMS or email.
Most Passkey implementations by default are syncable/copyable/backupable. The iOS default is iCloud Password Manager and keys get backed up to iCloud and restored on device restore when replacing a phone (just like the rest of the users passwords they choose to store). Android has similar defaults with the Chrome Password Manager.
What’s PQ story with passkeys? Considering all the hype that everything needs to be pq safe by 2029 (or whatever), wouldn’t it make sense to delay adoption? Otherwise a db leak would compromise every single account in a pq world.
Most Passkeys use PQ PKI algorithms. From statistics I've seen most are Elliptic Curve on currently recommended PQ curves.
For better and worse, Webauthn is one of the "choose your own adventure" PKI systems where the keys themselves suggest which PKI algorithm/details they use. This is partly because Webauthn has been around a long time and has had to backwards compatibly support a wide variety of physical security keys over the ages.
Most good open source libraries for implementing passkeys will do a good job of limiting passkeys to known good algorithm choices, including any PQ requirements/suggestions. The Passkey standard itself also sets a "higher water" baseline above Webauthn's supported algorithm list.
I don’t follow? What is a “currently recommended PQ curve”? As far as I understand, the entire point is that all ECC is broken by quantum computers, hence the hype to move to something else by 2029. Anyone that can see your public key can compute your private key.
My understanding is that some of the curves are still considered high enough entropy that the number of qubits needed is "unreasonable". The important point remains though that passkeys don't have a fixed encryption suite and can be updated over time.
Passkeys aren’t permanent, you can change or revoke them. If the algorithm used suddenly becomes vulnerable, you would need to rotate all your passkeys.
Sure. You’re assuming every site will revoke your passkey when that happens though. It also feels like a great time to trick people into registering an attacker passkey instead.
With the exception of general-purpose authentication services like Microsoft Entra ID where organizations can set pretty much arbitrary authentication requirements, I've yet to encounter a site where merely setting up a passkey disables other forms of authentication.
The benefit of adding additional authentication methods without disabling others is limited, of course, but it can still be useful where, e.g., you're comfortable logging in using a password manager on your own devices but want to use an iPhone or YubiKey to log in from public computers.
The easiest way to think of it is they are like ssh key auth where the keys are stored in your password manager.
I have no doubt users will get confused about which password manager they have their passkey stored in, but these are the same users who don't know what a password manager is so they share a password across everything and get hacked regularly.
It doesn't help that the primary benefit we get from passkeys, in exchange for a lot of pain and fragility, is that phishing is harder to pull off. That's a big deal for a lot of people, but frankly, I'm not one of them. I already know not to click on links in emails.
I've never fallen for a phishing attack and any attack targeted and sophisticated enough to catch me is probably going to be sophisticated enough to steal/hijack a passkey anyway. In the extremely improbable event that I did get phished and somebody got into my account somewhere, they'd only have access to that one account because unlike most people I don't re-use passwords and recovery would no more complicated than contacting customer service and resetting my password with them.
Considering the horror stories of people who been screwed by using passkeys, I'm sticking with "not worth the trouble"
The defining feature of passkeys is that they're stored in your password manager, and you can't read them, so you can't be tricked into typing them into the wrong web site.
Most password managers don't even allow you to export/backup the passkeys yourself. (Bitwarden is an exception.)
Instead, password managers support a finicky app-to-app transfer protocol called "Credential Exchange Protocol" (CXP), where you install two password managers at once, and they convey your passwords + passkeys, without ever generating a file that you can read. (And Microsoft's password manager doesn't even support CXP yet. As of today, you can only do it on Android and iOS.)
Many people read that and say, "see, that's why I'm never going to use passkeys! I'm safer managing my own backups, and I'm too smart to be tricked into copying and pasting my password to the wrong site." But they're wrong. You are not too smart to be tricked. Nobody is.
If you use the same cloud-sync password manager everywhere, passkeys just work. If you don't, you'll have to use Credential Exchange Protocol to transfer them, which is a hassle.
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.
> The defining feature of passkeys is that they're stored in your password manager, and you can't read them, so you can't be tricked into typing them into the wrong web site.
That's the biggest issue.
Haven't been tricked so far. On the other hand, I've had a couple of accounts locked because "we don't like your ip", "we want your phone number now", or "we want to send a push notification/text to the phone that just died".
Why would I trade control over my credentials for some potential security gains, while introducing new dependencies on Google, Apple, or whoever runs my password manager - and the very real risk of being locked out of all of my own accounts?
Maybe, but most websites I really dont care if my account gets hacked. I care way more about being able to login conveniently. Im just as frustrated with seemingly every single website wanting 2fa doing a 2fa check every week or less.
That actually works too. The PC shows a QR code you scan with your phone which negotiates the login. Doesn't require signing in with anything on the PC first.
I do this with my work laptop where the passkeys are stored on my personal phone.
> But they're wrong. You are not too smart to be tricked. Nobody is.
If my password manager is entering my password for me, so how can I be tricked? That's the superpower for passkeys, right? It also applies for plain passwords. Infact, if a login page looks familiar, but my password manager doesn't show any matching credentials, that throws up red flags for me, because I only use my password manager.
Because password managers allow you to use a password and 2fa even if the url doesn't match. And sites often legitimately change domain or have multiple domains which trains users that sometimes it doesn't work and you have to override the automatic matching.
Passkeys physically don't allow you to send them to the wrong sites so the sites have to make sure they keep working.
"Weird, my password manager isn't submitting my password properly. Well, that happens sometimes. I'll just copy and paste it" [or manually select a password to autofill]
> Many people read that and say, "see, that's why I'm never going to use passkeys! I'm safer managing my own backups, and I'm too smart to be tricked into copying and pasting my password to the wrong site." But they're wrong. You are not too smart to be tricked. Nobody is.
It is not remotely difficult to not fall for phishing attacks. I think I've seen one in my entire life which was actually well crafted such that a person might fall for it even if he was paying attention. One. Everything else is the lowest effort slop where all you need to do is hover over the link to see "this does not in fact go to microsoft.com like it claims".
Randomly generated strong passwords for all practical purposes are just as good as passkeys and keep you as the user in control. If you really need to copy/paste between a laptop and mobile or give it to a friend/family member, you can.
What do passkeys offer users that rand strong password + password managers don't?
They are tied to the issuing domain and the system that carries the passkey will refuse to present it to any other domains. It’s more or less impossible to fall for phishing or a spoofed site. Your password manager may have similar functionality for automatic filling of forms but less sophisticated users can often be tricked into providing passwords via copy and paste.
Phishing is even easier. Instead of "open your password manager, copy your password and paste it here" it becomes "your passkey is out of date, click here to enroll a new passkey. As part of this process a reset link will be sent to your email and code to your phone. Do not share the code with anyone."
The less sophisticated users can use their passkeys then, and the rest of us who know what we’re doing and have been for 25 years can continue to not support vendor and platform lock-in and forced device attestation. The amount of marketing and push behind passkeys does not feel entirely genuine to me.
You know how to feed the site certificate into gpg before every login to check for url phishing attacks? I usually have to ask my password manager to do that (which didn’t exist 25 years ago)
Bitwarden browser extension, and I imagine most other password managers, will only offer to auto-fill a password if the site matches. There's a setting to choose the exact rule, but the default is matching the domain name.
So if you get sent to goog1e.com, your password manager won't prompt you to enter your Google passwords. Though of course, you could still manually paste it in if you got somehow convinced that it's a legit site.
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 unique 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.
Everyone knows to hash passwords now and browsers basically enforce SSL. This is not a practical differentiator.
>Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).
>If your entire database is stolen, it’s useless.
As are databases containing strong randomly generated password hashes. What is your threat model here, they somehow forgot to hash their passwords yet they are still hashing session tokens, storing customer data in completely separate databases, safely storing private keys, etc.? It requires quite the strawman scenario to apply.
> They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).
This is only technically true because of the definition of what a passkey is is vague.
Hardware Attestation solves this problem and is "good actually". The issue with attestation is when site attempt to restrict which enclaves/sources can register keys. But if you don't restrict who/what can register keys, attestation is super useful for preventing this exact issue.
When you register your key initially you establish your hardware attestation parameters. The attacker cannot know those parameters unless they were the ones to initially register you for the site as the public attestation signature is unique per-key and the private one per-use with the public one verifying the private one.
So if you have remote attestation you can verify whether the source presenting the signature for auth is the same source that created the signature and trivially block MITM attacks. Likewise for more complicated custody/proxy chains.
This just by itself largely solves MITM key re-enrollment attacks but tech camps that support passkeys either ideologically oppose attestation (due to understandable enclosure fears) or enforce hardware attestation for enclosure purposes without bothering to address MITM/signature origin checks.
Can I do hardware attestation across several devices yet? My desktop, my phone, a console, my girlfriends phone of a different brand if I need to log into a shared account, etc?
It seems like one of those things that only works if you're sticking to one ecosystem.
Yes. You can register as many different passkeys as you want. Any limitation in passkeys registration quantity is a limitation of the website/app itself and not a limit of the spec, etc.
Only in theory. Suppose you are a bank, which enclaves/sources/devices do you support vs. not support? What do you do for users on a desktop PC that don't have an enclave? Phishing sites will leverage your weakest enrollment option.
Strictly speaking it's mainly hardware attestation but it's technically "hardware based passkeys" and "remote attestation". So if you rely on attestation in general and don't restrict the attestation source it works just as well.
Software passkeys can be stolen if the client is compromised but they aren't vulnerable to MITM or phishing as long as attestation is used.
> which enclaves/sources/devices do you support vs. not support?
You support all of them and prefer the strongest configuration for the source available.
If you've registered a hardware based key with attestation and then an attack tries to intercept that via phishing or MITM, the key already has its capabilities established and if you try to use the key without attest it should fail.
If you register a key without attestation support then you may be vulnerable to MITM or phishing but you can't intercept a user/their passkey with a stronger set of capabilities and downgrade them.
Stealing passwords is already an incredibly rare attack nowadays. The attack is almost always on the cred reset path. Suppose a user loses their phone with the secure enclave and wants to login to your site using their laptop without a secure enclave.
Are you really going to block that cred reset on the grounds that it's a downgrade? You're going to have a lot of users calling your support asking why they can't login after switching devices.
So you allow it, then oops it was not a laptop, it was a phishing site.
> (re-enroll attacker's key or register attacker's passkey).
What is the mechanism to do this? As I understand it, the passkey is basically a public/private key pair. You'd have to download the attacker's key pair into your passkey system? What passkey system allows you to provide a key pair, rather than always generating one? I'd like to see a step-by-step walkthrough that doesn't involve a straightforward phishing scenario, or running privileged commands on the users computer (if you can do that, all bets are off.)
How? Public keys are public keys. They are designed for full disclosure. They are "leak proof" in the sense that leaks should not ever matter. The useful thing about public key infrastructure is that it asymmetrically moves the security threat to managing the private key, which is in the user's hands, and away from the public key. With a strong password I have to assume that both my Password Manager is up to the task of not leaking it and that the remote website handles my password correctly (including salting and hashing and not leaking and not using a hash algorithm with known collision flaws and not using a hash algorithm with large well known rainbow tables, etc…). With a passkey I mostly only have to worry that my Password Manager is up to the task, those are the threat models I get to worry about, I no longer have to worry about if a remote website is keeping pace in the ongoing arms race because all they have is a public key that I don't care if it leaks.
Here's one way to screw it up: make the public key the password. Normally only the user and the site know the user's public key for a given site, so it's as secure as a password, and nobody notices the problem.
The article describes a straightforward phishing attack that works specifically against accounts that are _not_ protected by passkeys:
> Depending on which multi factor method the account uses, the victim sees a matching fake screen, whether a one time code prompt, an authenticator app number match, or an SMS page.
The only sense in which passkeys have anything to do with this at all is that the attackers used the word "passkey" in their emails. When a phishing campaign with the subject line "Your Mailbox is Full, Log In to Fix Now!" succeeds, that does not demonstrate an interesting vulnerability inherent to your mail server's mailbox size limits.
Right, if you phish the credentials to an account that is not protected by a passkey, one thing you can now do is set up your own passkey on it. That's exactly what passkeys would've protected the victim against!
The other articles you've linked also describe attacks against accounts that allow non-passkey logins, or attacks that require a compromised browser.
There will never be a login that doesn't involve a potentially compromised device/OS/browser/password manager. As long as using a passkey means using those things too, having a passkey isn't enough to keep attackers out of your accounts. They can be pretty good about keeping legitimate users out of their accounts though. You just have to weigh that risk against the risk of you falling for a phishing attack.
In this attack, it sounds like the key step was that the user entered their username and password, thinking they were preparing to enter a passkey. It wasn't the passkey system itself (which would prevent this attack), it was the transition from password → passkey system that was attacked.
In any case, if you can get the user on the phone and convince them to let you walk them through a bespoke auth flow, I doubt there is any auth mechanism that would stop this. This is why every auth system these days is constantly telling you "We'll never ask for X", because at that point, the game is over.
> In any case, if you can get the user on the phone and convince them to let you walk them through a bespoke auth flow, I doubt there is any auth mechanism that would stop this.
Exactly. Passkeys can't solve the problem of phishing. At best it only makes it more difficult. Phishing is less of a concern to me personally than losing my access to my account because of the complexity and fragility of passkeys. I've read enough horror stories, even from very capable people, about people who were screwed because they thought they were doing the right thing by setting up passkeys. Passkeys sound like they might be great for many other people. My vulnerability to phishing doesn't justify the risk of passkeys.
That's like saying that there's nothing wrong with passwords, it's a bug in the human that can't tell the difference between their bank's website and some random web form with their banks logo slapped on it created on wix.com
Attacks on passkeys have been because of flaws in the OS, or the browser, or the password manager, but none of those things are going away any time soon. Passkeys depend on those things, which means they aren't are solution to the problem of phishing. They just make phishing harder.
Passkeys also make things harder for the legitimate user though, and there's a very real question of whether the protection they offer is worth the trouble.
You're arguing theory and not practice. In theory they're better of course. The problem is the implementation. And implementation is a mess because everyone is trying to lock you into their own little ecosystem.
Exactly! Whereas passwords are extremely flexible and can be stored, managed, and written down in numerous ways that are vendor-independent. Want to store your passwords on sticky notes in a safe? Go ahead! Want to use Bitwarden? Yep, you can. KeePass for offline storage? Yes! With good password hygiene (128-bit entropy, never reusing passwords) there is virtually no risk, especially with 2FA added.
You can (and should) do the same with passkeys. Like SSH keys, they're just text.
Save a passkey in Bitwarden, then export your vault as JSON. You'll see a nice plain text JSON block with your passkey that you can print, or backup, or import into whatever replaces Bitwarden.
> There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.
You replied to someone talking about password managers, which objectively do exactly that.
> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
And Passkeys don't offer portability, user choice, or user control.
Cryptography may be a solution, passkeys are one technical implementation that at is core is designed around smartphone-first, vendor-first, brand-loyality-first thinking.
password managers do not do that. open up your password manager, press "copy" on the password, and then paste it into a random website. it will paste it.
(i think 1password just recently enabled an option that will warn you if the website is different than the one it has, but it still lets you paste it)
You can not use a passkey on the wrong site. Period. They’re unphishable.
Short of somehow talking a user through finding the full private key and getting them to send that to you, there is no way to trick a user into giving you what you need to get into a website impersonating them.
That’s absolutely not true with a password manager. They may TRY to prevent you from ACCIDENTALLY entering it on a website, but they don’t stop you.
> Short of somehow talking a user through finding the full private key and getting them to send that to you, there is no way to trick a user into giving you what you need to get into a website impersonating them.
It is Schrodinger's Bob - Both technically literate enough to know how to do that, while also not being technically literate enough to spot the phish or determine why autofill isn't working/the password manager isn't matching.
This is where Passkeys shine, in an edge-case user that is neither of the two most common user types. Basically a unicorn situation.
Copy and paste is not a skill that requires much technical literacy. I've not seen a Password Manager that makes the copy button hidden or hard to find or need much technical skill to use.
Many "legitimate" websites, especially corporate "SSO", accidentally train users that autofill just doesn't work some of the time. Example Corporation's SSO configuration generally has users put their password into auth.example.com, except when the app in question is using some weird SAML flow and accidentally ends up at saml.example.com or auth.okta.com. An old legacy internal app still needs the password inputted in an HTML Basic Auth prompt due to a redirect through oldauth.example.com. The user learns to just copy and paste and have no idea why autofill works on some internal apps and not others because they have no idea what SAML is or why a legacy app is special/different from modern ones.
It happens on the public web, too, to a lesser extent. A website goes through a "rearranging deck chairs phase" and can't decide if id.example.com is cooler than auth.example.com or if they should just put login only on top level example.com and flip back and forth over a few weeks as different internal teams "win" or various A/B tests run.
>It is Schrodinger's Bob - Both technically literate enough to know how to do that, while also not being technically literate enough to spot the phish or determine why autofill isn't working/the password manager isn't matching.
you must not work in regular corporate environments. this happens all the time.
yes, they know how to hit the big "copy" button but don't know how to debug an extension.
take a year or two to work security (or general IT support) in a non-tech-company corporate environment, and get ready to have your socks blown off. people become exceptionally literate with things they interact with all day (excel is great example of this) yet have no idea that google.example.com isn't an official google website.
> Passkeys don't offer portability, user choice, or user control.
This is objectively false. Every major platform provides user choice in Passkey Manager. It's the same flow/settings to setting up a third party Password Manager.
All of the ecosystems have defaults that include some amount of portability: iOS defaults to Passkeys synced through iCloud Password Manager and backed up/restored with device backups. Android defaults to Passkeys synced through Chrome Password Manager. Windows defaults to Passkeys synced through Edge Password Manager. All of the ecosystems have plugin systems to support third party Password/Passkey Managers such as 1Password or Bitwarden.
Most devices that support Passkeys support a QR code bootstrapped flow for cross-device/cross-ecosystem Passkey challenge signing via Bluetooth LE.
Most ecosystems deliberately don't provide explicit private import/export to help protect users, but that's more an implementation detail than a technical requirement, and mostly not an implementation detail for "lock in" reasons but for simple security reasons: the private key you cannot export is the private key that is harder to steal by bad actors. The private key that you cannot manually import is the private key that can't be installed by bad actors.
Passkeys can be, and have been, stolen and hijacked. They make it more difficult for scammers and hackers to get into your accounts, but not impossible. How many phishing emails have you personally fallen for that this is your #1 concern over the fragility and complexity of passkeys?
By that reasoning passwords are 100% secure too, it's the human's fault when they fall for phishing sites! Passkeys depend on humans, password managers, devices, certificate authorities, browsers, and operating systems. That's not even including the implementation itself (https://www.esentire.com/blog/securing-passkeys-thwarting-au...)
All of this means that even when you're using a passkey an attacker could still break into your accounts. Passkeys can make it harder for them, but it can make it harder for you to get access to your accounts too. For me, I don't think the risk of phishing is worth the trouble passkeys would cause me.
Typically the user gives a website their public passkey, which does not need to be kept secret since it’s public. If the website is hacked the attackers only get information that is already public.
You seem to be talking about a scenario where a user’s private keychain on their computer is compromised and the attacker is able to access other systems from that same machine without the user’s knowledge. (Note that the keychain data is itself encrypted so can’t be used from a different computer.)
It's not just the end user that you have to worry about, attacks are helped by the fact that websites suck at passkeys too
"...we developed PASSKEYS-ATTACKER. The tool allows for precise manipulation of WebAuthn messages at every step of the protocol and integrates 15 attack types of which 10 were not covered in previous work. Among them, 2 attack types have critical CVSS scores. We discovered them on 18 out of 103 evaluated websites. These attacks take over user accounts, delete their passkeys, or lock them out of their accounts. Nearly half of the tested sites (53) were vulnerable to at least one attack with a high CVSS score, exposing users to threats such as phishing and session fixation." https://www.usenix.org/conference/usenixsecurity26/presentat...
You lose a device or the local DB that keeps your passkey and you are screwed.
You need to migrate from one login domain to another (rebranding, change of login providers...) and none of your customer credentials will carry over.
Your password might not be stored anywhere except in your head.
Your local storage gets compromised and your passkeys are there for the taking (password in your head isn't).
"Cloud" password managers who hold your passkey private key part is exactly like them having your password and are worse than websites having proper cryptographic hash of your password: they might not be e2e encrypting it (you were comparing with sites doing password hashing wrong too), so a breach exposes all your passkeys just the same.
My point is that there is no panacea. Passkeys are like SSH keys for the web. I still put a passphrase on my SSH keys. Do you?
> There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.
Replying only to this part, using a password manager with autofill solves this problem. The password manager (I use Bitwarden, but there are others) can check the site you're trying to log in to, and only autofill passwords that are for that site. I don't have to do any work to differentiate example.com from thisisexample.com, because Bitwarden will only show me the example.com password.
Nothing of this explains anything, at best it increases the confusion. If anything, all this mumbo jumbo pushes me further away from using passkeys than before.
- Your Passkey Manager generally offers some form of multi-device sync. Most Passkey Managers are the same as Password Managers so it may even be a multi-device sync you are already used to.
- Devices support a flow where a QR Code kicks off a Bluetooth LE handshake between two devices to sign a one time Passkey challenge. That can be used for one time login on devices you don't sync your Password Manager to or to help bootstrap additional Passkeys on the new device.
my passkeys are in 1password, and accessible from any device i have 1password installed on. it's a very smooth experience (both adding new ones and using existing ones).
The secure part of a passkey does not have to be transmitted. It’s public key cryptography. It’s used to sign something as proof that you control the key.
And for that reason, the server does not have the secret. It only has the public key, which is useless on its own. So it can be stored in the database in plain text unencrypted. And you’re not really taking any risk.
Passwords are not cryptography. People may use cryptography to store them at rest, or their hash. But the true password still has to be transmitted. The first time, and every time.
>But the true password still has to be transmitted. The first time, and every time.
The password never has to be transferred. In fact never having the password should be the goal. Not even a first time. Don't let the password leave their device. You transmit the hash.
That just means the hash is effectively the real password. If an attacker gets a hold of the hash that you transmitted, they can use that to authenticate to the server.
All that you gain by transmitting the hash, is that the attacker will need to modify the client's request to inject the stolen hash.
If the client (website or app) runs on the attacker's own devices, this is trivial. I suppose it is a valid obstacle if we are talking about an ATM or similar locked-down client.
That's not accurate. If that were true, then a hacker stealing password hashes would
enable them to instantly log in, without cracking them. Rainbow tables and dictionary attacks exist for a reason.
Pass-the-hash has been tried in NTLMv1 and thankfully that was the end of that failed experiment.
Modern password authentication is performed by the client sending a plaintext password encapsulated within a symmetrically-encrypted tunnel. On the Web that's with TLS. The server then uses bcrypt or another scheme to hash the password (along with the stored salt) and compared that resulting hash with the value in the table.
>then a hacker stealing password hashes would enable them to instantly log in, without cracking them
How do you know the hashed value stored in the database is the same hashed value the user submitted? Server side I can add a salt and hash more before storing or comparing.
> How do you know the hashed value stored in the database is the same hashed value the user submitted?
Please explain how authentication would occur without a comparison between the user's submission and a value stored at creation/update of the passphrase.
Sure, you could MITM still if all you do is that, as with anything it depends on what you are defending against.
If you are defending against clear text being discoverable, then bcrypt hashing with a unique salt on the client is good enough.
If you are trying to prevent MITM you can combine that salting with public/private key transmission of the bcrypt hash to the backend (effectively the same idea as pass keys without the downsides).
MITM just affects your service, and doesn't always matter depending on what the service is, for example, a recipe manager doesn't need to have bullet proof security.
As the hash is being encrypted with the public key in the client, that would require that the client be compromised. In which case the original password is already exposed at that point, thus a discussion of the transport is no longer the concern.
The point of a hash is that the password is not stored on the machine long term. Thus, if an attacker gains access to the back-end and exports all the hashes, you can't reuse the hashes themselves to login. I.e. you need to do a password-cracking attack, which is infeasible with a password of sufficient length.
I don't care if someone gets my password hash. They aren't going to crack it due to the complexity of it.
> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.
While rare, a couple of sites which has many (>1000) users have sent me my password in the plain when I told I forgot them.
Many sites have e-mailed my password in the open when I registered, as well.
I don't defend passkeys here, but too many weak links are present in password based flows today. If someone uses per-site strong passwords, one can contain the leaks, but use the password even once, and the problem grows exponentially.
I immediately emptied my account with BBVA (a major bank with $37B yearly revenue) after their app asked me to validate my identity by entering "the fourth character of your password". Subsequent attempts asked for different ordinals. This was in 2023.
But the sites where I actually care if my account gets compromised - Steam, FastMail, DigitalOcean etc. - are very unlikely to screw up password storage.
I'm never going to bother with paranoid security inconveniences for the crappy website my local pizza place uses.
You are supposed to send the password, via TLS so it's not in the clear, to the server to be hashed.
If you hash on the client... then the hash essentially becomes the password, and defeats the purpose of a hash. I could just steal the hash and use it.
Wow, you sound like you know what you're talking about.
> They have to be transmitted. They (or their hash) have to be stored. And so so many get that wrong.
Ok, you've stopped sounding like you know what you're talking about.
Passwords have to be transmitted or stored. They don't have to be transmitted and stored. As you note, we usually opt for transmission but not storage. You could do it the other way around.
> There is nothing to prevent you from entering your super secure unique password on the wrong site if you get phished.
> Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
They can still be entered. Not working isn't the same thing as not being sent. A cryptographic exchange should hopefully fail before anyone who's pretending to be the counterparty you want learns enough to impersonate you. But you can enter anything anywhere.
> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
Unique strong passwords offer the following:
1(a). They are never transmitted (well, once), and provide phishing resistance; or
1(b). They are never stored, and provide leak resistance.
2. In the event of compromise, no other credentials of yours are simultaneously compromised.
It's true that it would be nice to enjoy phishing resistance and leak resistance.
Here are some other things unique strong passwords offer:
3. You are free to establish any relationship you like, with anyone you like. You don't need permission from Yubico to create an account somewhere.
4. Yubico can't pretend to be you.
You might notice that passkeys don't offer any of those. Your comment appears to enthusiastically endorse the idea that passkeys are a trap.
> Passwords are fundamentally broken. They cannot be fixed.
This is the "PGP is fundamentally broken" argument again. It will never be valid.
If you ask any followup questions, the reason that "PGP is fundamentally broken" is that people use Outlook plugins, and those plugins mean that they're constantly sending email in plaintext when they should have sent it encrypted. There's a very, very simple solution to this.
Don't use Outlook plugins. Run PGP yourself.
Before you send your email, check whether it looks more like "OK, everyone's ready for the kidnapping on Thursday" or "Eb+h+Q1iDEYUgJlO5GTtmcibC+D1E9oJWvZeoy9I2tpqxe9j/iokAx0R". You will be able to tell the difference. Nobody has ever failed at telling these apart.
If you were about to send the email, but it's still in plaintext, don't send it.
Passwords are no more fundamentally broken than PGP is.
As I understand it, in theory, there is no "secret" exchange over the network with passkeys, once they are initially set up (one side sends a challenge to decrypt, and the challenge is one-time use. The decryption all happens locally.) And so they aren't as vulnerable to phishing or other common ways to steal passwords (such as key loggers, which don't even involve the network.)
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.
---------
Oct 14 - 12:30pm...
---------
There is a wall of text below your question and _none coherently, concisely answer your question: "What do passkeys offer users that rand strong password + password managers don't?"
Anything that randomly makes a Windows 8-style popup offer to keep my login credentials safe makes me want to run farrrrr away.
The vibe of the original criticism, even with its technical flaws was this: are passkeys - as a standard, and a user interface - vulnerable to corporate capture? I think passkey defenders are focusing far more on the theoretical technical superiority, and ignoring how instinctively alarming the average implementation is.
We face a lot a lot of attempts to capture our data, and passkey feels like a new frontier.
For me, I know exactly where I am with my password manager & TOTP. I think the current confusing interface of passkeys will make me less secure rather than more, so I've not invested the time to think about how to use them.
Agreed. They put someone else between you and your access, between you and your security.
Lets give the guys at the Home Depot all the keys to our super secure house locks. Any time you want to get in, just roll down to one of 5 convenient locations, authenticate with the HD, and they will issue you a one time entrance pass to the house. Easy.
Definitely not wrong here. It is a confusing mess for most people. Thankfully, for folks all in on the Apple ecosystem, it should be pretty decent of an experience. Everyone else? not so much.
I think this is exactly the "Passkeys are a trap" argument though right? If you lock yourself into a single vendor, everything is easy and beautiful. If you choose a diverse set of vendors, it sucks so much more than passwords and password managers ever did.
That wasn't FIDO as a group. That was one vocal member and even their employer ended up disowning the comment. It also wasn't about sync, it was about plaintext export.
This is not accurate. The very first sentence of that issue is:
> Passkeys should never be allowed to be exported in clear text.
and from another comment by the issue creator:
> I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.
They're arguing for storing them in encrypted form. That's very much a different argument than arguing against exporting. I'm not taking any sides here, I just think it's bad to so badly misrepresent people's standpoints.
Which changed to KeepassXC looking to support the standarization work to allow passkeys to be moved between user-controlled software products.
The complaint wasn't in allowing credentials to move (that is the point of the CXF and CXP work). The complaint was in having sensitive data in a plaintext file live long-term without any protections. That is also why one of Tim's early recommendations was to require encrypting the file via a passphrase.
Asking that services require you to encrypt your backup file by default to protect against local malware or malicious access is certainly not "The people behind passkeys do not like...allowing you to export your passkeys".
Well, KeePass is self-hosted, and I hadn't heard of strongbox before, but it says on the website:
> 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.
Generally, if you want to restrict the user to use a particular authenticator, you need to own that authenticator. At that point you can have the attestation you are looking for. If you want Yubikey policy and behavior, you're gonna have to get your user a Yubikey.
The passkey provider vendors are motivated to serve their customer's needs (the end users, and secondarily enterprise deployments) over non-customer needs.
So Apple platform support (for example) will only send an attestation when one is configured via MDM. Your provisioned work device can indicate to work systems that it is in policy.
The compatibility-limiting risk, if it exists, is more likely from regulators putting their hands on the scale and pushing for security policies that would prevent synchronization and backup, and requiring attestations to make sure those policies are in effect.
Most "Passkey" branded approaches are portable. The "not portable" subset of Passkeys is primarily backwards compatibility with things like Yubikeys. That's also what attestation is mostly for, backwards compatibility with applications and Enterprises that still need "this is specifically the physical Yubikey I mailed this user" type keys, not as much Passkeys.
I'm not saying it's impossible, I'm saying there's a barrier that's useful to further vendor lock in. My mom is going to use Apple passwords on her iPhone. When she needs a new phone, the complexity of import/export and fear of losing access to her accounts is going to push her to buying another iPhone. It's just another avenue of lock in, like existing OS level password managers, just with an extra level of confusion for the end user.
My dad didn't like iCloud Passwords because he still uses a Windows laptop and only recently has the iCloud Passwords app been good or all that useful. We settled on 1Password a few years ago and having 1Password on his phone and setup as his default password app means that iOS uses it as the default Passkey app as well. "It just works."
The vendors could use it to enhance lock in, but for the most part the vendors all seem in agreement that the rising tide safety to float all boats of Passkeys is worth investing in making them friendly, especially to non-technical users, and to some extent try to avoid direct lock-in.
Mostly, though, it is not true lock-in, as in they mostly don't force you to do things their way. They encourage it, make the features pretty seamless to use, etc, so that you want to stay in their system, but they generally permit you to use whatever tools you want.
The fact that the password manager someone might use on another system is a complete piece of crap does not mean passkeys are an Apple lock-in attempt.
There are an open standard. You just have terrible software.
My issue isn't with the standard, but if all implementations lead to the same shitty experience of 3 different apps begging to store and use my passkeys, then something isn't working right. In my case, the terrible software is Apple's Mac OS, Google's Chrome and/or Firefox, and sometimes Bitwarden still acting weird. Lets not even get into how wild Windows acts when a passkey shows up.
Saying it's an open standard, and that it's just all the major players I'm forced to interact with that make it suck isn't very helpful. That's like the people that say "Don't like iOS? Build your own successful mobile OS lol"
I’m sorry you have multiple pieces of software that want to be in charge, but aren’t passwords the same? Because Chrome and Firefox both want me to use them for my passwords. It’s not a problem unique to Passkeys.
It’s just everyone ignoring user preferences to try to score stickiness.
As the previous article says, some passkeys are open, while others require lock-in, and megacorporations deliberately create confusion between the two.
As a Bitwarden (and Vaultwarden) user on Mac/iOS/Safari, Linux/Firefox and Android I have had zero issues with passkeys since I started using them a few years ago.
The first two accounts I switched over to passkeys were my Nintendo and Playstation Accounts as it made sign-in much smoother.
I now use passkeys pretty much everywhere I have the option (at least on high value accounts such as Amazon) and I have not once had an issue. Not having to use a TOTP (or worse an SMS or email based one use code/link!) is much nicer in my personal opinion.
Some sites have a much better designed on-boarding process than others I 100% agree there. I find the sites that do a poor job with their passkey enrolment are the same sites that also did a terrible job of 2FA/MFA setup as well though.
One blessing with passkeys is since I set it up for my mother with her Amazon account she has not once had to ask me to help me reset her password. At least once every 6 months I would have to help her sort things our as she would forget it, reset it and then forget what she reset it to and can't reset it again as she hadn't clicked to update the password in her password manager so it had an old or incorrect password, etc. Always a pain to sort out. Not happened once since switching her to a passkey which is wonderful for me.
Also it is essentially impossible for her to use the passkey on a fake site. Multiple times she has fallen for phishing emails with realistic looking site logins and she would just blindly enter her username and password as many elderly people do.
Both of my systems are apple, one has a Work Apple account and one has a Home apple account. How do I log into website X with 1 identity WITH FIREFOX? (people are going to jump through hoops when they find out my work laptop blocks mozilla services when I can just use a TOTP token on my phone and everything works.)
I think Firefox had system integration with the password/passkey provider framework since 122.
If you do not have access to your personal Apple account on your work laptop, you would need to find some other passkey provider with native integration.
Under Settings > Privacy and Security, look to see that Firefox is listed and has access under "Passkeys access for Web Browsers". Unlike a native app which only needs passkeys for its own services, Firefox needs access for every potential service you might hit over the internet.
Then under General -> Autofill and Passwords, you'll see any apps which are registered as system password managers. Unfortunately this is a subset of the ones which register on iOS and I'm not familiar who has done integration yet in their Mac release - Chrome (with GPM) for instance is not listed even though it is available on iOS.
Same here. My only nitpick is that I have to carefully go through the various machines and browsers, etc, and ensure that only 1Password is ever consulted for password storage.
This describes most non-techy people I know who are 20~ years older than me (unless they're 40+ years older than me and only using a laptop to check their email).
Step away from HN, and there are probably a lot of people who only use their phone to access the Internet. Smartphone brand loyalty seems to be strong, too.
> But you can’t simply switch to Android without recreating every single passkey. Sounds like vendor lock-in to me
Not so fast. Migrating passkeys from iOS to Android is possible now; migrating from Android to iOS is still being worked on.
Ricky Mondello's team at Apple created the Passwords app which brought passkeys to iOS, macOS, etc.
The entire presentation is worth watching if you’re interested in passkeys; the the clip below starts at 24:00 mark where they talk about migrating between platforms.
Starting with iOS 26.5, you can choose to move passkeys and passwords
from Apple Passwords to Google Password Manager. However, Android still
needed "a future update" to receive them. That same update is meant to
add transfers from Android back to iPhone [1].
The FIDO Alliance created a specification in 2024 called Credential Exchange Format [2] for moving credentials including passkeys, between passkey managers on the same device and across platforms.
In other words, being able to move passkeys between devices and platforms has always been part of the plan.
I was under the impression that most credential managers won't allow you to export a passkey to a plain text format, but will only allow limited app-to-app transfer of keys (with a limited selection of compatible apps only)
That still requires recreating every passkey, even if both can exist at once. If I want 50 sites to use a passkey on macOS and Linux, I need to go through the setup process 100 times, and all 50 sites will likely handle it slightly differently.
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.
Still amazed that on HN of all places people are confused by or having problems with passkeys. I have yet to see any of the issues people are guesstimating could become problems and adopted on day one.
I have had two poor experiences, where passkeys I set up at one point stopped working and I had to generate a replacement, but this was not a problem because I have yet to come across a site that didn’t continue to offer other means of logins.
I don’t see anybody complaining about the login-via-emailed-link which seems to be the much more common trend these days and which I really dislike because it introduces an unwanted delay in login (and I have come across many sites for which this is the only means of logging in).
So far, I've had a hard time setting up an iCloud passkey on desktop Windows. Windows Hello keeps intercepting most attempts at a passkey, and 1Password will usually step in otherwise. The UX around it continues to be baffling to me.
At least there's a dedicated migration protocol for passkeys, but I'm not super stoked about how basic Apple's password management is, and how few fields there are for each profile.
But I also feel like it's time to retire my YubiKeys ...
You act as if the experience on Windows is the point of Apple's password manager. I'm not surprised the experience is pretty bad -- as far as I can tell, accessing the passwords and notes is pretty much the only thing you can really do on Windows, and the user experience is significantly impaired compared to Apple devices.
(For example, it only stores the passwords in memory and never persists them locally in any form, because there's no way to secure that, so it has to redownload them from scratch every time you open the app. It also only supports proper Windows Hello PINs rather than normal account passwords, because that's the only way to get proper hardware backed cryptography locked behind authentication, etc. It's a mess)
This, I've been an engineer for 25 years and I hate passkeys. I have a work laptop and a home laptop and I connect to some websites from both and I... it's just a mess.
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 if the website loses its domain? There are plenty of examples of dickish domain registries and registrars, domain holders getting phished, etc. How do you reset it to the new domain?
Allow email resets in the case of a lost domain. You could disable them in normal operation but in this case, any users with passkeys from the old domain can enroll a new one via email.
Sites should support multiple passkeys, and allow you to select between them if more than one are available.
I've seen this work on both Windows and iOS, where I have sites set up to use passkeys from multiple sources (Yubikey, Windows Hello, Apple Passwords, Microsoft Authenticator app), but I've also seen it not work, so there must be something the site has to do to make this possible.
Also consider the case where you use Google password manager and your Google account gets locked for any (or no) reason. It's unclear whether you can even still use your passkeys, much less migrate them away.
At my work we are forced to use passkeys internally and it's fine with me.
At some point in the past, due to the constant nagging I set up a passkey on my GitHub account.
I needed to sign in to work's GitHub account, so unknowingly (since there's no SSO option there) I just clicked on "Sign in with a pass key". It didn't ask for my username, just gave me an option to scan QR code. And I did because work's pass key is set up on my personal phone. Then I noticed that it's trying to sign in with my personal GitHub account. It's good that I don't have anything sensitive on there but I really wouldn't want to sign in on my personal account on my work's laptop.
> 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.
This is the same problem we've had for 20 years with password managers, though.
The solutions are mostly the same as well (with the change to a QR + BLE based mechanism over manual transcription to go cross-device, and a protocol to support moving passwords and passkeys over to different software rather than using a plaintext password CSV export).
Many password managers also manage passkeys (and were managing TOTP before).
A password is not like this because a password is a simple keyboard input by default. It only becomes a password manager if you make the active choice to install a password manager, and then it's your fault if you don't grok your own chosen password manager. Passkeys use something password-manager-esque out of the box, so they have this problem.
TOTPs are already not that great in my opinion. It's like democracy: the least bad option. It's a decent trade-off between convenience and security, so I'll stick to unless there are good reasons not to. Passkeys have managed to make that experience worse, with a very large potential gotcha in the future, while not introducing any improved security I see why I should care about.
You can back up the TOTP secrets to add another layer of protection. I haven't needed to restore from backup yet, but I'm pretty confident that failure mode won't be a problem outside the immediate timeframe my phone happens to die.
> What happens when I go to the same site on a different platform?
You click the "log in with QR code" button, scan the QR code, and authenticate using your phone.
Unfortunately that only works from phone (and watch) to computer. If you don't have the passkey available, you click "forgot password" and set a new one, same as with a password.
You can use it computer to computer, too, as long as the laptop has a camera to read QR codes.
In theory phones and watches could implement the other direction and generate the QR codes, there's just less pressure on the ecosystems to make that easy to do so it's not there in practice today.
You only do it if you want to. You can put your passkey in keepassxc or 1password or bitwarden or google's password vault or any other cross-platform passkey platform.
It's only a problem if you pick a platform that locks you out, even then there's workarounds. It's not a replacement for logging in every day, it's more a replacement for typing over the 64 character random password from your phone's password manager on the library computer.
It's easy to install Chrome on most devices and even iCloud Passwords has an okayish and getting better Windows app today that works in supported browsers. (It would be nice if it also acted as a Windows-wide plugin for Passkeys, but it doesn't yet today.)
Passkeys in their current state essentially are just SSH keys with added website verification.
A lot of the "slippery slope" confusion in the past couple of articles has been that this "cheap SSH key" approach was built on top of the same standard for "expensive hardware key" (Webauthn). This is great because it means a rich backwards compatibility story across a long history of devices and "expensive hardware key" remains an option for Passkeys. This is unfortunately confusing because Enterprises still need Webauthn for "only expensive hardware key" usage so need options in the standard like "Attestation" which specifies things like "exactly which expensive hardware key vendor was used".
People see this confusion and think it leads to a slippery slope of attestation being required "in the future", but the reality is more that attestation and things like it were required in the past and are optional now because we realize "cheap SSH keys" are good enough for most users (with some standardization and shared "branding").
In best practices for SSH keys you should be using different keys on every device and shouldn't be extracting/copying them. Best practices are also to use different keys for every SSH host in addition to per-device keys.
Passkeys enforcing keys not be extracted/copyed as plaintext and that keys are per-host/domain are just following ancient SSH best practices.
Because yes the SSH world is sloppy with dangerous plaintext (or modest password encrypted) key copying and reuse. That does make it a "simpler" ecosystem, but that doesn't make it a better ecosystem.
That said, Passkeys generally are frequently copied, most of the ecosystems support multi-device sync and backup. They just aren't done in a way that provide plaintext export if you want to print a book of your Passkeys and store it in a safe deposit box or sloppily `scp` them from one machine to another.
I think the core problem is they’re called passkeys and evangelized as a replacement for passwords, which makes people think they’re like passwords or like keys—secrets we’re responsible for not losing—whereas actually they’re like session cookies. They’re a fast path in that you’re meant to be able to create, delete, and even clear all of at will, with no penalty but that you’ll have a fussier login next time. They sure do suck as an only way in, they’re not even meant to be able to do that.
Passkeys only make sense if multiple passkeys are supported. What if I lose my Fido key? One issue here is that passkeys don’t have a clear role. If they are replacing passwords, only, then they are 100% an improvement even when not hardware backed, but you still need 2fa. If they are hardware backed, you probably don’t need a second factor and different sites see different roles. Assuming I can setup a backup key, hardware backed covers all of sites’ misconceptions, though.
A few examples here to illustrate...
The way ebay and Amazon handle this are great. Multiple passkeys allow login of multiple device ecosystems and/or hardware tokens so that users can mange their own level of risk and really any level of implementation is helps the average person.
Meta's implementation by contrast is bad, in my opinion. You are only allowed one passkey (so one login ecosystem/hardware key allowed) and it completely bypasses 2fa and security tokens. So, someone looking for more security must avoid passkeys "altogeher" and use password + U2f security key and the passkey only being allowed in a single ecosystem means that password/phishing lanes must remain open. All you're doing is disabling 2fa on a key that is likely sync'd to all of your devices. All that said...it may still be a security improvement for most users in the real world in practice, I just find it a very annoying and confusing set of security decisions.
2FA exists because defense in depth. Even if passwords weren't phishable, it can still be handy to defense in depth that a person is who they say they are by checking multiple factors ("something you know", "something you are", "something you have").
Passkeys largely meet 2FA requirements by themselves because they are "something you have" (its stored on a device you own) and require "something you know" (device PIN) or "something you are" (biometric unlock) to use.
It moves the attack surface to password managers, which is arguably a better situation than phishing. I'm skeptical that the war is over, though. I have no proof to back this up as phishing is the low-hanging fruit today, so the numbers 'largely' back you up. I personally include device compromise in my threat model and I'll concede that may be overdoing it for the average person.
Yeah, there needs to be a way to link password managers to share passkeys, and also to share passkeys between people. There are also a lot of great features that could be implemented with passkey sharing too, like revocation, time limits, or capability limits.
Adding the kind of sharing it sounds like you are describing would just shift the attacks to that new attack surface. The attackers would basically try to trigger and intercept those shares.
If machines, browsers, phones etc are set up properly (yes, I know, big ask, especially with the confusion surrounding this, so I acknowledge the caveat), then the vast majority of passkey requests will go right into the preferred method (i.e. 1Password, Bitwarden, even Apple, browser of choice, etc). And most of those now will allow that passkey then to be used on a different device if signed in and synced.
I have found it to work pretty well with a password manager. I would suspect OS level passkeys would be much less "portable", especially across different manufacturer devices, like Mac/Windows, or even Windows/Android, etc. Which is why I waited to start using passkeys until I could use a password manager to store them, and I turned off all other passkey storages (same as I did for password storage before).
Obviously any new feature in a password manager is a new attack surface. That doesn't mean we should never add new features to password managers.
If we don't add decent sharing to passkeys then people will continue to use passwords, which is worse for security than adding a properly designed sharing feature for passkeys.
I don't think I have seen a case where using a passkey stops me from using my password on another device/platform that doesn't have access to the passkey.
Maybe, but ultimately a website/service wants active users, and making it too hard to log in from different platforms or reset your auth and get back in is not going to get them more users or better user retention.
It's not even clear what happens with Google Password Manager. It might go into your Google account or your local device. I somehow ended up with a mix of both.
TOTP is phishable. The push to get away from TOTP is driven by phishing.
I've done authentication projects for financial institutions that were actively targeted by phishing attacks, and it is difficult to mitigate TOTP phishing. Defeating TOTP is very much in the standard playbook for high-dollar scam operations.
The objection here isn't to something that uses public keys instead of TOTP. It's that they added support for remote attestation to passkeys, which an enormous red flag and enables That Which Is To Be Prevented, i.e. permanently entrenching the incumbents because many third parties won't support new device makers with no user adoption yet and users won't adopt a device that won't work with many third party services.
Moreover, the large majority of ordinary people are going to use whatever comes with their phone anyway, which can then lock the key in the device's secure processor by default independent of remote attestation. So then it's not getting you anything for those people and the primary thing it does is to impede Linux Girl from using Linux and anyone new from ever trying to create a competing mobile platform or even a usable non-Google fork of Android.
The obvious way to satisfy people is to remove support for remote attestation from the spec.
> The obvious way to satisfy people is to remove support for remote attestation from the spec.
If you presume bad faith on the part of basically the entire WebAuthn implementer community, how does this help?
The consumer passkey authenticator implementations of today do not provide attestations, passkey relying parties do not consume them, and both would need to intentionally ship changes to enact the scenario you're worried about. If you're worried about both of these colluding to lock you out of your accounts, it seems naive to think that changes to an (intentionally malleable, extensible) spec will protect you.
All the rest of this argument just misses me. Whatever the non-phishable authentication you want to use is, that's fine by me. But TOTP is phishable, eminently so, so you're not going to see security people back down from deprecating it.
I think the arguments about attestation are bogus for all the reasons everyone else is pointing out but that doesn't matter because I'm not talking about Passkeys, I'm talking about why TOTP is a dead letter. You're not going to get security people to back down on deprecating TOTP, because it's phishable, and the point of modern authentication protocols is defeat that attack.
By all means, keep lobbying against Passkeys! I don't care. But you'd be shooting yourself in the foot rhetorically to build TOTP into your case, as the comment I replied to originally just did.
Every time I've used a passkey with a site was in addition to the regular user password. So like a cached auth saved in the phone secure storage, protected by my PIN/fingerpring.
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.
Security matters, users who want choice have to take responsibility, users that don't can just use Apple.
"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"
That it’s possible to know the answers to these questions doesn’t mean the system is good. This is a level of complexity that most people simply do not have the time or bandwidth for.
>>users who want choice have to take responsibility, users that don't can just use Apple
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 to the people who will actually use it.
"...if attestation is the thing you're worried about, the post's own recommendation pushes you towards attestation rather than away from it!"
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.
> 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.
Remote 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.
Attestation is to your advantage if your phone gets rooted/hacked (evil maid attack). It will let you know that something is wrong when you try to login into an attested site.
That should be up to my phone then. Unlockable phones display a mandatory warning screen on power on if they've been unlocked - isn't that sufficient? Why should Facebook also be allowed to care?
We know users blow past any warnings, even if it is in big, bold, red letters stating that they were hacked and should not continue.
Plus why should I be inconvenienced by not being able to watch my TikToks if my phone was hacked? On the other hand, I expect my important apps to apply a higher level of validation before they accept random inputs.
> In a 2009 blog post, security analyst Joanna Rutkowska coined the term "Evil Maid Attack" due to hotel rooms being a common place where devices are left unattended.[1][2] Rutkowska then published a practical method for bypassing TrueCrypt disk encryption on victim devices, requiring merely an external USB flash drive.[3]
I hope the situation with disk encryption has improved. Otherwise, what is even the point of it? Any local malware you get is going to get an unencrypted view of the disk anyway (just like your legitimate programs) and there is already something seriously wrong if someone manages a remote login on a random home desktop that wasn't specifically configured for it.
Then you just entered your unlock code / password into the compromised device which immediately transmits it to the attacker who has your real device.
On top of that, secure boot doesn't require remote attestation. If your device doesn't like the new configuration then it doesn't release the key. The site has nothing to do with that except insofar as you need the key to sign into it. Your device manufacturer's key doesn't have to sign anything, all your device has to do is not give up your key unless the device is in the configuration you specified. And if it will do that then it would also sign an attestation to the same effect, so remote attestation still provides you with no advantage whatsoever.
Maybe I'm misreading, but that was my point - an app roots your phone but doesn't reboot yet, resets SecureBoot to the new configuration so it's accepted on reboot, triggers a PIN screen to re-seal user secrets, but it will now fail attestation since it's hashes will be non-recognized.
the reality is that evil maid attacks, and more broadly (and realistically) physical access attacks are exceedingly rare. The vast majority of stolen credentials are phished or some other social-engineering trick, not James Bond sneaking in with his badusb.
It was inconceivable to crypto bro’s that kidnapping people for their keys was a possibility…
If banks make it a requirement you use certain pre approved devices, you better believe badusb/physical theft will take place more commonly and it will definitely not be someone as polite as James.
Yeah this article is confusing for me. The one a few days ago was basically saying "this is a slippery slope", which the post today acknowledges, then goes on to say "These passkeys don't give websites an attestation statement at all, and though a site can ask, what comes back is none" as though it invalidates the post a few days ago.
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.
I also get generic errors trying to check out, not exaggerating, like 25% of the time on anything that isn't amazon. I think Firefox and resisting fingerprinting and VPN together means places really don't want my money. I know fraud prevention etc etc, but I can still be annoyed at the state of the internet.
This blog post is the perfect example of someone rationalizing away the bigger picture.
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.
When my state introduced seatbelt laws they assured the public that they would only be a secondary offense, never the primary basis for getting pulled over and issued a ticket.
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.
I think it's more that attestation can require a specific "approved" authenticator, and that authenticator is what would enforce all of the required OS/Software/Hardware requirements, even if it didn't get included in the attestation standard.
Most consumer websites won't demand you share a scan of your face to third parties, until they do. Same exact thing will happen with passkeys, guaranteed.
Exactly how http was the standard for normal websites and banks et. al. using https until, everyone was.
Now that was a good thing with https, not so much with passkeys until Chrome pushes through a change and says they'll only accept attested passkeys issued by their own google password manager/authenticator.
Access is a good thing too. I don’t want hardware attestation, i want to be able to access my bank from anywhere. Banks continually push their liability for security onto customers.
People who are more tech libertarian don't like when critical aspects of their life requires a smart phone from either Apple or Google. The ability to avoid these companies is becoming increasingly difficult, and attestation is one piece of that puzzle.
I don't think that means throwing out passkeys entirely, but that's why you're seeing a lot of "slippery slope" stuff in here
The line of thinking, I guess, is that you shouldn't be forced to buy a specific companies device just to access your own money. And in 10 years time, the companies approved to make devices like this will be DisneyAppleFlix and TeslOpenAI.
That's my guess, at least. I know next to nothing about attestation and passkeys.
How? It wouldn't be easy at all it would be totally unconventional and break all sorts of expected workflows for passwords if you had to take a photo every time. For example at my work we have a ton of computers and none of them have webcams.
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.
and your bank can't force a certain client for a password if they decide to? or that you need to drink a confirmation can? or whatever arbitrary technical constraints they want to do in general?
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.
They effectively can't to the extent that it's not a social norm to enforce that level of security theater. You are arguing in favor of normalizing an increased degree of security theater.
My point here is that this specific step on the slippery slope is a cliff, not some infintessimal change, because now the authentication is done through a program and not copyable information. If verification-can technology is standardized on an OS level and advocated by four out of five tech priests (and maybe even enshrined in law (think of the children)), then you are going to be drinking a whole lot more mountain dew in the future to say the least.
If it was just a single bank or something that tried this, people would get pissed off, leave, and the frog would not be boiled. It takes a slow industry-wide movement to shift the standards of what is acceptible to the common man.
Do not handover your identity, or verification of it (as the current case is) to anyone else, irrespective of the benefits, including the security aspect.
---
The author has strong incentives for the success of passkeys.
1. Scott Helme is founder and CEO of Report URI, and Companies House records his ownership at over 25% and up to 50%. Report URI markets a "Passkeys Protection" offering, giving him a commercial interest in services for passkey adopters.
2. His WhyNoPasskeys.com campaign pushes websites to adopt passkeys, is sponsored by Report URI, and promotes its passkey protection services. The "Passkeys Are Not a Trap" article also carries a Report URI sponsor banner.
3. Troy Hunt, Helme’s Report URI business partner and investor, joined 1Password’s advisory board in 2020; Helme has also appeared in Hunt’s 1Password-sponsored content. That establishes an indirect vendor connection.
Virtually every authority on passkeys is going to have an industry connection. Just like how most climate change authorities receive funding to do climate research, how SEC investigators typically have backgrounds in banking, open source military analysts are veterans, etc.
It's not because people are bought by the powers that be, it's the way the world works. People enter the fields they have expertise in.
The guy literally owns a business in this space and has a huge financial incentive to push passkey adoption. Technically he has an "industry connection" just like millions of other people who work in tech and happen to know about passkeys through other work, but conflating the two is wildly misleading. His perspective is as far away from unbiased as possible.
Research funding is hardly perfect, but most of the people studying climate change are doing actual research and trying to draw evidence based conclusions that hold up under peer review. Their incentives are not the same as a tech founder who could potentially make generational wealth if one particular outcome is realized.
> 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.
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.
Apple does not support Passkey attestation on consumer devices. They've said between user privacy concerns and user experience concerns (syncing and backup are critical requirements to non-technical users) they will not support attestation on consumer passkeys. They worked through the standards process to push compromise standards that are not attested but help with some of the "compliance issues" that might have come to require consumer passkey attestation (these are the uvi and uvm extensions which are not attested and essentially are "I solemnly swear a biometric unlock was used to access this key" for basic 2FA/MFA CYA).
So the "biggest providers" very much have some champions against attestation.
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.
The idea of keeping my passwords in my work-sponsored password manager just sounds absurd. Who thinks that's a good idea? What happens when you leave the job?
My workplace doesn't offer this, but I like the idea of how 1Password does it. If your workplace has a business account with 1Password, each of the business users gets a personal account for free. If you change jobs you can pay for your own account, but it isn't tied to the company account other than getting it for free with the corporate account.
What I did was use usernames on those services that included a few chars to remind me which business I'd created it for. I was a software engineer bug changed jobs/contracts on average about once per year (that's a very, very rough average though).
it's work-owned or work-managed accounts that get stored in a work-sponsored password manager.
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.
eh the companies account for that. for example 1password basically gives you a "free" extra personal account if you enroll into a work account. and when you leave, you just keep the personal account.
"free" because im not sure if your employer pays for it or if its like a free benefit to a bussiness licence
What you describe is a different attack surface than the much more problematic on that password managers solve well: password re-use across websites where the blast radius is super high.
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.
I think this part is where TOTP's 2FA/MFA model is "safer": you do not need to trust the TOTP manager. Even if the app sends all your TOTP secret keys to the server, they cannot hack your account because your password is stored elsewhere, and TOTP code alone is useless.
Not GP, but I've seen this happen a few times with $work managed password managers. From memory and in no particular order, the reasons for the breach were:
- 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.
(1) The use case I have seen is that a startup or small unit in a big organization has subscriptions to a number of services that are shared by multiple users; if I had to log into one of these things I would log into the password manager and use the username and password that we all share -- these have never been things that I use for my day and day out software development but usually are things the marketing people use that I only have to log into every six months or so if I have to help out with a problem. I've always had individual accounts for bread and butter services such as version control, issue tracking, documentation management and such.
Of course the right thing to do is give members of an organization their own username and password or integrate with the enterprise SSO of that organization... And that's a lot of what I do for work! Many vendors don't support that or jack up prices 10x or more per seat for SSO, so shared username/passwords are widespread.
(2) "they got hacked" means "I read about an incident in the media". Probably some security boundaries were breached and others weren't. I don't think any of these were the worst case scenario of "100% of passwords got leaked". I wasn't personally effected because I didn't take the bait, I either had moved on to another job or somebody else cleaned up any mess so I don't know exactly how my organizations were affected. Still it proved my intuition (gotten from looking at a lot of software and working on user management for numerous web sites, some famous) that these password managers were not paragons of operational excellence.
The author is really missing the forest for the trees here
> 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.
A closed-firmware USB key is really no better option.
Dear Yubico / Kensington / Google Titan, can I export my private key components to this other device, or even print them out on paper for storage?
No - you're just an untrustworthy user granted the fleeting privilege of using BigCorp devices. Now stop asking such questions or you might have your attestation revoked.
> [Attestation] say nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
Largely false. The Pixel verifies the OS and will reveal `verifiedBootState != Verified` on GrapheneOS in the attested passkey at registration, which websites may choose to reject. Apple Silicon has an undocumented SEP which prevents Asahi Linux from accessing it. There may be other examples now or in the future.
Also, I think you can deduce the device color from [1] on Android.
"The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. 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)."
"This implementation is not spec compliant and has the potential to be blocked by relying parties."
Proponents keep trying to hand wave away the attestation lock-in problem as some vague faraway threat that we may never encounter. It isn't. It's the actual plan.
These are very damning. Pretty straightforward about removing all software freedoms in favour of some sense of security. It really is already happening:
> I have a sneaky suspicion that some of our failures with various RP's is because they are only accepting certain authenticator GUIDs.
This comment from the KeepassXC maintainer makes me feel like the whole spec is already completely flawed if such a situation is even possible.
> 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.
Practical experience from Austria where attestation is used to limit which hardware tokens can be used for the EU digital identity: it sucks. You're limited to a very limited number of keys: https://www.id-austria.gv.at/de/hilfe/hilfe-zu-ida/authentif...
Now: will more people do this? I don't know. But I fault the standard for enabling it in the first place.
Exactly. From the page about the requirements for the app under 1) in your link:
> System requirements
> Android 12 or iOS 16
So one of four methods is, by default, already completely dependent on having an account with $american_megacorp.
4) is another app where it doesn’t outright say, but I’m guessing the requirements are also a mainstream OS, mobile at that as well since they seem to use biometrics.
That leaves 2) dedicated hardware and 3) dedicated hardware. Great. (see the “my house burned down” article/thought experiment as to why I’m against that.)
I think the passkey standard included attestation for good reasons, but it is obviously also possibly a trap in the sense that I'm sure there were some people on the standards committee(s) envisioning a glorious world where they can flip this on for everyone and instantly all the bad stuff stops.
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. There is no way around the fact that strict attestation implies more user responsibility to make sure they don't lose their token, and at scale, they absolutely will. Work environments can get away with this because work environments have a scalable mechanism to re-verify identity to the extent the business cares about it personally, and reissue tokens. At scale the big companies do not have this for individuals. You can't use hardware attestation without this infrastructure for reverification, and any infrastructure for reverification a large corporation tries to create will have exploitable holes in it.
> there were some people on the standards committee(s) envisioning a glorious world where they can flip this on for everyone and instantly all the bad stuff stops.
I still don't use passkeys because I don't know what advantage it has over my existing method of generating random passwords in my passport manager and using that. My password manager generally autofills it anyway.
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.
The number one gain I see with passkeys is that they are phishing resistant. The biggest issue I've had with TOTP keys is they aren't phishing resistant.
Forcing people to use passkeys gives the authentication layer a stronger means to ensure that people are logging into the correct domain. A password manager accomplishes this, but it's very difficult to enforce. (I've heard a number of variants of "John Smith sent me an important document and when I went to open it, the password manager didn't work so I just copied password")
I’ve seen tech-savvy people getting phished into entering their password on a fraudulent site, despite the password manager blaring alarms that the login looked fishy.
This cannot happen with passkeys at all because crypto magic.
I assume a phishing site wouldn't even attempt to use the passkey because it can't. So wouldn't it just ask for a password, and at that point, if you're gonna fall for it, you'd go and grab the actual text password anyway?
My password manager matches off of domains too, so it wouldn't suggest to autofill on a phishing site.
Right. It didn’t suggest it but the phishing message was convincing enough that the tech-savvy person fished the password out manually and input it anyway. A mistake for sure, and one the password manager was trying to help with, for sure, but this mistake would have been impossible with a passkey.
Right. The “correct” way for a service to handle this is to disable password logins for any account that has enrolled a passkey. A few services do this, but boy howdy is it ever unfriendly to users (or at best, difficult for them to get their heads around).
No, the commenter is letting people use Passkeys. They didn't say anything about not letting other people use it, they just expressed why they don't find them useful.
As far as I've read here before, device attestation is definitely there, it's just not being used (one of the big tech namely Apple is balking... maybe they have their own means or plans in their ecosystem).
My main reason for not using it is I'm not interested participating in a scheme where I do not own/access the private keys and being able to use them and store them the way I want to.
I'm fine with TOTP and sure, I understand it's not phishing resistant by itself.
I don't use passkeys but the thing that raised a red flag for me while reading the article that the OP is responding to is the "non-copyable" property. It's not possible to prohibit delegation[0], so the idea that a key can only be used on one specific device necessarily involves a form of DRM/wishful thinking.
The entire point of passkeys is to force DRM onto all corners of the web. It lets sites require attestation of the software running on the client device. Once they use that to eliminate hardware and operating system competition, they’ll ramp up surveillance and censorship even higher than current windows levels.
Passkeys are the second prong of the age verification push.
If you want more evidence, read up on Project 2025’s plans for forcing the internet to adhere to American Christian Nationalist values, then try to figure out how that could work in the absence of passkeys.
Look, at best, Passkeys shift your logins from your head to OS-supplied keychain management. Whether they do attestation today or not, they big, industry-wide effort to move away from "what you know" (i.e. username/password) + "what you have" (2FA) towards "platform-authenticates-you-to-website automatically" has both security benefits and lock-in risks.
Maybe it was too strong to say the were a "trap", but it is also too strong to say there is no worries here.
No, you can't just use whatever passkey manager that you want.
I use Safari, Chrome, MacOS, a Google Pixel phone, and 1Password. I have passkeys in 1Password, but it's a crap shoot if I'm able to login on a device.
Chrome wants me to use Google Password Manager. There's no option in chrome://settings to set 1Password as my passkey manager. If I try to use a passkey to login to GitHub Chrome pops up a modal that lets me choose between iCloud Keychain, Use a phone or tablet, or USB security key. There's no option to use a different credential manager.
Safari wants to use my iCloud Keychain. There's no option in MacOS Settings to set 1Password as my passkey manager. If I try to login to GitHub I get an option to Scan QR Code or Use Security key. There's no option to use a different credential manager.
My Pixel wants to use Google Password Manager. There *is* an option in Pixel Settings to set 1Password as my passkey manager, but it doesn't work in Chrome. All I can do it select "use another device" and it shows a QR code. There's no option to use a different credential manager.
Essentially every OS and browser thinks I want to use a phone for my passkey, and this is exactly the situation that I and everyone else is bothered by. I do not want to tie my login credentials to a phone that can be lost/stolen/bricked and will be replaced in several years.
So no, you can not use your own credential manager.
Much like you could use any AOSP fork to run banking applications... until you couldn't. But hey, at least there's an explainer website[0] that completely glosses over this detail.
[0]: One great bit of environmental storytelling is the "Made with <3 by the passkey community" in the footer. "Passkey community" of course means timcappalli with minor contributions from two others. You might remember him from https://github.com/keepassxreboot/keepassxc/issues/10407#iss....
It's notable that several of the claims on that page conflict with the other info in both the OP article and the follow-on.
As for choice as the user, it's a choice "for now"... and only for users who understand all of these details (which seems unlikely).
Personally, my observation is that if one tries to properly configure 2FA with any major website lately (no, I don't mean AWS console), the level of "your choice" and properly implemented security has actually gotten worse...
TFA's author has also explicitly precluded the "platform-authenticates-you-to-website automatically" workflow, in a separate blog post [0]:
> This one can be tricky because I've seen many sites using passkeys to replace passwords, but that's not something we've done on Report URI, passkeys are used as a 2FA mechanism.
Well, they can (and likely will be) used in both modes. Either these things are just a different way of generating a password for a password manager (itself a big target of attacks), or they are a way "to move beyond password with TPM-level security". If it's the former, the security benefits are limited. If it's the latter, the "it's a trap" logic applies at least in part.
> Well, they can (and likely will be) used in both modes.
I agree - and that makes me wish that the messaging was more clear from passkey supporters. Some may be genuinely confused and talking about one or the other mode (or not even realize that multiple modes exist), and some may be trying to claim the benefits of one mode while/or handwaving away the tradeoffs of the other mode.
I actually spoke up about this at a local chamber meeting today during my 30 second elevator pitch. I decided to give a brief cybersecurity awareness month pitch about having backups for your 2FA and to be wary of passkeys because you will be locked out on device changes.
I think they are a trap. A usability nightmare. So, I acquiesce to a passkey to a site while on my iPhone and now I cannot log onto it from my work desktop in Firefox. An older person sets it up on his or her Google account, gets a new phone (iPhone to Android) or Android to iPhone doesn't matter and loses access. We know that Google won't help a regular consumer with anything.
Syncing may be a thing in theory but the friction is huge.
- trying to sign in to Okta on my personal Linux desktop computer. It has bluetooth and I had my phone right next to me, also with bluetooth turned on. But Firefox simply refuses to even show the option for "connect to your phone" or to give a QR code... it just said "tap your security key or biometric device". I had neither; my passkey is on my phone. Then it timed out and I gave up trying to log in.
- trying to sign in on my work Macbook using Google Chrome (enterprise managed one). For some reason, upon scanning the QR code, my phone was stuck on "Connecting..." and timed out. I had bluetooth turned on on both devices, they were five centimeters apart, both were connected to internet with a great gigabit connection. It turns out, I had to quit and restart Chrome and it magically started working.
- trying to sign in on my work desktop using a physical Yubikey remotely using VNC. It's not possible by design. I had to get my coworker to press my Yubikey in the office.
- trying to get Muse and OpenAI Dot to sign in using a passkey. It's not possible by design.
Generally, the user experience is really horrible with passkeys. It is also ironic that it trusts my phone (used for shitposting; easily lost or stolen) instantly, but simply refuses to trust my personal Linux desktop computer, which is fully encrypted, securely stored in my house, and contains all my life's work and everything that is dear to me.
Counterexample: the swisspass. It's a private service from the swisspost, and they whitelist webauthn providers. For example, you can't use bitwarden https://community.bitwarden.com/t/follow-up-on-bitwarden-pas...
So the danger is there today, not in the future, since I'm already cut out today from the service, unless I use some hack
What I'd like to understand is why the majority of sites that allegedly supoprt passkeys do not let me store them on Yubikey hardware but instead are pushing into "cloud" passkeys. That's what is triggering my spidey sense about the whole scheme. If they are so great all around and vendor neutral why is everyone pushing me to store my keys in some "cloud" password manager? If I'm going to the trouble of setting up passkeys I want to be in control of them across all my accounts. That means my own hardware dongle. Not some cloud vendor's pinky swear that they'll take care of them and let me use them on my terms.
My OS (Arch), my browser (Firefox) and my hardware (Yubikey) all work fine with some sites. For example my Google account credentials are on my Yubikey passkey. But half of the sites that claim to support passkeys won't offer me the option to save the passkey on my hardware. Paypal is one such example. Facebook is another. I don't understand why. They seemingly only want to cooperate with cloud based passkey storage. I don't know what mechanics govern this.
Paypal refuses to offer generating a passkey on either Firefox or Chrome on Linux. Spoofing the UA to Firefox on Windows does work, though. Whatever they're doing, it's not normal. I'm surprise you run into it so often.
This is the first time I've seen this issue, very weird. Then again, I had to apply some kind of hack to enable TOTP back in the day (something about faking an RSA key fob), so I'm not surprised Paypal is stil shit.
Let us consider the average user. The one who manages to lose their iPhone and has no idea what their iCloud account login is because they were aware of having to log into it once when they created the account at phone purchase 3 years previously.
That person is fucked when they lose their phone anyway, because they're also the sort of person who has never backed up all their photos/contacts/iCloud files anywhere that doesn't require iCloud auth to get at. At some point we have to either properly educate people on the fact that they need to have a recovery path, or we have to accept that they're going to need to rebuild their entire digital life every 2-3 years.
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.
Impossible. Because iPhones randomly force you to enter your iCloud password, often at the worst possible time. Such a user would have already been prevented from signing in to their own iMessage on a random Tuesday afternoon.
One of the most frustrating issues with Apple's UX.
I've never experienced that. The only time I've entered my password was when I set up the iPhone and when the phone got into a weird state after a software update.
It seems to vary with how often you purchase things from the App Store and iTunes Store and how "high value" your account seems to some sort of iOS metrics. Which is why it also often seems like "phone is in a weird state after a software update" as that is probably also when some of these metrics reset/get rechecked.
It depends. It sounds like you're all in on the ecosystem. I only have the apple account because I have an iphone. I didn't get one of those double check reauthentications since many years ago, up until last month when I got apple tv. I know because I had to reset my password and it was older than my use of a password manager.
I'm a happy user of 1Password myself, but warning that they only allow export of passkeys through a specific protocol, and it has to be done on the mobile app. [0]
> 1Password for iOS exports ... directly to other supported apps, including your passkeys.
They pick the list of other supported apps. There is no ability to export to a standard encrypted file, nor is there a way to develop an open source app that can receive an export over the objections of 1Password Inc.
Exactly. So much for TFA's "or whatever other software of your choosing" claim.
Passkeys are a trap, trying to lock users in to the service providers.
I did say I like and use 1Password, but I do remember that they switched from a one-time payment model to a subscription model, and have now stopped supporting the old software and only support their subscription software. If it wasn't for my non-tech-savvy, aging family I support their usage of 1Password for, I would still be on Keepass[XC] for my own private usage.
Let’s assume passkeys are the greatest thing since sliced bread.
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 hope passkeys are the same as the USB-C rollout. The internet whines and complains for a few years about their theoretical device from 1999 that won't work anymore and then everything is just plain better for years to come.
So many words spent on HN articles complaining about USB-C or praising Lightning... fast forward a few years to now and I legitimately just pack one cable in my bag and charge any device I happen to bring with me.
I'm not an expert, but it's frustrating to read these threads about passkeys.
The common objection I see here is "But if I lose my device I'm locked out!"
A lost passkey should be treated the same as a lost password.
Sites that implement passkeys need to have an account recovery mechanism. Granted, not every site does this correctly. Don't use passkeys on sites that don't have a recovery mechanism!
Secondly, the site you're authenticating to must allow you to have multiple passkeys. You either have a cloud-synced password manager so that all of your devices get the same passkey, or you have a passkey per device that you use to access the site. Again, not every site allows multiple passkeys. Don't use passkeys on sites that don't allow you to have multiple passkeys.
For a site implements both of these properties correctly, if you lose your device, you just connect to the site with your new device, perform whatever account recovery procedure (TOTP, email verification, phone verification, ...), create a new passkey, and, ideally, disable the passkey from your lost device.
> 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.
Then guess what - people stop using those websites.
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.
Only a few people stop using those websites, because most people will use the Apple or Google authenticators and be done with it. And if those websites are essential services, those few people who don't conform will be left out in significant ways.
> Then guess what - people stop using those websites.
Wishful thinking. Sadly, the vast majority of people will be perfectly OK with a website telling them they have to use a recent iPhone or Play-enabled Android phone to do something. This is already the case for banking apps and a huge number of other phone-app-only services.
Passkeys can be tied to a root of trust, like those owned by google, microsoft, apple.
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.
I have seen an exception to this with Microsoft Entra. I was not able to store and use the passkey in my password manager of choice, I had to save it in Microsoft Authenticator. I haven't tried again lately since that was for a previous job, and I didn't look into the underlying reason it failed, whether it was attestation of some sort or something else about how they set it up.
I'm generally pro-passkeys, but also acknowledge they are a hot mess for the average non-techy consumer. And there does seem to be room for the screws to tighten, and we definitely need to resist that.
Microsoft also didn't let me use a normal TOTP authenticator and it wouldn't let me sign in with just my password. Every step along the way of a corporate MS account is bullshit, passkeys are just a victim of enterprise policies.
I have to say the messaging around passkeys is bad. So many providers show modals with big friendly lock logos superimposed on a smartphone to announce the change without offering any explanation about why the change is happening, why the change is happening now, or how the technology works.
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.
> 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.
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.
As if the police in a corrupt state are going to check the public fingerprint of your passkeys. Your account identifier is proof enough.
The make and model of your authenticator is shared with about 2 million other Yubikeys, if anything they'll compare your public key, not the attestation process.
Last time I tried using Firefox on Linux with Keepass's passkey implementation it worked on the test page and a couple other sites but Facebook refused to add it, so I definitely believe that e.g. banks and various other important sites won't balk at restricting passkeys to Android, iOS/MacOS, and Windows. I am curious what other people's practical experience is with these kinds of sites.
I've set up a few passkeys to see what it's like and the experience is wildly different between sites.
State Farm is the only place I've actually liked it. I don't have to type ANYTHING in.
Open browser, open password manager, click the "sign in with existing passkey", browser and password manager talk, prompt me to confirm the passkey choice, and I'm in.
Most sites I've messed with insist on you entering a username first.
> Most sites I've messed with insist on you entering a username first.
A lot of them do that to detect if they need to trigger an SSO flow. It's awfully annoying. Things get extra fun when a website migrates from email+password to SSO and suddenly you have two accounts that both exist in their system, one of which doesn't work if you hit enter before the SSO javascript redirect happens.
The counter-argument he makes against people's concerns about attestation is laughable, all he says is that it hasn't happened yet.
Passkeys are not designed just for security, there are other corporate interests involved. It's impossible to share logins for example. He even mentioned this concern and didn't address it.
The device/app lockdowns are already real for TOTP - Microsoft and others insist on using their snowflake authenticator instead of using the standard protocol. So it's not unlikely that they will extend that kind of lock-in to all passkeys.
If they are not a trap, then the standard should be amended to allow third party implementations to forge attestations.
Otherwise, it is a trap. The story of the last 25 years of the internet is user hostile ratcheting away of the open web. Passkeys are obviously another step in the process.
I don't want passkeys. I want to stop being bothered with setting up passkeys, especially if I already have 2FA setup, and definitely if I already have a hardware fido key on the account.
Some context I think is missing: TFA's author claims to use passkeys for 2FA (and so, not as a password replacement as I think is often implicitly assumed in discussion):
> This one can be tricky because I've seen many sites using passkeys to replace passwords, but that's not something we've done on Report URI, passkeys are used as a 2FA mechanism.
I use ProtonPass on every device I own (religiously) and have never had an issue. But it's because I'm very careful to only deal with any credential ever via ProtonPass.
I can imagine it gets annoying very fast if you accidentally put a passkey in the wrong place, ie because Chrome proposes it's own credentials store.
ProtonPass also lets me export the private parts so I'm not stuck as with some passkey managers.
Passkeys are great but require you to understand some things about them, and you need discipline in dealing with them.
Every point in that post has been discussed at length other places, some of which is in the HN thread the author mentions. And the discussions make it clear that the points being made are not seeing the problem - not that there isn't a problem.
Passkeys have benefits - but they also have problems. Many people just don't think the benefits are worth the problems. And many people are afraid that sites will just stop accepting passwords in favor of passkeys, leaving people worse off.
Almost every complaint I see about passkeys seems to be based on behavior and configurations I just do not see in the real world.
“Once I set up a passkey I can’t log in from another device” - have never seen this to be the case. Existing password / OTP codes have always worked as a fallback if syncing somehow breaks.
“I don’t want to trust Apple/MS/Google with my logins” - so don’t. Use bitwarden or 1Password or lastpass or whatever you want to store your passkeys.
“If I lose my phone I’m screwed” - see #1 and enable sync maybe?
Boils down to I believe a lot of folks looked at passkey implementation at a high level, saw some potential pitfalls, and never actually used them to discover those pitfalls have all been accounted for.
Go ahead and skip passkeys if you want, but stop preaching about evils that don’t exist.
Passkeys are great for developers who are into cryptography and security, and who understand the idea and implementation behind it. For the rest of us it's something to avoid.
I don't use passkeys anywhere for fear of losing access. I just don't care enough to study how it really works. With passwords, I occasionally print out all my important passwords and store them in a safe and I know there's no way I could lose access.
I'm moving my HSA because the company moved to passkeys.
I use unique email addresses and passwords, stored only on my devices(Linux, Windows, Android) using open source software (KeepassXC, KeepassDX). Passkeys add new friction I don't need.
Every single IT person thought it would be an extreme mess, too complicated for regular users. In my company we work on the (gas) grid so lot's of blue collar types.
We went there, gave the pilot group a Yubikey and said: This is like the company pass you already have. Without the company pass you cannot enter any buildings. Without the Passkey you cannot enter a computer or app.
If you lose it report to the same people (service desk).
The response has been EXTREMELY POSITIVE. People fucking LOVE getting rid of passwords, password requirements and taking off their gloves to enter it every time.
We are now rolling it out to everyone and next year when we stop our silly "phishing game" contract we will actually save money while reducing a massive cyber security risk for our company: (voice) phishing.
Perfectly fine in a business environment where you don't have privacy. It is unacceptable for any personal computer(including phones) to be leaking unique ids so you can be tracked.
Passkey attestation hands control of the client software to the website. Since surveillance capitalism funds most of the web, this means that, over time, the only approved clients will be surveillance devices, and those devices will slowly add more and more invasive spyware.
Initially, they will probably “just” require hardware serial numbers or similar (so they can join IDs on the backend).
There are already serious proposals to require live web cam feeds for porn site login biometrics purposes, so I can’t really come up with any hyperbole to add.
This is exactly what happens in many companies like bank of america. They are forcing their app to every employee and contractor and is actively tracking locations and whatnot from phone.
Reminds me of when The Powers That Be forced me to connect to websites with HTTPS. Then they stopped supporting Internet Explorer 5. What were they trying to hide?
Lot's of additional great information for consumers and prosumers at whatarepasskeys.info. Many of the questions that are constantly discussed in these comments are answered in the FAQ and content.
Contributions and feedback are welcome! GitHub link is at the bottom of the page.
Saying "attestation can't hurt you, your password manager returns `none` today so it's not a concern" is avoiding the entire point of the original article which was that that can change at any time! I'm already seeing in a corporate context, IT departments forcing hardware attestation as required everywhere. Justifiable, but also clear evidence that it's no longer in your control as the person authenticating. That's the point, passkeys are marginally more secure for you, while handing huge amounts of control to centralized platforms.
you can have a TOTP variant which has the browser display a challenge string & QR code, authenticator generates a 5-6 digit response. include more entropy in the response if you want to do away with the password entirely.
passkeys are trash, I would never opt for dedicated hardware (or a cloud service) and using them with a password manager is extremely messy when you want the password manager to be properly isolated from the rest of your system.
I think it's a bad sign when someone immediately resorts to strawmen and argument from incredulity in their counter-argument:
>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."
Not sure if this mentioned, but I setup a new Gmail account and it wouldn't let me add my yubikey for MFA. I could only add a passkey to my yubikey for MFA.
Wouldn't web browsers themselves be the ultimate passkey managers like they already do with passwords? They'd need a way to export the passkeys to another passkey manager though.
I cannot possibly game out all future adverse design choices that a vendor may make. Today, October 14th 2026, Passkeys offer more upsides to me than they do downsides, so I use them
If a particular app vendor or website changes how they accept or use Passkeys, then I won't use them for that app or site. If my computing platform vendor(s) make it harder or worse to use Passkeys then I'll bail out
There's a lot of what-ifs in every decision, and I cannot possibly nor would I want to, figure out 82 steps ahead in 4-D chess how company X may try to screw me over
There is nothing about passkeys that requires biometrics. Synced passkeys on android will work with your screen unlock code if you do not have biometrics enabled. Same with passkeys stored in a password manager. Same with hardware passkeys that do not support biometrics.
I mean the desire to trap seems to be among the big corporations already.
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.
Just came back from doing a bit of research and apparently I can use Bitwarden to generate and store passkeys.
I have been dismissing the entire concept because I assumed it had to do with hardware keys, which I would never trust. But if it's bitwarden, then I can easily do a backup, and that would be very reliable.
I was expecting the author to at least address the thinly veiled threat to blacklist KeePassXC at [0] (via the very same mechanism they claim is harmless), but of course it's not even mentioned.
I'm sorry, but if your system allows someone to make a credible threat like this, you should make sure to redesign your protocol so that kind of abuse is not possible BEFORE advocating for it. I'm so incredibly sick of people repeating history, only to disappear once we're all roped into yet another anti-user scheme.
What's annoying about passkeys (and not talked about enough, including in this article) is that passkeys seem to be a boon for the targeted-advertising industrial complex.
Since passkeys are tied to verified devices, they guarantee absolute de-anonymization -- and further spread that advertising "wealth" by seamlessly linking across devices, and therefore to their respective corporate stakeholders (i.e. via bluetooth to conveniently login on a laptop via a phone-domiciled passkey).
Username + password at least requires circumstantial marketing analysis to "verify" whether a user is who marketers think they are. But with passkeys, your login confirms your Windows account ID, cell phone MAC address, home address, what have you.
Anything that's tied to hardware is one accident away from locking you out forever unless you set of "2 of 3" or some other "let's make life even worse when it comes to authentication" solution.
"Is not a trap" does not follow from "Is currently good".
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.
Which is a statement about the near future. There is room for a conversation about the long term, but this article is not a part of that conversation.
Thank you for posting on this. The last post on passkeys was utterly confusing and I have been thinking about this until yesterday. I had done some research for a client and had referenced your blog. This whole FIDO2 cryptography-based passkeys system is confusing even to a technical person, let alone convincing the general audience. After bringing together all the different types of passkeys, I had categorized them into three main categories:
1> Synced Software Passkeys (e.g., Google Password Manager, Apple iCloud Keychain): Encrypted locally but synchronized across a cloud account.
2> Device-Bound Software Passkeys (e.g., Microsoft Authenticator app on a phone): Only inside the physical device's secure hardware chip.
3> Device-Bound Hardware Passkeys (e.g., YubiKey, RSA iShield Key): Permanently burned into a dedicated physical USB/NFC chip.
I advocate for "Device-Bound Hardware Passkeys," but not many websites support them. Keeping a duplicate hardware passkey is important in case the original hardware key is lost.
These guys are so dedicated to protecting us from ourselves that they won’t provide any mechanism to export passkeys and port them between devices because it might be used for phishing. It’s just fucking annoying and presumptuous. No im not going to fall for phishing, i need to have some escape hatch to get the data.
Attestation lock down is also ALREADY a real thing. Microsoft sites (and others) frequently require you to use their bespoke 2FA app instead of using the open TOTP protocol. They will do the same thing when it comes to deciding which devices and software are allowed to login, and everything outside the corporate slop safety bubble will be denied.
I absolutely love them now that I have a Mac. They're shared between my phone and my Mac automatically so I can just sign in to anything with my fingerprint.
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.
"A passkey is bound to the domain it was created for, so your browser simply won't use your example.com passkey on examp1e.com."
What happens if a service you use loses its domain? For example, if I run a marxist online forum, it could happen at any time that the US regime sanctions my site and seizes my domain. Would my comrades still be able to log in with their passkeys?
"AAGUIDs are unique identifiers assigned to FIDO authenticators (including passkeys and security keys) and are used to identify authenticator models for attestation and metadata purposes."
If there is any unique id that can track you, then it's a trap. No security system should be leaking unique ids that can be used to track users.
When a website forces a passkey into my password manager without even asking me (fucking Amazon), it is pretty unambiguously something that is not good for me.
> 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.
There's absolutely nothing insecure or wrong with app passwords for a local client application.
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.
App passwords are not scoped, are they? When I set up an app password for my whole google account it is never asked whether it is for email, docs, youtube, etc... . The oauth token is properly scoped.
API tokens are usually explicitly scoped by the user when they create them. I don't recall Google (or anyone else) ever exposing that when creating an app password, but maybe it was scoped down on first use?
Google would not do something that would lock out half of the mobile device market. iOS doesn't do attestation.
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
Are you sure iOS doesn't do attestation? Google recently turned on requiring an iOS or Google-attested Android device with a camera for some reCAPTCHA challenges(i.e. take a photo of this QR code). They waited for Apple to support it before doing so.
Is that the same thing we're talking about here? That sounds like a CAPTCHA, not Passkeys. I mean iOS isn't doing attestation in Passkeys, I'm sure there's some thing on the phone that it's doing that is a version of attestation
Okay? At some point mail applications didn't support IMAP, because it was new. Was IMAP bad because it forced POP3 clients to build new support that they didn't previously do in order to support the improved functionality?
OAuth wasn't about lock-in (since any client can support it), it was about getting off shitty legacy auth
Google today might not do that, but Google tomorrow, when some upper manager's multi-million dollar bonus gets tied by a performance metric on how many people are using passkeys for gmail would in a heartbeat.
> 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.
"Model of the authenticator" could say almost everything about these if the model was let's say "Google Pixel 10". TEE would refuse to sign the attestation if the bootloader was unlocked / AVB didn't verify.
YubiKey attestation is not a problem because the device doesn't work against me in such a way it would require installing custom software on it. And even if YubiKey went crazy, they're not a monopoly.
Situation with smartphones is very much different..
I hate passkeys because they're always tied to a specific account or a device like a phone. I hate being dependent on phones/devices. That being said I know they solve a lot of problems so....
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.
Syncable passkeys are a thing which the OP addressed. Apple, Bitwarden, and other password managers all implement syncable passkeys. In fact, I just did an upgrade of my iPhone 15 Pro Max to an 18 Pro Max and all of my passkeys came along with the upgrade.
I don't think it's appropriately addressed. The apple ecosystem has really good syncing between devices but only when they share an iCloud account. What happens when your work mac isn't permitted to use your personal account? What happens when your company issued password manager and your personal one fights? What happens when your company issued device is an Apple device AND you have to use a mandatory password manager from the company?
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.
Passkeys are confusing, fragmented, awkward, and annoyingly implemented. They aren't a trap, but they are far less efficient and less proven than a password and app-based MFA.
I don't like them, they offer no advantages to logins with random passwords. They would only be more secure if they were forced to be stored on hardware devices like Yubikeys, which almost never happens in practice. In reality it's true that they can be dangerous because they can be set up in a way that doesn't allow storing them in software and using them on multiple devices, and such device-bound passkeys will eventually lock you out or be reset in the same way as password+login (usually just by email).
The standard and implementations are also unnecessarily complex and obtuse. IMHO passkeys are not a good technology.
At the end of the day, I just don't really want them. I already have passwords and I already have to put up with 2FA. Passkeys are just one more damn thing to understand in an ecosystem I already want to spend as little time in as possible.
That being said, password and 2FA is the best combo, where you control the token of the 2FA and it’s on a separate app/platform/etc than where you have your passwords.
Thankfully someone with some sense. I saw that post title and didn't even bother to read it. It sounded like someone having argued with me a decade ago that IPv6 is a mechanism for the government to track you because you have no more privacy anymore because you don't have NAT...
I’ll be silly, but having a unique address per device, is indeed a simpler vector to track, right?
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.
Because I too understand passkey attestation and have written code to do exactly that and have worked in multiple enterprises where we've done a mass Yubikey rollout across thousands of people. So I've got a pretty solid understanding of passkeys, yubikeys, and attestation. As well as I don't read headlines of people claiming it's "tracking you".
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.
Because, apparently, passkey evangelists are a cult.
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.
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
Google and other services like PayPal make Passkeys default if you generated one.
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...
One of the bigger issues with passkeys has been that they get locked to one provider (like apple in your case). Now i HAVE to use an Apple device to unlock passwords, same with Google and Android. Its very much all eggs in one basket.
If it was easy to migrate between services, then i would be a lot more open to using passkeys.
It's fairly easy to export/transfer passkeys (I think, I've never actually done it)
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
I don't need to, I'm not bouncing around password vaults with the frequency of a cheap HAM radio. I've skimmed over announcements of the feature becoming available in a product or two
For a few corporations yes, but not for local only like KeePass or similar. Thats the issue i have with them, if a can set them up as easy as TOTP on KeePass then fine.
Too add to my own comment: I know that its coming, but until i can export to something like. keepass and not a commercial entity then i don't consider it ready.
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.
Well, they're synchronized to my Apple account so that's not an issue. They're available on all of my Apple devices, or even ones I don't have right now that I log into in the future
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
I'm sure they exist but I have yet to come across a service that both removes the ability to also use a password when you register a passkey and also has no other recovery methods if your passkey (and/or password) become unknown or unavailable to you
In theory if I locked down my Apple account with the advanced protection features that are optional, I could lock myself out, but it would be on me to save recovery codes/secondary passkeys/etc during enrollment in those optional configurations
Otherwise, I'd walk into the Apple Store and they'd be able to get me back in my account if I didn't have some alternate method to get in
You do the acccount recovery flow. Options include providing your recovery key or proving your identity to Apple customer support. Do you really think Apple did not account for this?
It's just not a replacement for TOTP and password entirely. It's a shortcut, a super-cookie that is more secure. If I lose the device that has my passkey, I need a way to access my account from another device.
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.
I don't know enough to argue about whether passkeys are a trap or not, but I do know as a user that they appear to be a confusing mess.
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?
So in my own experience, the same tool I use for TOTP is the one I use for passkeys, suggesting it’s at least possible for passkeys to be as frictionless as TOTP.
On the rare occasion I’m logging into a device that isn’t mine, that doesn’t have my password manager on it, scanning a QR code from a device that does have my password manager on it has been enough to get me in. Without sharing any secrets with the foreign device, incidentally
So I’d wager your concerns are valid and are likely to be addressed over time, as this stuff develops rapidly. It might even be better in your scenarios already
Lately it has been a tap-tap operation to enroll a passkey. Sweetwater.com surprised me with it the other day. I was done in seconds, and now I can log in without even having to enter a code. Face ID handles it for both iCloud Keychain and Bitwarden
I thought "Passkeys are a trap" was going to be about this usability nightmare. Some sites, once connected via passkey, make it all but impossible to connect in another way. Some support multiple passkeys. Some do not. Some support passkey or something else. Some do not.
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...
This is the issue.
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.
It's ironic that passkeys are most usable in conjunction with a password manager that syncs them across all of a user's devices, but this is also the scenario where they have the least security benefit over traditional passwords.
I do appreciate that passkey adoption has led to wider support for hardware security tokens for sites where I actually care about increased security over password managers, however.
The specific security benefit is that there's no way for a tech-stupid person, or a tech-literate person who's short on sleep, to copy paste their password into p4ypal.com instead of PayPal.com.
Yes but if you have a password manager that's set up well you'll never be copy pasting passwords in the first place. If the password doesn't show up you know there's a problem.
The benefit of a passkey here isn't zero but it's at the minimum.
From my experience, passkeys work great in the Apple ecosystem. Adding a passkey for a new site on my Mac results in that passkey syncing automatically on my iPhone and iPad via iCloud.
"But what if I lose all of my Apple devices in a freak boating accident?" people often ask or something like it. Apple has a procedure for this [1].
You can contact your "recovery contact" (a trusted friend or family member) that can help authenticate you to regain access to your account, especially if you're locked out or forgot your password.
On a new device, you login to your Apple account, make sure iCloud Keychain is enabled, and all of your credentials, including your passkeys, sync to your device.
I get it—not everyone wants or uses iCloud. Apparently, you can use 3rd party password managers like 1Password, Bitwarden, etc. to backup and recover your passkeys to use elsewhere.
Here's a video of an export from 1Password to the Passwords app on an iPhone [2].
[1]: https://support.apple.com/guide/iphone/passwords-devices-iph...
[2]: https://youtube.com/shorts/gJ8BzT73JzY?si=zSY8vp_v297IfCro
I don't fear loosing all my devices in a freak boating accident. I fear apple deciding they don't like me for whatever reason and then I am fucked.
It is why I never use "sign in with <google, meta, apple, whatever>"
So the solution to my iDevice dying is that I have to buy a new one to maintain access to my accounts and have no option to move to non-Apple hardware?
But what I don't understand is how are passkeys improving what Apple provides here. You could have just done this with passwords and had all the ecosystem benefits you outlined.
You can't enter a passkey at the wrong website.
Ok, great. What about in a mixed ecosystem like I’m using?
The 1password integration works great IME. When a site supports passkeys, 1password seems to offer to save the passkey, and at login time, a little popup appears from 1password asking if I want to use my passkey, and I can either enter my password, or use TouchID to unlock 1password.
I use this across iPhone, MacOS and Windows, and haven't run into any issues.
As mentioned a cross-platform password manager like Bitwarden is the way to go in this case. But yeah, the vast majority of internet users don’t use one.
Get a Yubikey?
You're in a mixed ecosystem. You unfortunately get mixed results.
> no one can attest with certainty that I won’t wake up in a painful situation because I decided to adopt passkeys
Seems that way. Better luck next year, passkey standards(?) people. Hope it’ll be ironed out at some point.
I think the repeated posts and articles constantly rehashing this topic is telling. Every thread is nearly the same in terms of some people saying “here are the reasons why passkeys don’t work for me” and other people saying “you’re holding it wrong”. I don’t think many people come away with their views changed.
> figuring out how to get the flow to set up a LastPass key by default seems unusually difficult
Disable iOS passwords and set lastpass as your only password autofill source. It’s far from difficult. In settings under autofill passwords
In my experience iCloud Passwords is a superior cross-platform password manager than LastPass today, so I’d recommend going in the other direction. (Source: I switched from LastPass to Passwords a couple of years ago.)
I’ve never seen an implementation where passkeys deleted my password or could lead to a situation where it was locked out. They usually just bypass the password+2fa dance when functioning, and otherwise just don’t matter if they don’t function. (Well perhaps except home depot, where it gets mad at me every time I use a password and tries to install a new copy of the same broken passkey as last time, for my convience)
This sounds like an iOS problem. Bitwarden + Firefox on Linux, or Bitwarden + Android, has never been anything but smooth for me when it comes to saving or using Passkeys.
If we go for anecdotal examples that are not representative, then in my case, Bitwarden passkey use ends in an endless loop with most websites. Import and export is still a promise or "coming soon." In the case of hardware keys, two devices are needed. I was a proponent of passkeys, but big players screwed that up, like every single shared "standard".
Bitwarden / ProtonPass + iOS has also been smooth. So sounds like a lastpass issue.
iOS has really good support for third party Password Managers. I've seen the integration with both Strongbox and 1Password. I've heard Bitwarden supports it as well. I think it is a Lastpass problem in this specific case.
LastPass has a tutorial video that shows you how to only use them for autofill: https://www.lastpass.com/features/autofill/iphone
Other password managers do, too: https://bitwarden.com/help/auto-fill-ios/#keyboard-autofill
If you need a tutorial for something that’s supposed to be as simple and transparent as a website authentication, your standard has already failed the usability test.
This isn't a standards problem, this is an "Apple, Google, and Microsoft made using your own software difficult" problem. They have an interest in making their authenticators the default, and the settings UX on all three platforms makes it unclear that their authenticator is active as well as your own "third-party" authenticator choice.
It’s difficult to disentangle one from another, when the companies with the vested financial interest in locking you in are the board members of the consortium creating the standard.
The standard doesn't dictate the UX of settings screens. That's entirely on the platforms which own the screens and I would hope that is kept out of already-huge standards like WebAuthn.
Exactly. I'm disinclined to cut Apple, Google, and MS the benefit of doubt for steering a standards committee to spec + real world usage that privileges themselves.
you can see in both the lastpassword and the bitwarden tutorials that the default iOS password manager can be toggled on or off, just like the other options.
you're misunderstanding: this isn't specific to passkeys, this is for changing the password manager(s) used when filling passwords, 2fa codes and passkeys.
since the person I responded to couldn't find it, I linked tutorials. it amounts to opening the Settings app, going to "General" and then "AutoFill & Passwords", so it's also not terribly difficult to find compared to other iOS settings.
you could've at least tried to understand what's being talked about before blindly complaining.
Whenever LostPass, I mean LastPass is mentioned, it makes me feel twitchy and reminds me of that time I made a really bad tech decision of using it.
LastPass is not a secure place to store your passwords. Bitwarden is the second worst place. Don't just take my word for it, do your own research.
Supporting multiple passkeys should be a minimum requirement for every Passkey implementation. It's generally worth naming and shaming the websites that don't implement that correctly. People want backup passkeys. People want both iOS keys and Windows keys for the most convenience.
My general advice for non-technical users that seems to work pretty well is "sign up for new sites with passkeys on your phone" because most non-technical people trust the password manager ecosystem on their phone, have some amount of multi-device sync already established, and the QR code started Bluetooth LE flow on desktop/Windows PCs for sharing passkeys works easiest with phone passkeys.
(I run a tiny site that is Passkey Only for login and it's been interesting providing technical support for it. One of the biggest recurring issues at this point is nothing in the Passkey flows themselves but the fact that the Facebook in app browser does not support Passkeys for a number of presumably security reasons, plus Meta being jerks, and having to remind new users to "Open in External Browser" before signing up/logging in when posting links to the site in Facebook.)
> The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows
It's still just biometrics as "device PIN". The crucial difference remains that the biometric data never leaves your device. To support Passkeys the remote website only ever sees your Passkeys' public keys, they never see biometric data, they never have a chance to store biometric data in a database to violate PII/HIPPAA/etc standards when it inevitably leaks to "hackers" (or gets sold to the highest bidder).
My takeway from “Passkeys are a trap” is that there are like four different approaches to something that everyone just calls “passkeys”, and they are not the same. For example, some are portable and some are not.
Passkey-over-Ethernet-over-USB C!
> Some sites, once connected via passkey, make it all but impossible to connect in another way.
That's the issue I had with Okta a few years back. I used a password then later added a passkey through Bitwarden on my work laptop. Bitwarden hadn't yet implemented passkeys for mobile.
I went to authenticate through Okta on my work phone. It prompted me for the passkey. Since mobile passkeys didn't exist, I got stonewalled. I had to make a blood sacrifice just to get Okta to allow password access again.
This is why I don’t like passkeys. I’m surprised the “use site from multiple devices” use case isn’t more common.
Am I nuts for accessing a site from both my mobile phone as well as from the multiple computers I use?
This also gets super messy when combined with multi-site auth services like id.me where I need to use the same login to access very diverse sites and services from multiple computers (eg, irs.gov, treasurydirect.gov, disburser.treasury.gov).
The trap is the ratchet towards attested hardware and closed-source-only implementations.
Same. I don't understand it, and there is enough conflicting information (See this article pair as an example) that I suspect it's not something where I just need to do more reading. I suspect there's something fundamentally confusing, and subjectively-interpretable about this.
My suspicion: There is a significant chance I will lose access to one or more account by doing this, so I'm not going to until the air clears. I don't trust the motivations of the services pushing it.
This may or may not help depending on how technical you are, but at the core a passkey works through public key cryptography, like SSH keys work. Setting up a passkey with a site involves sending a public key to the site, which they store as being owned by your account. Then, to sign in, they use your public key to generate a challenge, you use your private key to solve the challenge, and you respond proving you have the corresponding private key.
This means you never send your private key to the site, so if their database is compromised they only get a public key, which can’t do anything (it is public, after all)
No amount of phishing can get you or your client to hand over your private key, because there is no use case where that is required. There is no possibility of MITM, since your private key is never sent anywhere in any situation.
As for getting locked out of your account, losing your passkey would be the same as losing a password. You would need to follow the site’s password reset flow, and if you can recover from a lost password, you can recover from a lost passkey.
This is a fantastic explanation and analogy. Thank you!
I will poke at this a bit:
> As for getting locked out of your account, losing your passkey would be the same as losing a password. You would need to follow the site’s password reset flow, and if you can recover from a lost password, you can recover from a lost passkey.
Do you think this is one of those scenarios that sounds reasonable at first, but can get torn apart by unknowns, edge cases etc? To use an analogy from a recent HN thread that is stretched a bit, is this like saying "If you use a crypto hardware wallet, you're safe", then reading about compromised hardware wallets due to something outside the assumption set.
The threat models here are often very similar to existing Password Manager threat models. If an attacker gets access to your Password Manager they get access to every password you have stored there and can do what they like with that information. The same applies to your Passkey Manager, which in many cases (including for your own peace of mind) is/should be the same app/vault as your Password Manager for other types of passwords.
A lot of the same Password Manager requirements and best practices apply to Passkey Management such as using strong master passwords or biometric unlocks or device PINs. Using Password Managers that support device bound hardware security enclaves, etc.
But even more so than average Password Management, because Passkeys are public key infrastructure the benefits you get out of the box exceed those of ordinary passwords. One of the factors in most Passkey implementations here is that sites (defined by hostname) all get different public keys. (Users are suggested to use different passwords for every site, but are not required to. Passkeys do that technically and are generally enforced in that effort by browsers and Operating Systems.) Leaking those public keys is no longer an issue (they truly are public keys), and leaked public keys aren't generally useful to other sites and apps. (Passwords that leak and even sometimes salted and hashed passwords that leak are liabilities and can be useful for rainbow table attacks or social engineering attacks or password reuse attacks.)
There are certainly edge cases to Passkey Management but in general the threat models follow Password Management threats: does someone have physical access to your device? Do they have access to your biometrics or device PINs?
But also the blast radius is reduced compared to usual Password Management threats: a single leaked private key generally only impacts a single website/app. Being able to sign a Passkey challenge once doesn't mean unlimited access (a password can be used forever after finding it), because challenges have timestamps and random entropy and generally don't support replay at all.
Passkeys also open up other use cases like using a mobile device or hardware security token to log into sites from public computers, which, while not risk-free (targeted malware could still hijack your session while you're logged in), is still significantly safer than giving the public computer a password.
This is roughly analogous to the difference between swiped/card not present and chip/NFC credit card payments. While a hacked chip/NFC credit card terminal could display a different amount than actually charged, it can't subsequently make additional charges after the card or device is withdrawn.
The risks from using passkeys are a subset of the risks from using passwords. There aren’t zero risks, just fewer than for passwords.
If you own only one device—a mobile phone, like the majority of people in the world—and you lose it, how do you get back into your passkey-protected email account?
This is site-specific, but typically by using the same mechanisms used to reset forgotten passwords.
Also, sites can and often do support multiple passkeys, which opens up the possibility of allowing for reliable account recovery using one or more backup devices (one or more YubiKeys, for instance) that is still siginificantly more secure than reset flows using SMS or email.
How would you get back into your email account if you lost your password or password manager? It is the exact same situation.
Most Passkey implementations by default are syncable/copyable/backupable. The iOS default is iCloud Password Manager and keys get backed up to iCloud and restored on device restore when replacing a phone (just like the rest of the users passwords they choose to store). Android has similar defaults with the Chrome Password Manager.
Backup codes, sms backup, trusted user backup. Most of these are quite insecure but better than loosing access to your digital life.
What’s PQ story with passkeys? Considering all the hype that everything needs to be pq safe by 2029 (or whatever), wouldn’t it make sense to delay adoption? Otherwise a db leak would compromise every single account in a pq world.
Most Passkeys use PQ PKI algorithms. From statistics I've seen most are Elliptic Curve on currently recommended PQ curves.
For better and worse, Webauthn is one of the "choose your own adventure" PKI systems where the keys themselves suggest which PKI algorithm/details they use. This is partly because Webauthn has been around a long time and has had to backwards compatibly support a wide variety of physical security keys over the ages.
Most good open source libraries for implementing passkeys will do a good job of limiting passkeys to known good algorithm choices, including any PQ requirements/suggestions. The Passkey standard itself also sets a "higher water" baseline above Webauthn's supported algorithm list.
I don’t follow? What is a “currently recommended PQ curve”? As far as I understand, the entire point is that all ECC is broken by quantum computers, hence the hype to move to something else by 2029. Anyone that can see your public key can compute your private key.
My understanding is that some of the curves are still considered high enough entropy that the number of qubits needed is "unreasonable". The important point remains though that passkeys don't have a fixed encryption suite and can be updated over time.
Passkeys aren’t permanent, you can change or revoke them. If the algorithm used suddenly becomes vulnerable, you would need to rotate all your passkeys.
Sure. You’re assuming every site will revoke your passkey when that happens though. It also feels like a great time to trick people into registering an attacker passkey instead.
With the exception of general-purpose authentication services like Microsoft Entra ID where organizations can set pretty much arbitrary authentication requirements, I've yet to encounter a site where merely setting up a passkey disables other forms of authentication.
The benefit of adding additional authentication methods without disabling others is limited, of course, but it can still be useful where, e.g., you're comfortable logging in using a password manager on your own devices but want to use an iPhone or YubiKey to log in from public computers.
The easiest way to think of it is they are like ssh key auth where the keys are stored in your password manager.
I have no doubt users will get confused about which password manager they have their passkey stored in, but these are the same users who don't know what a password manager is so they share a password across everything and get hacked regularly.
It doesn't help that the primary benefit we get from passkeys, in exchange for a lot of pain and fragility, is that phishing is harder to pull off. That's a big deal for a lot of people, but frankly, I'm not one of them. I already know not to click on links in emails.
I've never fallen for a phishing attack and any attack targeted and sophisticated enough to catch me is probably going to be sophisticated enough to steal/hijack a passkey anyway. In the extremely improbable event that I did get phished and somebody got into my account somewhere, they'd only have access to that one account because unlike most people I don't re-use passwords and recovery would no more complicated than contacting customer service and resetting my password with them.
Considering the horror stories of people who been screwed by using passkeys, I'm sticking with "not worth the trouble"
The defining feature of passkeys is that they're stored in your password manager, and you can't read them, so you can't be tricked into typing them into the wrong web site.
Most password managers don't even allow you to export/backup the passkeys yourself. (Bitwarden is an exception.)
Instead, password managers support a finicky app-to-app transfer protocol called "Credential Exchange Protocol" (CXP), where you install two password managers at once, and they convey your passwords + passkeys, without ever generating a file that you can read. (And Microsoft's password manager doesn't even support CXP yet. As of today, you can only do it on Android and iOS.)
Many people read that and say, "see, that's why I'm never going to use passkeys! I'm safer managing my own backups, and I'm too smart to be tricked into copying and pasting my password to the wrong site." But they're wrong. You are not too smart to be tricked. Nobody is.
If you use the same cloud-sync password manager everywhere, passkeys just work. If you don't, you'll have to use Credential Exchange Protocol to transfer them, which is a hassle.
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.
> The defining feature of passkeys is that they're stored in your password manager, and you can't read them, so you can't be tricked into typing them into the wrong web site.
That's the biggest issue.
Haven't been tricked so far. On the other hand, I've had a couple of accounts locked because "we don't like your ip", "we want your phone number now", or "we want to send a push notification/text to the phone that just died".
Why would I trade control over my credentials for some potential security gains, while introducing new dependencies on Google, Apple, or whoever runs my password manager - and the very real risk of being locked out of all of my own accounts?
> You are not too smart to be tricked. Nobody is.
Maybe, but most websites I really dont care if my account gets hacked. I care way more about being able to login conveniently. Im just as frustrated with seemingly every single website wanting 2fa doing a 2fa check every week or less.
Great news! If you use a cloud-sync password manager, passkeys are way more convenient than TOTP.
Until I need to login to the website on a PC that is not my own.
That actually works too. The PC shows a QR code you scan with your phone which negotiates the login. Doesn't require signing in with anything on the PC first.
I do this with my work laptop where the passkeys are stored on my personal phone.
This doesn't work if the device you want to login on doesn't have Bluetooth.
> But they're wrong. You are not too smart to be tricked. Nobody is.
If my password manager is entering my password for me, so how can I be tricked? That's the superpower for passkeys, right? It also applies for plain passwords. Infact, if a login page looks familiar, but my password manager doesn't show any matching credentials, that throws up red flags for me, because I only use my password manager.
Because password managers allow you to use a password and 2fa even if the url doesn't match. And sites often legitimately change domain or have multiple domains which trains users that sometimes it doesn't work and you have to override the automatic matching.
Passkeys physically don't allow you to send them to the wrong sites so the sites have to make sure they keep working.
If the password database of the website is hacked the attacker knows your password for that very website. With passkeys he knows your public key.
"Weird, my password manager isn't submitting my password properly. Well, that happens sometimes. I'll just copy and paste it" [or manually select a password to autofill]
on Android i use keepassDX it support passkeys and their export too
> Many people read that and say, "see, that's why I'm never going to use passkeys! I'm safer managing my own backups, and I'm too smart to be tricked into copying and pasting my password to the wrong site." But they're wrong. You are not too smart to be tricked. Nobody is.
It is not remotely difficult to not fall for phishing attacks. I think I've seen one in my entire life which was actually well crafted such that a person might fall for it even if he was paying attention. One. Everything else is the lowest effort slop where all you need to do is hover over the link to see "this does not in fact go to microsoft.com like it claims".
Randomly generated strong passwords for all practical purposes are just as good as passkeys and keep you as the user in control. If you really need to copy/paste between a laptop and mobile or give it to a friend/family member, you can.
What do passkeys offer users that rand strong password + password managers don't?
They are tied to the issuing domain and the system that carries the passkey will refuse to present it to any other domains. It’s more or less impossible to fall for phishing or a spoofed site. Your password manager may have similar functionality for automatic filling of forms but less sophisticated users can often be tricked into providing passwords via copy and paste.
Phishing is even easier. Instead of "open your password manager, copy your password and paste it here" it becomes "your passkey is out of date, click here to enroll a new passkey. As part of this process a reset link will be sent to your email and code to your phone. Do not share the code with anyone."
Yep, just look at the FBI alert of signal accounts being hacked. This is the same "vulnerability" that syncing passkey will have.
This ^. It introduces MORE layers to phish. More external 'trust me'.
ESPECIALLY when seemingly no one actually knows how passkeys actually work.
The less sophisticated users can use their passkeys then, and the rest of us who know what we’re doing and have been for 25 years can continue to not support vendor and platform lock-in and forced device attestation. The amount of marketing and push behind passkeys does not feel entirely genuine to me.
You know how to feed the site certificate into gpg before every login to check for url phishing attacks? I usually have to ask my password manager to do that (which didn’t exist 25 years ago)
Bitwarden browser extension, and I imagine most other password managers, will only offer to auto-fill a password if the site matches. There's a setting to choose the exact rule, but the default is matching the domain name.
So if you get sent to goog1e.com, your password manager won't prompt you to enter your Google passwords. Though of course, you could still manually paste it in if you got somehow convinced that it's a legit site.
Same with password managers inside web browsers: they'll only present the filled-in password for the original domain, not a phishing domain.
Bull. People need to stop repeating this.
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 unique 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.
>They have to be transmitted.
Everyone knows to hash passwords now and browsers basically enforce SSL. This is not a practical differentiator.
>Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).
>If your entire database is stolen, it’s useless.
As are databases containing strong randomly generated password hashes. What is your threat model here, they somehow forgot to hash their passwords yet they are still hashing session tokens, storing customer data in completely separate databases, safely storing private keys, etc.? It requires quite the strawman scenario to apply.
> They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).
This is only technically true because of the definition of what a passkey is is vague.
Hardware Attestation solves this problem and is "good actually". The issue with attestation is when site attempt to restrict which enclaves/sources can register keys. But if you don't restrict who/what can register keys, attestation is super useful for preventing this exact issue.
When you register your key initially you establish your hardware attestation parameters. The attacker cannot know those parameters unless they were the ones to initially register you for the site as the public attestation signature is unique per-key and the private one per-use with the public one verifying the private one.
So if you have remote attestation you can verify whether the source presenting the signature for auth is the same source that created the signature and trivially block MITM attacks. Likewise for more complicated custody/proxy chains.
This just by itself largely solves MITM key re-enrollment attacks but tech camps that support passkeys either ideologically oppose attestation (due to understandable enclosure fears) or enforce hardware attestation for enclosure purposes without bothering to address MITM/signature origin checks.
Can I do hardware attestation across several devices yet? My desktop, my phone, a console, my girlfriends phone of a different brand if I need to log into a shared account, etc?
It seems like one of those things that only works if you're sticking to one ecosystem.
Yes. You can register as many different passkeys as you want. Any limitation in passkeys registration quantity is a limitation of the website/app itself and not a limit of the spec, etc.
>Hardware Attestation solves this problem
Only in theory. Suppose you are a bank, which enclaves/sources/devices do you support vs. not support? What do you do for users on a desktop PC that don't have an enclave? Phishing sites will leverage your weakest enrollment option.
Strictly speaking it's mainly hardware attestation but it's technically "hardware based passkeys" and "remote attestation". So if you rely on attestation in general and don't restrict the attestation source it works just as well.
Software passkeys can be stolen if the client is compromised but they aren't vulnerable to MITM or phishing as long as attestation is used.
> which enclaves/sources/devices do you support vs. not support?
You support all of them and prefer the strongest configuration for the source available.
If you've registered a hardware based key with attestation and then an attack tries to intercept that via phishing or MITM, the key already has its capabilities established and if you try to use the key without attest it should fail.
If you register a key without attestation support then you may be vulnerable to MITM or phishing but you can't intercept a user/their passkey with a stronger set of capabilities and downgrade them.
Stealing passwords is already an incredibly rare attack nowadays. The attack is almost always on the cred reset path. Suppose a user loses their phone with the secure enclave and wants to login to your site using their laptop without a secure enclave.
Are you really going to block that cred reset on the grounds that it's a downgrade? You're going to have a lot of users calling your support asking why they can't login after switching devices.
So you allow it, then oops it was not a laptop, it was a phishing site.
> (re-enroll attacker's key or register attacker's passkey).
What is the mechanism to do this? As I understand it, the passkey is basically a public/private key pair. You'd have to download the attacker's key pair into your passkey system? What passkey system allows you to provide a key pair, rather than always generating one? I'd like to see a step-by-step walkthrough that doesn't involve a straightforward phishing scenario, or running privileged commands on the users computer (if you can do that, all bets are off.)
>Everyone knows to hash passwords
got a good chuckle out of me. your optimism is inspiring.
Anyone not hashing passwords is going to find a way to mess up passkeys.
How? Public keys are public keys. They are designed for full disclosure. They are "leak proof" in the sense that leaks should not ever matter. The useful thing about public key infrastructure is that it asymmetrically moves the security threat to managing the private key, which is in the user's hands, and away from the public key. With a strong password I have to assume that both my Password Manager is up to the task of not leaking it and that the remote website handles my password correctly (including salting and hashing and not leaking and not using a hash algorithm with known collision flaws and not using a hash algorithm with large well known rainbow tables, etc…). With a passkey I mostly only have to worry that my Password Manager is up to the task, those are the threat models I get to worry about, I no longer have to worry about if a remote website is keeping pace in the ongoing arms race because all they have is a public key that I don't care if it leaks.
Here's one way to screw it up: make the public key the password. Normally only the user and the site know the user's public key for a given site, so it's as secure as a password, and nobody notices the problem.
> re-enroll attacker's key or register attacker's passkey
Can you walk me through how that would work?
Probably something like this https://cybersecuritynews.com/hackers-abuse-microsoft-entra-...
The article describes a straightforward phishing attack that works specifically against accounts that are _not_ protected by passkeys:
> Depending on which multi factor method the account uses, the victim sees a matching fake screen, whether a one time code prompt, an authenticator app number match, or an SMS page.
The only sense in which passkeys have anything to do with this at all is that the attackers used the word "passkey" in their emails. When a phishing campaign with the subject line "Your Mailbox is Full, Log In to Fix Now!" succeeds, that does not demonstrate an interesting vulnerability inherent to your mail server's mailbox size limits.
> The only sense in which passkeys have anything to do with this at all is that the attackers used the word "passkey" in their emails.
That's wrong. They attackers actually go on to create a real passkey that gives their device access to the compromised account.
Accounts that are already protected by passkeys can still be vulnerable too. see:
https://www.forbes.com/sites/zakdoffman/2025/08/28/yes-your-...
https://www.esentire.com/blog/securing-passkeys-thwarting-au...
https://unit42.paloaltonetworks.com/passwordless-authenticat...
Right, if you phish the credentials to an account that is not protected by a passkey, one thing you can now do is set up your own passkey on it. That's exactly what passkeys would've protected the victim against!
The other articles you've linked also describe attacks against accounts that allow non-passkey logins, or attacks that require a compromised browser.
There will never be a login that doesn't involve a potentially compromised device/OS/browser/password manager. As long as using a passkey means using those things too, having a passkey isn't enough to keep attackers out of your accounts. They can be pretty good about keeping legitimate users out of their accounts though. You just have to weigh that risk against the risk of you falling for a phishing attack.
In this attack, it sounds like the key step was that the user entered their username and password, thinking they were preparing to enter a passkey. It wasn't the passkey system itself (which would prevent this attack), it was the transition from password → passkey system that was attacked.
In any case, if you can get the user on the phone and convince them to let you walk them through a bespoke auth flow, I doubt there is any auth mechanism that would stop this. This is why every auth system these days is constantly telling you "We'll never ask for X", because at that point, the game is over.
> In any case, if you can get the user on the phone and convince them to let you walk them through a bespoke auth flow, I doubt there is any auth mechanism that would stop this.
Exactly. Passkeys can't solve the problem of phishing. At best it only makes it more difficult. Phishing is less of a concern to me personally than losing my access to my account because of the complexity and fragility of passkeys. I've read enough horror stories, even from very capable people, about people who were screwed because they thought they were doing the right thing by setting up passkeys. Passkeys sound like they might be great for many other people. My vulnerability to phishing doesn't justify the risk of passkeys.
Isn’t that a bug in the Microsoft software, not the pass key specification?
That's like saying that there's nothing wrong with passwords, it's a bug in the human that can't tell the difference between their bank's website and some random web form with their banks logo slapped on it created on wix.com
Attacks on passkeys have been because of flaws in the OS, or the browser, or the password manager, but none of those things are going away any time soon. Passkeys depend on those things, which means they aren't are solution to the problem of phishing. They just make phishing harder.
Passkeys also make things harder for the legitimate user though, and there's a very real question of whether the protection they offer is worth the trouble.
But every single one of those attacks has also existed for classic password managers.
It’s not a new vulnerability. It’s not a reason to roll out Passkeys unless it’s also a reason to get rid of passwords.
With Passkeys you’re still net ahead.
You're arguing theory and not practice. In theory they're better of course. The problem is the implementation. And implementation is a mess because everyone is trying to lock you into their own little ecosystem.
In implementation, passwords are a complete disaster. We’ve been dealing with the fallout of it for decades.
In theory, if everyone did everything correctly and followed best practices, passwords would work quite well.
Reality shows we are not anywhere near there.
Exactly! Whereas passwords are extremely flexible and can be stored, managed, and written down in numerous ways that are vendor-independent. Want to store your passwords on sticky notes in a safe? Go ahead! Want to use Bitwarden? Yep, you can. KeePass for offline storage? Yes! With good password hygiene (128-bit entropy, never reusing passwords) there is virtually no risk, especially with 2FA added.
You can (and should) do the same with passkeys. Like SSH keys, they're just text.
Save a passkey in Bitwarden, then export your vault as JSON. You'll see a nice plain text JSON block with your passkey that you can print, or backup, or import into whatever replaces Bitwarden.
> There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.
You replied to someone talking about password managers, which objectively do exactly that.
> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
And Passkeys don't offer portability, user choice, or user control.
Cryptography may be a solution, passkeys are one technical implementation that at is core is designed around smartphone-first, vendor-first, brand-loyality-first thinking.
>which objectively do exactly that
password managers do not do that. open up your password manager, press "copy" on the password, and then paste it into a random website. it will paste it.
(i think 1password just recently enabled an option that will warn you if the website is different than the one it has, but it still lets you paste it)
So they do, in fact, do that and you have a workaround? They won't autofill on a phishing site, thus the copy/paste bypass.
It is a pretty big red-flag.
Autofill is not the same as use.
You can not use a passkey on the wrong site. Period. They’re unphishable.
Short of somehow talking a user through finding the full private key and getting them to send that to you, there is no way to trick a user into giving you what you need to get into a website impersonating them.
That’s absolutely not true with a password manager. They may TRY to prevent you from ACCIDENTALLY entering it on a website, but they don’t stop you.
> Short of somehow talking a user through finding the full private key and getting them to send that to you, there is no way to trick a user into giving you what you need to get into a website impersonating them.
So you're telling me they're phishable?
>They won't autofill on a phishing site,
right. and in an office setting, bob in accounting will go "weird, autofill isnt working, ill copy/paste it".
that is not a possibility with a passkey.
It is Schrodinger's Bob - Both technically literate enough to know how to do that, while also not being technically literate enough to spot the phish or determine why autofill isn't working/the password manager isn't matching.
This is where Passkeys shine, in an edge-case user that is neither of the two most common user types. Basically a unicorn situation.
It's definitely not a unicorn situation.
Copy and paste is not a skill that requires much technical literacy. I've not seen a Password Manager that makes the copy button hidden or hard to find or need much technical skill to use.
Many "legitimate" websites, especially corporate "SSO", accidentally train users that autofill just doesn't work some of the time. Example Corporation's SSO configuration generally has users put their password into auth.example.com, except when the app in question is using some weird SAML flow and accidentally ends up at saml.example.com or auth.okta.com. An old legacy internal app still needs the password inputted in an HTML Basic Auth prompt due to a redirect through oldauth.example.com. The user learns to just copy and paste and have no idea why autofill works on some internal apps and not others because they have no idea what SAML is or why a legacy app is special/different from modern ones.
It happens on the public web, too, to a lesser extent. A website goes through a "rearranging deck chairs phase" and can't decide if id.example.com is cooler than auth.example.com or if they should just put login only on top level example.com and flip back and forth over a few weeks as different internal teams "win" or various A/B tests run.
>It is Schrodinger's Bob - Both technically literate enough to know how to do that, while also not being technically literate enough to spot the phish or determine why autofill isn't working/the password manager isn't matching.
you must not work in regular corporate environments. this happens all the time.
yes, they know how to hit the big "copy" button but don't know how to debug an extension.
take a year or two to work security (or general IT support) in a non-tech-company corporate environment, and get ready to have your socks blown off. people become exceptionally literate with things they interact with all day (excel is great example of this) yet have no idea that google.example.com isn't an official google website.
> Passkeys don't offer portability, user choice, or user control.
This is objectively false. Every major platform provides user choice in Passkey Manager. It's the same flow/settings to setting up a third party Password Manager.
All of the ecosystems have defaults that include some amount of portability: iOS defaults to Passkeys synced through iCloud Password Manager and backed up/restored with device backups. Android defaults to Passkeys synced through Chrome Password Manager. Windows defaults to Passkeys synced through Edge Password Manager. All of the ecosystems have plugin systems to support third party Password/Passkey Managers such as 1Password or Bitwarden.
Most devices that support Passkeys support a QR code bootstrapped flow for cross-device/cross-ecosystem Passkey challenge signing via Bluetooth LE.
Most ecosystems deliberately don't provide explicit private import/export to help protect users, but that's more an implementation detail than a technical requirement, and mostly not an implementation detail for "lock in" reasons but for simple security reasons: the private key you cannot export is the private key that is harder to steal by bad actors. The private key that you cannot manually import is the private key that can't be installed by bad actors.
Passkeys can be, and have been, stolen and hijacked. They make it more difficult for scammers and hackers to get into your accounts, but not impossible. How many phishing emails have you personally fallen for that this is your #1 concern over the fragility and complexity of passkeys?
As far as I know, it has never happened. I know there was a presentation or two on bugs in individual password managers.
But that is not a flaw in passkeys. And there have been bugs in password managers that expose standard passwords as well.
> But that is not a flaw in passkeys.
By that reasoning passwords are 100% secure too, it's the human's fault when they fall for phishing sites! Passkeys depend on humans, password managers, devices, certificate authorities, browsers, and operating systems. That's not even including the implementation itself (https://www.esentire.com/blog/securing-passkeys-thwarting-au...)
All of this means that even when you're using a passkey an attacker could still break into your accounts. Passkeys can make it harder for them, but it can make it harder for you to get access to your accounts too. For me, I don't think the risk of phishing is worth the trouble passkeys would cause me.
Can you provide details on this attack?
Typically the user gives a website their public passkey, which does not need to be kept secret since it’s public. If the website is hacked the attackers only get information that is already public.
You seem to be talking about a scenario where a user’s private keychain on their computer is compromised and the attacker is able to access other systems from that same machine without the user’s knowledge. (Note that the keychain data is itself encrypted so can’t be used from a different computer.)
There are a lot of examples of attacks and bypasses, but this one is probably the worst I've seen so far https://www.techtimes.com/articles/323093/20260805/google-pa...
It's not just the end user that you have to worry about, attacks are helped by the fact that websites suck at passkeys too
"...we developed PASSKEYS-ATTACKER. The tool allows for precise manipulation of WebAuthn messages at every step of the protocol and integrates 15 attack types of which 10 were not covered in previous work. Among them, 2 attack types have critical CVSS scores. We discovered them on 18 out of 103 evaluated websites. These attacks take over user accounts, delete their passkeys, or lock them out of their accounts. Nearly half of the tested sites (53) were vulnerable to at least one attack with a high CVSS score, exposing users to threats such as phishing and session fixation." https://www.usenix.org/conference/usenixsecurity26/presentat...
> Passkeys can be, and have been, stolen and hijacked.
Proof needed.
> How many phishing emails h
The point is the average Joe will not be phished - especially important stuff - like email or eBay or bank. That is the reason for passkey.
Yes, many people in HN can avoid scammers.
Feel free to google for more:
https://www.forbes.com/sites/zakdoffman/2025/08/28/yes-your-...
https://www.howtogeek.com/passkeys-were-supposed-to-be-more-...
https://www.malwarebytes.com/blog/news/2026/08/googles-synch...
https://cybernews.com/security/google-passkeys-vulnerability...
https://cybersecuritynews.com/passkeys-via-aitm-phishing-att...
https://www.zdnet.com/article/your-passkeys-could-be-vulnera...
You lose a device or the local DB that keeps your passkey and you are screwed.
You need to migrate from one login domain to another (rebranding, change of login providers...) and none of your customer credentials will carry over.
Your password might not be stored anywhere except in your head.
Your local storage gets compromised and your passkeys are there for the taking (password in your head isn't).
"Cloud" password managers who hold your passkey private key part is exactly like them having your password and are worse than websites having proper cryptographic hash of your password: they might not be e2e encrypting it (you were comparing with sites doing password hashing wrong too), so a breach exposes all your passkeys just the same.
My point is that there is no panacea. Passkeys are like SSH keys for the web. I still put a passphrase on my SSH keys. Do you?
> There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.
Replying only to this part, using a password manager with autofill solves this problem. The password manager (I use Bitwarden, but there are others) can check the site you're trying to log in to, and only autofill passwords that are for that site. I don't have to do any work to differentiate example.com from thisisexample.com, because Bitwarden will only show me the example.com password.
Nothing of this explains anything, at best it increases the confusion. If anything, all this mumbo jumbo pushes me further away from using passkeys than before.
the non-mumbo-jumbo version is:
- you can't get phished
- you dont need to worry if your password is securely stored
And what if I need to use a different device?
- Your Passkey Manager generally offers some form of multi-device sync. Most Passkey Managers are the same as Password Managers so it may even be a multi-device sync you are already used to.
- Devices support a flow where a QR Code kicks off a Bluetooth LE handshake between two devices to sign a one time Passkey challenge. That can be used for one time login on devices you don't sync your Password Manager to or to help bootstrap additional Passkeys on the new device.
my passkeys are in 1password, and accessible from any device i have 1password installed on. it's a very smooth experience (both adding new ones and using existing ones).
There’s support for that and has been for years. It works fine.
> They have to be transmitted.
What do you image happens with passkeys?
> They (or their hash) have to be stored.
What do you image happens with passkeys?
> 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.
From the consumer, do you imagine a hacker has my key to unlock my password database?
From a service provider, do you imagine they are not using encryption at rest?
> Cryptography is the solution in passkeys are the implementation.
Do you imagine cryptography is not used with passwords?
The secure part of a passkey does not have to be transmitted. It’s public key cryptography. It’s used to sign something as proof that you control the key.
And for that reason, the server does not have the secret. It only has the public key, which is useless on its own. So it can be stored in the database in plain text unencrypted. And you’re not really taking any risk.
Passwords are not cryptography. People may use cryptography to store them at rest, or their hash. But the true password still has to be transmitted. The first time, and every time.
>But the true password still has to be transmitted. The first time, and every time.
The password never has to be transferred. In fact never having the password should be the goal. Not even a first time. Don't let the password leave their device. You transmit the hash.
That just means the hash is effectively the real password. If an attacker gets a hold of the hash that you transmitted, they can use that to authenticate to the server.
All that you gain by transmitting the hash, is that the attacker will need to modify the client's request to inject the stolen hash.
If the client (website or app) runs on the attacker's own devices, this is trivial. I suppose it is a valid obstacle if we are talking about an ATM or similar locked-down client.
What are you talking about? Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.
The way passkeys are being pushed is so clearly an attempt to add friction to leaving walled gardens. Stop talking in absolutes in a world of greys.
That's not accurate. If that were true, then a hacker stealing password hashes would enable them to instantly log in, without cracking them. Rainbow tables and dictionary attacks exist for a reason.
Pass-the-hash has been tried in NTLMv1 and thankfully that was the end of that failed experiment.
Modern password authentication is performed by the client sending a plaintext password encapsulated within a symmetrically-encrypted tunnel. On the Web that's with TLS. The server then uses bcrypt or another scheme to hash the password (along with the stored salt) and compared that resulting hash with the value in the table.
>then a hacker stealing password hashes would enable them to instantly log in, without cracking them
How do you know the hashed value stored in the database is the same hashed value the user submitted? Server side I can add a salt and hash more before storing or comparing.
> How do you know the hashed value stored in the database is the same hashed value the user submitted?
Please explain how authentication would occur without a comparison between the user's submission and a value stored at creation/update of the passphrase.
There is a comparison.
> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.
Unless I'm misunderstanding what you're doing, this achieves nothing.
Hashing the password on the client side makes the hash the password, and MITM attacks are still possible.
Sure, you could MITM still if all you do is that, as with anything it depends on what you are defending against.
If you are defending against clear text being discoverable, then bcrypt hashing with a unique salt on the client is good enough.
If you are trying to prevent MITM you can combine that salting with public/private key transmission of the bcrypt hash to the backend (effectively the same idea as pass keys without the downsides).
MITM just affects your service, and doesn't always matter depending on what the service is, for example, a recipe manager doesn't need to have bullet proof security.
What if the hash you're sending is discovered? I can use that to login to the service; it offers the same protection as a plain text password.
As the hash is being encrypted with the public key in the client, that would require that the client be compromised. In which case the original password is already exposed at that point, thus a discussion of the transport is no longer the concern.
The point of a hash is that the password is not stored on the machine long term. Thus, if an attacker gains access to the back-end and exports all the hashes, you can't reuse the hashes themselves to login. I.e. you need to do a password-cracking attack, which is infeasible with a password of sufficient length.
I don't care if someone gets my password hash. They aren't going to crack it due to the complexity of it.
Here is my hashed password. Good luck:
You can't use that to login to my system. You can only use it to validate if I give you my password...Correct. The hash effectively is the password at that point.
If you’re storing the hash unencrypted in the DB, and it’s “just” a hash so why not, you’ve gone backwards.
> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.
While rare, a couple of sites which has many (>1000) users have sent me my password in the plain when I told I forgot them.
Many sites have e-mailed my password in the open when I registered, as well.
I don't defend passkeys here, but too many weak links are present in password based flows today. If someone uses per-site strong passwords, one can contain the leaks, but use the password even once, and the problem grows exponentially.
I immediately emptied my account with BBVA (a major bank with $37B yearly revenue) after their app asked me to validate my identity by entering "the fourth character of your password". Subsequent attempts asked for different ordinals. This was in 2023.
> Many sites have e-mailed my password in the open when I registered, as well.
A phpBB forum era classic!
It adds a vintage character to otherwise modern and boring websites. This happened to me as recent as last week, BTW.
> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.
Don't assume everyone coding a login page is as competent as you though...sadly.
The mechanism proposed by the GP is not competence. It's a well-known vulnerability called "pass the hash".
But the sites where I actually care if my account gets compromised - Steam, FastMail, DigitalOcean etc. - are very unlikely to screw up password storage.
I'm never going to bother with paranoid security inconveniences for the crappy website my local pizza place uses.
This is incorrect implementation fyi.
You are supposed to send the password, via TLS so it's not in the clear, to the server to be hashed.
If you hash on the client... then the hash essentially becomes the password, and defeats the purpose of a hash. I could just steal the hash and use it.
The name of this vulnerability is "pass the hash"
Hash the hash.
> Bull. People need to stop repeating this.
Wow, you sound like you know what you're talking about.
> They have to be transmitted. They (or their hash) have to be stored. And so so many get that wrong.
Ok, you've stopped sounding like you know what you're talking about.
Passwords have to be transmitted or stored. They don't have to be transmitted and stored. As you note, we usually opt for transmission but not storage. You could do it the other way around.
> There is nothing to prevent you from entering your super secure unique password on the wrong site if you get phished.
> Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
They can still be entered. Not working isn't the same thing as not being sent. A cryptographic exchange should hopefully fail before anyone who's pretending to be the counterparty you want learns enough to impersonate you. But you can enter anything anywhere.
> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
Unique strong passwords offer the following:
1(a). They are never transmitted (well, once), and provide phishing resistance; or
1(b). They are never stored, and provide leak resistance.
2. In the event of compromise, no other credentials of yours are simultaneously compromised.
It's true that it would be nice to enjoy phishing resistance and leak resistance.
Here are some other things unique strong passwords offer:
3. You are free to establish any relationship you like, with anyone you like. You don't need permission from Yubico to create an account somewhere.
4. Yubico can't pretend to be you.
You might notice that passkeys don't offer any of those. Your comment appears to enthusiastically endorse the idea that passkeys are a trap.
> Passwords are fundamentally broken. They cannot be fixed.
This is the "PGP is fundamentally broken" argument again. It will never be valid.
If you ask any followup questions, the reason that "PGP is fundamentally broken" is that people use Outlook plugins, and those plugins mean that they're constantly sending email in plaintext when they should have sent it encrypted. There's a very, very simple solution to this.
Don't use Outlook plugins. Run PGP yourself.
Before you send your email, check whether it looks more like "OK, everyone's ready for the kidnapping on Thursday" or "Eb+h+Q1iDEYUgJlO5GTtmcibC+D1E9oJWvZeoy9I2tpqxe9j/iokAx0R". You will be able to tell the difference. Nobody has ever failed at telling these apart.
If you were about to send the email, but it's still in plaintext, don't send it.
Passwords are no more fundamentally broken than PGP is.
As I understand it, in theory, there is no "secret" exchange over the network with passkeys, once they are initially set up (one side sends a challenge to decrypt, and the challenge is one-time use. The decryption all happens locally.) And so they aren't as vulnerable to phishing or other common ways to steal passwords (such as key loggers, which don't even involve the network.)
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.
A decent degree of phishing protection. And passkeys are not vulnerable to an attack that can transiently read server memory.
AIUI: A password can be entered into a phishing site, a passkey can't.
--------- Oct 14 - 12:30pm... --------- There is a wall of text below your question and _none coherently, concisely answer your question: "What do passkeys offer users that rand strong password + password managers don't?"
Passwords always risk a transferrable oops: "Hi friend, this is the bank calling. We've got a big issue: what's your password so we can fix it?"
My thoughts exactly.
Anything that randomly makes a Windows 8-style popup offer to keep my login credentials safe makes me want to run farrrrr away.
The vibe of the original criticism, even with its technical flaws was this: are passkeys - as a standard, and a user interface - vulnerable to corporate capture? I think passkey defenders are focusing far more on the theoretical technical superiority, and ignoring how instinctively alarming the average implementation is.
We face a lot a lot of attempts to capture our data, and passkey feels like a new frontier.
For me, I know exactly where I am with my password manager & TOTP. I think the current confusing interface of passkeys will make me less secure rather than more, so I've not invested the time to think about how to use them.
Agreed. They put someone else between you and your access, between you and your security.
Lets give the guys at the Home Depot all the keys to our super secure house locks. Any time you want to get in, just roll down to one of 5 convenient locations, authenticate with the HD, and they will issue you a one time entrance pass to the house. Easy.
Bullshit.
Definitely not wrong here. It is a confusing mess for most people. Thankfully, for folks all in on the Apple ecosystem, it should be pretty decent of an experience. Everyone else? not so much.
I think this is exactly the "Passkeys are a trap" argument though right? If you lock yourself into a single vendor, everything is easy and beautiful. If you choose a diverse set of vendors, it sucks so much more than passwords and password managers ever did.
Keepassxc and strongbox passkey integrations seem pretty good on all of the OSes and browsers I've used.
I think passkeys make a messy credential situation even messier, but make a tidy credential situation even tidier.
Good thing the FIDO group is already trying to block key synchronization with keypass and other open source managers...
That wasn't FIDO as a group. That was one vocal member and even their employer ended up disowning the comment. It also wasn't about sync, it was about plaintext export.
It was about forbidding members from syncing with any software that allows or can be altered to allow plaintext exports.
From one guy mad in a github thread. It's a nothingburger.
> Keepassxc and strongbox passkey integrations
Isn't that a single vendor (or two)? How is this not lock-in?
KeepassXC at least allows you to export your passkeys should you choose. The people behind passkeys do not like this. https://github.com/keepassxreboot/keepassxc/issues/10407
This is not accurate. The very first sentence of that issue is:
> Passkeys should never be allowed to be exported in clear text.
and from another comment by the issue creator:
> I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.
They're arguing for storing them in encrypted form. That's very much a different argument than arguing against exporting. I'm not taking any sides here, I just think it's bad to so badly misrepresent people's standpoints.
The kdbx format is encrypted on-disk. You need a password to decrypt the database.
That isn't what is being discussed by the issue. The issue was pertaining to an unencrypted export.
Which changed to KeepassXC looking to support the standarization work to allow passkeys to be moved between user-controlled software products.
The complaint wasn't in allowing credentials to move (that is the point of the CXF and CXP work). The complaint was in having sensitive data in a plaintext file live long-term without any protections. That is also why one of Tim's early recommendations was to require encrypting the file via a passphrase.
Asking that services require you to encrypt your backup file by default to protect against local malware or malicious access is certainly not "The people behind passkeys do not like...allowing you to export your passkeys".
keepassxreboot/keepassxc#10407
I suppose we have different interpretations of the headline.maybe read the whole issue?
Well, KeePass is self-hosted, and I hadn't heard of strongbox before, but it says on the website:
> 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.
I use nextcloud to sync my own keepass database across my devices. Both nextcloud and keepassxc are open source.
Please explain how self hosting open source software is locking me into a vendor.
If the sky falls and strongbox ceases working with mac/iOS I can use android and linux. Nobody is locking my lockbox.
On iOS devices you can import/export Passkeys between supporting password manager apps (including Apple Passwords).
In my experience, migrating between Apple Passwords and Bitwarden worked without issues, in both directions.
Wasn’t part of the point of the last article that some of the various methods we call “passkeys” aren’t portable?
Generally, if you want to restrict the user to use a particular authenticator, you need to own that authenticator. At that point you can have the attestation you are looking for. If you want Yubikey policy and behavior, you're gonna have to get your user a Yubikey.
The passkey provider vendors are motivated to serve their customer's needs (the end users, and secondarily enterprise deployments) over non-customer needs.
So Apple platform support (for example) will only send an attestation when one is configured via MDM. Your provisioned work device can indicate to work systems that it is in policy.
The compatibility-limiting risk, if it exists, is more likely from regulators putting their hands on the scale and pushing for security policies that would prevent synchronization and backup, and requiring attestations to make sure those policies are in effect.
Most "Passkey" branded approaches are portable. The "not portable" subset of Passkeys is primarily backwards compatibility with things like Yubikeys. That's also what attestation is mostly for, backwards compatibility with applications and Enterprises that still need "this is specifically the physical Yubikey I mailed this user" type keys, not as much Passkeys.
But can you use Apple Password app on an Android device?
I'm not saying it's impossible, I'm saying there's a barrier that's useful to further vendor lock in. My mom is going to use Apple passwords on her iPhone. When she needs a new phone, the complexity of import/export and fear of losing access to her accounts is going to push her to buying another iPhone. It's just another avenue of lock in, like existing OS level password managers, just with an extra level of confusion for the end user.
My dad didn't like iCloud Passwords because he still uses a Windows laptop and only recently has the iCloud Passwords app been good or all that useful. We settled on 1Password a few years ago and having 1Password on his phone and setup as his default password app means that iOS uses it as the default Passkey app as well. "It just works."
The vendors could use it to enhance lock in, but for the most part the vendors all seem in agreement that the rising tide safety to float all boats of Passkeys is worth investing in making them friendly, especially to non-technical users, and to some extent try to avoid direct lock-in.
If that's the argument, it's bull. If you use Apple hardware, you're not locked in and required to use Apple's default Passwords manager.
Microsoft Authenticator, Bitwarden, 1Password, etc. all support storing passkeys and support multiple hardware platforms.
It's no different than making your own decision on which password manager you want to use.
brother I locked myself in long before the passkey showed up
I mean yeah, customer lock in has been Apple's business model for a long ass time, that's not surprising.
Mostly, though, it is not true lock-in, as in they mostly don't force you to do things their way. They encourage it, make the features pretty seamless to use, etc, so that you want to stay in their system, but they generally permit you to use whatever tools you want.
On an iPad/iPhone, you are not allowed to install apps not approved by Apple.
Oh shit really?
Agreed, it's the bare minimum to keep them out of trouble usually.
The fact that the password manager someone might use on another system is a complete piece of crap does not mean passkeys are an Apple lock-in attempt.
There are an open standard. You just have terrible software.
My issue isn't with the standard, but if all implementations lead to the same shitty experience of 3 different apps begging to store and use my passkeys, then something isn't working right. In my case, the terrible software is Apple's Mac OS, Google's Chrome and/or Firefox, and sometimes Bitwarden still acting weird. Lets not even get into how wild Windows acts when a passkey shows up.
Saying it's an open standard, and that it's just all the major players I'm forced to interact with that make it suck isn't very helpful. That's like the people that say "Don't like iOS? Build your own successful mobile OS lol"
I’m not saying built your own mobile OS.
I’m sorry you have multiple pieces of software that want to be in charge, but aren’t passwords the same? Because Chrome and Firefox both want me to use them for my passwords. It’s not a problem unique to Passkeys.
It’s just everyone ignoring user preferences to try to score stickiness.
As the previous article says, some passkeys are open, while others require lock-in, and megacorporations deliberately create confusion between the two.
What lock in? The attention this article debunks and no one uses?
Microslop uses it. If you want to login to a corporate Microslop account with a passkey, you have to use Microslop software.
That question has been answered multiple times here.
As a Bitwarden (and Vaultwarden) user on Mac/iOS/Safari, Linux/Firefox and Android I have had zero issues with passkeys since I started using them a few years ago.
The first two accounts I switched over to passkeys were my Nintendo and Playstation Accounts as it made sign-in much smoother.
I now use passkeys pretty much everywhere I have the option (at least on high value accounts such as Amazon) and I have not once had an issue. Not having to use a TOTP (or worse an SMS or email based one use code/link!) is much nicer in my personal opinion.
Some sites have a much better designed on-boarding process than others I 100% agree there. I find the sites that do a poor job with their passkey enrolment are the same sites that also did a terrible job of 2FA/MFA setup as well though.
One blessing with passkeys is since I set it up for my mother with her Amazon account she has not once had to ask me to help me reset her password. At least once every 6 months I would have to help her sort things our as she would forget it, reset it and then forget what she reset it to and can't reset it again as she hadn't clicked to update the password in her password manager so it had an old or incorrect password, etc. Always a pain to sort out. Not happened once since switching her to a passkey which is wonderful for me.
Also it is essentially impossible for her to use the passkey on a fake site. Multiple times she has fallen for phishing emails with realistic looking site logins and she would just blindly enter her username and password as many elderly people do.
Both of my systems are apple, one has a Work Apple account and one has a Home apple account. How do I log into website X with 1 identity WITH FIREFOX? (people are going to jump through hoops when they find out my work laptop blocks mozilla services when I can just use a TOTP token on my phone and everything works.)
I think Firefox had system integration with the password/passkey provider framework since 122.
If you do not have access to your personal Apple account on your work laptop, you would need to find some other passkey provider with native integration.
Under Settings > Privacy and Security, look to see that Firefox is listed and has access under "Passkeys access for Web Browsers". Unlike a native app which only needs passkeys for its own services, Firefox needs access for every potential service you might hit over the internet.
Then under General -> Autofill and Passwords, you'll see any apps which are registered as system password managers. Unfortunately this is a subset of the ones which register on iOS and I'm not familiar who has done integration yet in their Mac release - Chrome (with GPM) for instance is not listed even though it is available on iOS.
I use 1Password to sync all my passkeys between iPhone, Mac, and Windows. It works exceptionally well!
Same here. My only nitpick is that I have to carefully go through the various machines and browsers, etc, and ensure that only 1Password is ever consulted for password storage.
>Thankfully, for folks all in on the Apple ecosystem, it should be pretty decent of an experience.
How many people are for now and forever more all in on the Apple ecosystem. You never have to login on another non Apple device ever?
This describes most non-techy people I know who are 20~ years older than me (unless they're 40+ years older than me and only using a laptop to check their email).
Step away from HN, and there are probably a lot of people who only use their phone to access the Internet. Smartphone brand loyalty seems to be strong, too.
But you can’t simply switch to Android without recreating every single passkey. Sounds like vendor lock-in to me
> But you can’t simply switch to Android without recreating every single passkey. Sounds like vendor lock-in to me
Not so fast. Migrating passkeys from iOS to Android is possible now; migrating from Android to iOS is still being worked on.
Ricky Mondello's team at Apple created the Passwords app which brought passkeys to iOS, macOS, etc.
The entire presentation is worth watching if you’re interested in passkeys; the the clip below starts at 24:00 mark where they talk about migrating between platforms.
The FIDO Alliance created a specification in 2024 called Credential Exchange Format [2] for moving credentials including passkeys, between passkey managers on the same device and across platforms.In other words, being able to move passkeys between devices and platforms has always been part of the plan.
[1]: https://youtu.be/yVadD-Lfrfk?t=1454
[2]: https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-2026030...
Yes you can. You can export your passkeys and then import them into whatever android password manager, or 1Password.
I was under the impression that most credential managers won't allow you to export a passkey to a plain text format, but will only allow limited app-to-app transfer of keys (with a limited selection of compatible apps only)
I want to import them in Android nit another app and you can export to an Android app only to another app on your iPhone
Well designed platforms and auth frameworks allow adding multiple passkeys. The problem is this requirement was never coded into the passkey standard.
That still requires recreating every passkey, even if both can exist at once. If I want 50 sites to use a passkey on macOS and Linux, I need to go through the setup process 100 times, and all 50 sites will likely handle it slightly differently.
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.
Still amazed that on HN of all places people are confused by or having problems with passkeys. I have yet to see any of the issues people are guesstimating could become problems and adopted on day one.
I have had two poor experiences, where passkeys I set up at one point stopped working and I had to generate a replacement, but this was not a problem because I have yet to come across a site that didn’t continue to offer other means of logins.
I don’t see anybody complaining about the login-via-emailed-link which seems to be the much more common trend these days and which I really dislike because it introduces an unwanted delay in login (and I have come across many sites for which this is the only means of logging in).
So far, I've had a hard time setting up an iCloud passkey on desktop Windows. Windows Hello keeps intercepting most attempts at a passkey, and 1Password will usually step in otherwise. The UX around it continues to be baffling to me.
At least there's a dedicated migration protocol for passkeys, but I'm not super stoked about how basic Apple's password management is, and how few fields there are for each profile.
But I also feel like it's time to retire my YubiKeys ...
> But I also feel like it's time to retire my YubiKeys ...
Why, specifically?
You act as if the experience on Windows is the point of Apple's password manager. I'm not surprised the experience is pretty bad -- as far as I can tell, accessing the passwords and notes is pretty much the only thing you can really do on Windows, and the user experience is significantly impaired compared to Apple devices.
(For example, it only stores the passwords in memory and never persists them locally in any form, because there's no way to secure that, so it has to redownload them from scratch every time you open the app. It also only supports proper Windows Hello PINs rather than normal account passwords, because that's the only way to get proper hardware backed cryptography locked behind authentication, etc. It's a mess)
This, I've been an engineer for 25 years and I hate passkeys. I have a work laptop and a home laptop and I connect to some websites from both and I... it's just a mess.
Same. Fully agreed.
New and interesting ways to get locked out of your system.
> Why are passkeys better?
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 if the website loses its domain? There are plenty of examples of dickish domain registries and registrars, domain holders getting phished, etc. How do you reset it to the new domain?
Allow email resets in the case of a lost domain. You could disable them in normal operation but in this case, any users with passkeys from the old domain can enroll a new one via email.
Sites should support multiple passkeys, and allow you to select between them if more than one are available.
I've seen this work on both Windows and iOS, where I have sites set up to use passkeys from multiple sources (Yubikey, Windows Hello, Apple Passwords, Microsoft Authenticator app), but I've also seen it not work, so there must be something the site has to do to make this possible.
Also consider the case where you use Google password manager and your Google account gets locked for any (or no) reason. It's unclear whether you can even still use your passkeys, much less migrate them away.
I agree and I have a good example.
At my work we are forced to use passkeys internally and it's fine with me.
At some point in the past, due to the constant nagging I set up a passkey on my GitHub account.
I needed to sign in to work's GitHub account, so unknowingly (since there's no SSO option there) I just clicked on "Sign in with a pass key". It didn't ask for my username, just gave me an option to scan QR code. And I did because work's pass key is set up on my personal phone. Then I noticed that it's trying to sign in with my personal GitHub account. It's good that I don't have anything sensitive on there but I really wouldn't want to sign in on my personal account on my work's laptop.
> 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.
This is the same problem we've had for 20 years with password managers, though.
The solutions are mostly the same as well (with the change to a QR + BLE based mechanism over manual transcription to go cross-device, and a protocol to support moving passwords and passkeys over to different software rather than using a plaintext password CSV export).
Many password managers also manage passkeys (and were managing TOTP before).
A password is not like this because a password is a simple keyboard input by default. It only becomes a password manager if you make the active choice to install a password manager, and then it's your fault if you don't grok your own chosen password manager. Passkeys use something password-manager-esque out of the box, so they have this problem.
They give me OpenID vibes, and non-tech people can't understand what they are.
Heck, as an engineer even I don't get them. What ever happened to password + yubikey?
TOTPs are already not that great in my opinion. It's like democracy: the least bad option. It's a decent trade-off between convenience and security, so I'll stick to unless there are good reasons not to. Passkeys have managed to make that experience worse, with a very large potential gotcha in the future, while not introducing any improved security I see why I should care about.
I've had nothing but bad experiences with TOTP. Mostly involving dead phones and having to find the backup codes.
You can back up the TOTP secrets to add another layer of protection. I haven't needed to restore from backup yet, but I'm pretty confident that failure mode won't be a problem outside the immediate timeframe my phone happens to die.
> What happens when I go to the same site on a different platform?
You click the "log in with QR code" button, scan the QR code, and authenticate using your phone.
Unfortunately that only works from phone (and watch) to computer. If you don't have the passkey available, you click "forgot password" and set a new one, same as with a password.
You can use it computer to computer, too, as long as the laptop has a camera to read QR codes.
In theory phones and watches could implement the other direction and generate the QR codes, there's just less pressure on the ecosystems to make that easy to do so it's not there in practice today.
That's part of the horrible experience I hate. why should I have to have my phone to login on my computer.
You only do it if you want to. You can put your passkey in keepassxc or 1password or bitwarden or google's password vault or any other cross-platform passkey platform.
It's only a problem if you pick a platform that locks you out, even then there's workarounds. It's not a replacement for logging in every day, it's more a replacement for typing over the 64 character random password from your phone's password manager on the library computer.
It's easy to install Chrome on most devices and even iCloud Passwords has an okayish and getting better Windows app today that works in supported browsers. (It would be nice if it also acted as a Windows-wide plugin for Passkeys, but it doesn't yet today.)
It almost seems like instead of passkeys in their current state we just need SSH keys but with added website verification.
Passkeys in their current state essentially are just SSH keys with added website verification.
A lot of the "slippery slope" confusion in the past couple of articles has been that this "cheap SSH key" approach was built on top of the same standard for "expensive hardware key" (Webauthn). This is great because it means a rich backwards compatibility story across a long history of devices and "expensive hardware key" remains an option for Passkeys. This is unfortunately confusing because Enterprises still need Webauthn for "only expensive hardware key" usage so need options in the standard like "Attestation" which specifies things like "exactly which expensive hardware key vendor was used".
People see this confusion and think it leads to a slippery slope of attestation being required "in the future", but the reality is more that attestation and things like it were required in the past and are optional now because we realize "cheap SSH keys" are good enough for most users (with some standardization and shared "branding").
Except that in almost all implementations passkeys can't be extracted or copied, unlike ssh keys. Great for enterprise, terrible for home use.
In best practices for SSH keys you should be using different keys on every device and shouldn't be extracting/copying them. Best practices are also to use different keys for every SSH host in addition to per-device keys.
Passkeys enforcing keys not be extracted/copyed as plaintext and that keys are per-host/domain are just following ancient SSH best practices.
Because yes the SSH world is sloppy with dangerous plaintext (or modest password encrypted) key copying and reuse. That does make it a "simpler" ecosystem, but that doesn't make it a better ecosystem.
That said, Passkeys generally are frequently copied, most of the ecosystems support multi-device sync and backup. They just aren't done in a way that provide plaintext export if you want to print a book of your Passkeys and store it in a safe deposit box or sloppily `scp` them from one machine to another.
I think the core problem is they’re called passkeys and evangelized as a replacement for passwords, which makes people think they’re like passwords or like keys—secrets we’re responsible for not losing—whereas actually they’re like session cookies. They’re a fast path in that you’re meant to be able to create, delete, and even clear all of at will, with no penalty but that you’ll have a fussier login next time. They sure do suck as an only way in, they’re not even meant to be able to do that.
Passkeys only make sense if every user has a open source Fido 2 hardware based USB passkey (like yubikey but opensource).
Then the user still controls the passkey using a password and then everything else flows from that.
Passkeys only make sense if multiple passkeys are supported. What if I lose my Fido key? One issue here is that passkeys don’t have a clear role. If they are replacing passwords, only, then they are 100% an improvement even when not hardware backed, but you still need 2fa. If they are hardware backed, you probably don’t need a second factor and different sites see different roles. Assuming I can setup a backup key, hardware backed covers all of sites’ misconceptions, though.
A few examples here to illustrate... The way ebay and Amazon handle this are great. Multiple passkeys allow login of multiple device ecosystems and/or hardware tokens so that users can mange their own level of risk and really any level of implementation is helps the average person.
Meta's implementation by contrast is bad, in my opinion. You are only allowed one passkey (so one login ecosystem/hardware key allowed) and it completely bypasses 2fa and security tokens. So, someone looking for more security must avoid passkeys "altogeher" and use password + U2f security key and the passkey only being allowed in a single ecosystem means that password/phishing lanes must remain open. All you're doing is disabling 2fa on a key that is likely sync'd to all of your devices. All that said...it may still be a security improvement for most users in the real world in practice, I just find it a very annoying and confusing set of security decisions.
The primary reason 2FA exists is because passwords are phishable. If you remove passwords, the need for 2FA largely disappears.
2FA exists because defense in depth. Even if passwords weren't phishable, it can still be handy to defense in depth that a person is who they say they are by checking multiple factors ("something you know", "something you are", "something you have").
Passkeys largely meet 2FA requirements by themselves because they are "something you have" (its stored on a device you own) and require "something you know" (device PIN) or "something you are" (biometric unlock) to use.
It moves the attack surface to password managers, which is arguably a better situation than phishing. I'm skeptical that the war is over, though. I have no proof to back this up as phishing is the low-hanging fruit today, so the numbers 'largely' back you up. I personally include device compromise in my threat model and I'll concede that may be overdoing it for the average person.
> it could end up going to Google password manager, Samsung passWord manager, iCloud Keychain, or Windows Somethingorother.
Using all that is just asking for trouble. Turn all off except one.
Yeah, there needs to be a way to link password managers to share passkeys, and also to share passkeys between people. There are also a lot of great features that could be implemented with passkey sharing too, like revocation, time limits, or capability limits.
Adding the kind of sharing it sounds like you are describing would just shift the attacks to that new attack surface. The attackers would basically try to trigger and intercept those shares.
If machines, browsers, phones etc are set up properly (yes, I know, big ask, especially with the confusion surrounding this, so I acknowledge the caveat), then the vast majority of passkey requests will go right into the preferred method (i.e. 1Password, Bitwarden, even Apple, browser of choice, etc). And most of those now will allow that passkey then to be used on a different device if signed in and synced.
I have found it to work pretty well with a password manager. I would suspect OS level passkeys would be much less "portable", especially across different manufacturer devices, like Mac/Windows, or even Windows/Android, etc. Which is why I waited to start using passkeys until I could use a password manager to store them, and I turned off all other passkey storages (same as I did for password storage before).
Obviously any new feature in a password manager is a new attack surface. That doesn't mean we should never add new features to password managers.
If we don't add decent sharing to passkeys then people will continue to use passwords, which is worse for security than adding a properly designed sharing feature for passkeys.
Bitwarden[0] can store and supply passkeys (and passwords of course) across macOS, iOS, Windows and linux seamlessly.
[0]https://bitwarden.com/
Only if the website allows you to use Bitwarden for the passkey.
Outside of a corporate Microsoft Entra login policy, I'm not aware of Bitwarden passkeys being widely denied in practice.
The fact that it's even possible is a huge problem.
The internet is built on possibilities and sustained through consensus. Don't let perfect be the enemy of the good.
This is more an indictment of the current state of password managers and the tension between them at OS-level and browser level
I don't think I have seen a case where using a passkey stops me from using my password on another device/platform that doesn't have access to the passkey.
That's because we are still in the "barely lukewarm" stages of boiling the frog
Maybe, but ultimately a website/service wants active users, and making it too hard to log in from different platforms or reset your auth and get back in is not going to get them more users or better user retention.
Only true when the service needs you more than you need it.
It's not even clear what happens with Google Password Manager. It might go into your Google account or your local device. I somehow ended up with a mix of both.
TOTP is phishable. The push to get away from TOTP is driven by phishing.
I've done authentication projects for financial institutions that were actively targeted by phishing attacks, and it is difficult to mitigate TOTP phishing. Defeating TOTP is very much in the standard playbook for high-dollar scam operations.
The objection here isn't to something that uses public keys instead of TOTP. It's that they added support for remote attestation to passkeys, which an enormous red flag and enables That Which Is To Be Prevented, i.e. permanently entrenching the incumbents because many third parties won't support new device makers with no user adoption yet and users won't adopt a device that won't work with many third party services.
Moreover, the large majority of ordinary people are going to use whatever comes with their phone anyway, which can then lock the key in the device's secure processor by default independent of remote attestation. So then it's not getting you anything for those people and the primary thing it does is to impede Linux Girl from using Linux and anyone new from ever trying to create a competing mobile platform or even a usable non-Google fork of Android.
The obvious way to satisfy people is to remove support for remote attestation from the spec.
> The obvious way to satisfy people is to remove support for remote attestation from the spec.
If you presume bad faith on the part of basically the entire WebAuthn implementer community, how does this help?
The consumer passkey authenticator implementations of today do not provide attestations, passkey relying parties do not consume them, and both would need to intentionally ship changes to enact the scenario you're worried about. If you're worried about both of these colluding to lock you out of your accounts, it seems naive to think that changes to an (intentionally malleable, extensible) spec will protect you.
All the rest of this argument just misses me. Whatever the non-phishable authentication you want to use is, that's fine by me. But TOTP is phishable, eminently so, so you're not going to see security people back down from deprecating it.
Then they need to advance an alternative that doesn't support remote attestation.
I think the arguments about attestation are bogus for all the reasons everyone else is pointing out but that doesn't matter because I'm not talking about Passkeys, I'm talking about why TOTP is a dead letter. You're not going to get security people to back down on deprecating TOTP, because it's phishable, and the point of modern authentication protocols is defeat that attack.
By all means, keep lobbying against Passkeys! I don't care. But you'd be shooting yourself in the foot rhetorically to build TOTP into your case, as the comment I replied to originally just did.
>What happens when I go to the same site on a different platform?
Scan the QR code with your phone.
>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?
Most devices today ship with Bluetooth and even locked down machines support using your personal phone to authenticate.
>What if I want to consolidate them all in one platform just for the sake of being organised?
Then do that. Use whatever your phone uses.
>What if I lose or simply don't have the device with a certain passkey near me?
Then you will need to use a fallback authentication mechanism or will need to wait until you can get the device. TOTPs have the same issue.
Every time I've used a passkey with a site was in addition to the regular user password. So like a cached auth saved in the phone secure storage, protected by my PIN/fingerpring.
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.
Security matters, users who want choice have to take responsibility, users that don't can just use Apple.
"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"
That it’s possible to know the answers to these questions doesn’t mean the system is good. This is a level of complexity that most people simply do not have the time or bandwidth for.
Most people don't have time for the level of complexity of a password manager in general and just use one hunter3 level password for everything.
>>users who want choice have to take responsibility, users that don't can just use Apple
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 to the people who will actually use it.
EDIT: add last 8 words
"...if attestation is the thing you're worried about, the post's own recommendation pushes you towards attestation rather than away from it!"
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.
> 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.
Remote 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.
Attestation is to your advantage if your phone gets rooted/hacked (evil maid attack). It will let you know that something is wrong when you try to login into an attested site.
Like SecureBoot.
That should be up to my phone then. Unlockable phones display a mandatory warning screen on power on if they've been unlocked - isn't that sufficient? Why should Facebook also be allowed to care?
We know users blow past any warnings, even if it is in big, bold, red letters stating that they were hacked and should not continue.
Plus why should I be inconvenienced by not being able to watch my TikToks if my phone was hacked? On the other hand, I expect my important apps to apply a higher level of validation before they accept random inputs.
never, ever in my life I've seen SecureBoot doing anything ever remotely advantageous for me.
> In a 2009 blog post, security analyst Joanna Rutkowska coined the term "Evil Maid Attack" due to hotel rooms being a common place where devices are left unattended.[1][2] Rutkowska then published a practical method for bypassing TrueCrypt disk encryption on victim devices, requiring merely an external USB flash drive.[3]
I hope the situation with disk encryption has improved. Otherwise, what is even the point of it? Any local malware you get is going to get an unencrypted view of the disk anyway (just like your legitimate programs) and there is already something seriously wrong if someone manages a remote login on a random home desktop that wasn't specifically configured for it.
Then you just entered your unlock code / password into the compromised device which immediately transmits it to the attacker who has your real device.
On top of that, secure boot doesn't require remote attestation. If your device doesn't like the new configuration then it doesn't release the key. The site has nothing to do with that except insofar as you need the key to sign into it. Your device manufacturer's key doesn't have to sign anything, all your device has to do is not give up your key unless the device is in the configuration you specified. And if it will do that then it would also sign an attestation to the same effect, so remote attestation still provides you with no advantage whatsoever.
Maybe I'm misreading, but that was my point - an app roots your phone but doesn't reboot yet, resets SecureBoot to the new configuration so it's accepted on reboot, triggers a PIN screen to re-seal user secrets, but it will now fail attestation since it's hashes will be non-recognized.
the reality is that evil maid attacks, and more broadly (and realistically) physical access attacks are exceedingly rare. The vast majority of stolen credentials are phished or some other social-engineering trick, not James Bond sneaking in with his badusb.
It was inconceivable to crypto bro’s that kidnapping people for their keys was a possibility…
If banks make it a requirement you use certain pre approved devices, you better believe badusb/physical theft will take place more commonly and it will definitely not be someone as polite as James.
Yeah this article is confusing for me. The one a few days ago was basically saying "this is a slippery slope", which the post today acknowledges, then goes on to say "These passkeys don't give websites an attestation statement at all, and though a site can ask, what comes back is none" as though it invalidates the post a few days ago.
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.
Then multiply that ritual across the dozens of apps and sites you're forced to use a day...
It is genuinely an ordeal.
I also get generic errors trying to check out, not exaggerating, like 25% of the time on anything that isn't amazon. I think Firefox and resisting fingerprinting and VPN together means places really don't want my money. I know fraud prevention etc etc, but I can still be annoyed at the state of the internet.
This blog post is the perfect example of someone rationalizing away the bigger picture.
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.
When my state introduced seatbelt laws they assured the public that they would only be a secondary offense, never the primary basis for getting pulled over and issued a ticket.
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.
The arguments of they never "usually" do this, or "the guidance says" are meaningless. Whatever can be used for control, will be.
And every time you point it out, some useful idiot will say "you're making the slippery slope fallacy."
I think it's more that attestation can require a specific "approved" authenticator, and that authenticator is what would enforce all of the required OS/Software/Hardware requirements, even if it didn't get included in the attestation standard.
That's a good thing?
Most consumer websites won't use attestation.
Places where additional security is required (bank, employer, etc) can.
Most consumer websites won't demand you share a scan of your face to third parties, until they do. Same exact thing will happen with passkeys, guaranteed.
Exactly how http was the standard for normal websites and banks et. al. using https until, everyone was.
Now that was a good thing with https, not so much with passkeys until Chrome pushes through a change and says they'll only accept attested passkeys issued by their own google password manager/authenticator.
Access is a good thing too. I don’t want hardware attestation, i want to be able to access my bank from anywhere. Banks continually push their liability for security onto customers.
> Banks continually push their liability for security onto customers.
Bank customers: "You don't need to know anything about me."
Also bank customers: "You need to stop anyone who is not me from accessing my money."
People who are more tech libertarian don't like when critical aspects of their life requires a smart phone from either Apple or Google. The ability to avoid these companies is becoming increasingly difficult, and attestation is one piece of that puzzle.
I don't think that means throwing out passkeys entirely, but that's why you're seeing a lot of "slippery slope" stuff in here
Well those people can buy a YubiKey for $30 I guess. I don't see why that's a big issue.
The line of thinking, I guess, is that you shouldn't be forced to buy a specific companies device just to access your own money. And in 10 years time, the companies approved to make devices like this will be DisneyAppleFlix and TeslOpenAI.
That's my guess, at least. I know next to nothing about attestation and passkeys.
And passwords could easily be extended to requiring photo ID...
No, they can't. You could try ro replace passwords on your service with some stupid id verification scheme, but you have not extended passwords.
This is not true.
How? It wouldn't be easy at all it would be totally unconventional and break all sorts of expected workflows for passwords if you had to take a photo every time. For example at my work we have a ton of computers and none of them have webcams.
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.
and your bank can't force a certain client for a password if they decide to? or that you need to drink a confirmation can? or whatever arbitrary technical constraints they want to do in general?
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.
They effectively can't to the extent that it's not a social norm to enforce that level of security theater. You are arguing in favor of normalizing an increased degree of security theater.
My point here is that this specific step on the slippery slope is a cliff, not some infintessimal change, because now the authentication is done through a program and not copyable information. If verification-can technology is standardized on an OS level and advocated by four out of five tech priests (and maybe even enshrined in law (think of the children)), then you are going to be drinking a whole lot more mountain dew in the future to say the least.
If it was just a single bank or something that tried this, people would get pissed off, leave, and the frog would not be boiled. It takes a slow industry-wide movement to shift the standards of what is acceptible to the common man.
Do not handover your identity, or verification of it (as the current case is) to anyone else, irrespective of the benefits, including the security aspect.
---
The author has strong incentives for the success of passkeys.
1. Scott Helme is founder and CEO of Report URI, and Companies House records his ownership at over 25% and up to 50%. Report URI markets a "Passkeys Protection" offering, giving him a commercial interest in services for passkey adopters.
2. His WhyNoPasskeys.com campaign pushes websites to adopt passkeys, is sponsored by Report URI, and promotes its passkey protection services. The "Passkeys Are Not a Trap" article also carries a Report URI sponsor banner.
3. Troy Hunt, Helme’s Report URI business partner and investor, joined 1Password’s advisory board in 2020; Helme has also appeared in Hunt’s 1Password-sponsored content. That establishes an indirect vendor connection.
Virtually every authority on passkeys is going to have an industry connection. Just like how most climate change authorities receive funding to do climate research, how SEC investigators typically have backgrounds in banking, open source military analysts are veterans, etc.
It's not because people are bought by the powers that be, it's the way the world works. People enter the fields they have expertise in.
The guy literally owns a business in this space and has a huge financial incentive to push passkey adoption. Technically he has an "industry connection" just like millions of other people who work in tech and happen to know about passkeys through other work, but conflating the two is wildly misleading. His perspective is as far away from unbiased as possible.
Research funding is hardly perfect, but most of the people studying climate change are doing actual research and trying to draw evidence based conclusions that hold up under peer review. Their incentives are not the same as a tech founder who could potentially make generational wealth if one particular outcome is realized.
Thank you!
> 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.
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.
Apple does not support Passkey attestation on consumer devices. They've said between user privacy concerns and user experience concerns (syncing and backup are critical requirements to non-technical users) they will not support attestation on consumer passkeys. They worked through the standards process to push compromise standards that are not attested but help with some of the "compliance issues" that might have come to require consumer passkey attestation (these are the uvi and uvm extensions which are not attested and essentially are "I solemnly swear a biometric unlock was used to access this key" for basic 2FA/MFA CYA).
So the "biggest providers" very much have some champions against attestation.
"Password manager you trust..."
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.
The idea of keeping my passwords in my work-sponsored password manager just sounds absurd. Who thinks that's a good idea? What happens when you leave the job?
My workplace doesn't offer this, but I like the idea of how 1Password does it. If your workplace has a business account with 1Password, each of the business users gets a personal account for free. If you change jobs you can pay for your own account, but it isn't tied to the company account other than getting it for free with the corporate account.
Pretty much all the major vendors offer this now.
Ah that makes this make way more sense. Thanks for the insight.
I personally find it to be a disgusting way to get customers. The company pays for the service, yet they also get to be the product.
Depends on how you look at it I guess.
What I did was use usernames on those services that included a few chars to remind me which business I'd created it for. I was a software engineer bug changed jobs/contracts on average about once per year (that's a very, very rough average though).
it's work-owned or work-managed accounts that get stored in a work-sponsored password manager.
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.
exactly, it sounds more like a trap with the facade of benefit than passkey
Are you not keeping them separate? Are you using browser profiles?
It should be a default then not a suggestion we pass around in tech forums.
eh the companies account for that. for example 1password basically gives you a "free" extra personal account if you enroll into a work account. and when you leave, you just keep the personal account.
"free" because im not sure if your employer pays for it or if its like a free benefit to a bussiness licence
I deployed it for our company, I can confirm for you that as of this post, the personal account is a free benefit to the business license.
What you describe is a different attack surface than the much more problematic on that password managers solve well: password re-use across websites where the blast radius is super high.
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.
I think this part is where TOTP's 2FA/MFA model is "safer": you do not need to trust the TOTP manager. Even if the app sends all your TOTP secret keys to the server, they cannot hack your account because your password is stored elsewhere, and TOTP code alone is useless.
which password manager were you using that it got hacked?
Not GP, but I've seen this happen a few times with $work managed password managers. From memory and in no particular order, the reasons for the breach were:
- 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.
These examples are very different than your provider being hacked.
Ideally you should be isolating your passwords across the company so that one user doesn’t compromise every login, no?
> These examples are very different than your provider being hacked.
I am not GP. GP said:
> I say "no thanks, they're going to get hacked" and then six months later... they get hacked.
I interpreted that to mean "they (the passwords) were compromised" not necessarily "they (the password vault provider) were compromised".
> you should be isolating your passwords across the company so that one user doesn’t compromise every login, no?
Correct.
GP here:
(1) The use case I have seen is that a startup or small unit in a big organization has subscriptions to a number of services that are shared by multiple users; if I had to log into one of these things I would log into the password manager and use the username and password that we all share -- these have never been things that I use for my day and day out software development but usually are things the marketing people use that I only have to log into every six months or so if I have to help out with a problem. I've always had individual accounts for bread and butter services such as version control, issue tracking, documentation management and such.
Of course the right thing to do is give members of an organization their own username and password or integrate with the enterprise SSO of that organization... And that's a lot of what I do for work! Many vendors don't support that or jack up prices 10x or more per seat for SSO, so shared username/passwords are widespread.
(2) "they got hacked" means "I read about an incident in the media". Probably some security boundaries were breached and others weren't. I don't think any of these were the worst case scenario of "100% of passwords got leaked". I wasn't personally effected because I didn't take the bait, I either had moved on to another job or somebody else cleaned up any mess so I don't know exactly how my organizations were affected. Still it proved my intuition (gotten from looking at a lot of software and working on user management for numerous web sites, some famous) that these password managers were not paragons of operational excellence.
Probably LastPass
Yes!
They also didn't specify whether this is on-prem or cloud. Big dif why a 'hack' can occur...
Last pass. Twice iirc.
KeepassXC now supports passkeys as well.
Aren't password managers like Bitwarden essentially zero trust? Even if they hacked the entire database, what would they do with that?
The author is really missing the forest for the trees here
> 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.
The next paragraph states that Yubikeys are a registered authenticator. Yubikeys are platform-agnostic.
A closed-firmware USB key is really no better option.
Dear Yubico / Kensington / Google Titan, can I export my private key components to this other device, or even print them out on paper for storage?
No - you're just an untrustworthy user granted the fleeting privilege of using BigCorp devices. Now stop asking such questions or you might have your attestation revoked.
The issue is that operators can just curate a whitelist of authenticators they like. They could opt to not allow Yubikeys if they wanted.
> [Attestation] say nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
Largely false. The Pixel verifies the OS and will reveal `verifiedBootState != Verified` on GrapheneOS in the attested passkey at registration, which websites may choose to reject. Apple Silicon has an undocumented SEP which prevents Asahi Linux from accessing it. There may be other examples now or in the future.
Also, I think you can deduce the device color from [1] on Android.
So, in conclusion: https://storage.ghost.io/c/ee/88/ee889f88-37ef-43e5-9180-f9b...
[1] https://source.android.com/docs/security/features/keystore/a...
So: currently, the cauldron is cold, therefore ignore the fire below it and hop right in.
The cauldron is already warm. I encourage people to read these issue trackers.
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
https://github.com/keepassxreboot/keepassxc/issues/10406
"The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. 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)."
"This implementation is not spec compliant and has the potential to be blocked by relying parties."
Proponents keep trying to hand wave away the attestation lock-in problem as some vague faraway threat that we may never encounter. It isn't. It's the actual plan.
These links should be a mandatory reading in every passkey-related discussion.
These are very damning. Pretty straightforward about removing all software freedoms in favour of some sense of security. It really is already happening:
> I have a sneaky suspicion that some of our failures with various RP's is because they are only accepting certain authenticator GUIDs.
This comment from the KeepassXC maintainer makes me feel like the whole spec is already completely flawed if such a situation is even possible.
Just make sure you trust the cauldron you choose.
> 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.
Practical experience from Austria where attestation is used to limit which hardware tokens can be used for the EU digital identity: it sucks. You're limited to a very limited number of keys: https://www.id-austria.gv.at/de/hilfe/hilfe-zu-ida/authentif...
Now: will more people do this? I don't know. But I fault the standard for enabling it in the first place.
> it sucks
Exactly. From the page about the requirements for the app under 1) in your link:
> System requirements
> Android 12 or iOS 16
So one of four methods is, by default, already completely dependent on having an account with $american_megacorp.
4) is another app where it doesn’t outright say, but I’m guessing the requirements are also a mainstream OS, mobile at that as well since they seem to use biometrics.
That leaves 2) dedicated hardware and 3) dedicated hardware. Great. (see the “my house burned down” article/thought experiment as to why I’m against that.)
I think the passkey standard included attestation for good reasons, but it is obviously also possibly a trap in the sense that I'm sure there were some people on the standards committee(s) envisioning a glorious world where they can flip this on for everyone and instantly all the bad stuff stops.
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. There is no way around the fact that strict attestation implies more user responsibility to make sure they don't lose their token, and at scale, they absolutely will. Work environments can get away with this because work environments have a scalable mechanism to re-verify identity to the extent the business cares about it personally, and reissue tokens. At scale the big companies do not have this for individuals. You can't use hardware attestation without this infrastructure for reverification, and any infrastructure for reverification a large corporation tries to create will have exploitable holes in it.
> there were some people on the standards committee(s) envisioning a glorious world where they can flip this on for everyone and instantly all the bad stuff stops.
Why the past tense? Here's a list of FIDO Alliance board members: https://en.wikipedia.org/wiki/FIDO_Alliance#FIDO_members. I would love a spreadsheet with their positions on remote attestation - let's start with the banks.
I still don't use passkeys because I don't know what advantage it has over my existing method of generating random passwords in my passport manager and using that. My password manager generally autofills it anyway.
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?
>What would I gain from using a passkey?
The number one gain I see with passkeys is that they are phishing resistant. The biggest issue I've had with TOTP keys is they aren't phishing resistant.
Forcing people to use passkeys gives the authentication layer a stronger means to ensure that people are logging into the correct domain. A password manager accomplishes this, but it's very difficult to enforce. (I've heard a number of variants of "John Smith sent me an important document and when I went to open it, the password manager didn't work so I just copied password")
I’ve seen tech-savvy people getting phished into entering their password on a fraudulent site, despite the password manager blaring alarms that the login looked fishy.
This cannot happen with passkeys at all because crypto magic.
I assume a phishing site wouldn't even attempt to use the passkey because it can't. So wouldn't it just ask for a password, and at that point, if you're gonna fall for it, you'd go and grab the actual text password anyway?
My password manager matches off of domains too, so it wouldn't suggest to autofill on a phishing site.
Right. It didn’t suggest it but the phishing message was convincing enough that the tech-savvy person fished the password out manually and input it anyway. A mistake for sure, and one the password manager was trying to help with, for sure, but this mistake would have been impossible with a passkey.
> this mistake would have been impossible with a passkey.
But GP is saying that when the passkey is not auto-entered, the user will just use password-based login.
So the mistake will still happen even if passkeys are enabled and used, as long as password-based login remains as an option.
Right. The “correct” way for a service to handle this is to disable password logins for any account that has enrolled a passkey. A few services do this, but boy howdy is it ever unfriendly to users (or at best, difficult for them to get their heads around).
What's the difference between using a really good password vs. public key authentication in SSH?
> What would I gain from using a passkey?
The correct question is What did others gain?
- Phishing free press fingerprint or faceID or Windows Hello for login into many important sites
- many people don't have time to type password, then otp. If most of the world did that then this would not be needed.
- And finally, YOU are not OBLIGED to use it. Let the rest of population use it.
- It is like SOME pay with phone/NFC-Watch etc. MANY still use card or cash...
> And finally, YOU are not OBLIGED to use it. Let the rest of population use it.
They are.
Who forced you? Your employer?
No, the commenter is letting people use Passkeys. They didn't say anything about not letting other people use it, they just expressed why they don't find them useful.
You’d gain forced lock-in to client operating systems and hardware that someone else picks for you.
As far as I've read here before, device attestation is definitely there, it's just not being used (one of the big tech namely Apple is balking... maybe they have their own means or plans in their ecosystem).
My main reason for not using it is I'm not interested participating in a scheme where I do not own/access the private keys and being able to use them and store them the way I want to.
I'm fine with TOTP and sure, I understand it's not phishing resistant by itself.
Recent and related:
Passkeys are a trap - https://news.ycombinator.com/item?id=50048312 - Oct 2026 (571 comments)
Ricky Mondello responds to "Passkeys are a trap. Do not use them." - https://news.ycombinator.com/item?id=50061290 - Oct 2026 (14 comments)
I don't use passkeys but the thing that raised a red flag for me while reading the article that the OP is responding to is the "non-copyable" property. It's not possible to prohibit delegation[0], so the idea that a key can only be used on one specific device necessarily involves a form of DRM/wishful thinking.
[0] http://www.erights.org/elib/capability/delegations.html
The entire point of passkeys is to force DRM onto all corners of the web. It lets sites require attestation of the software running on the client device. Once they use that to eliminate hardware and operating system competition, they’ll ramp up surveillance and censorship even higher than current windows levels.
Passkeys are the second prong of the age verification push.
If you want more evidence, read up on Project 2025’s plans for forcing the internet to adhere to American Christian Nationalist values, then try to figure out how that could work in the absence of passkeys.
Yeah I think the OP is being naive about the risk here.
I do not think there is adequate reason to believe that FIDO Alliance members are supporters of Project 2025.
I think there are a number of people who mean well that aren't aware that they are creating the means for state control of computing.
Look, at best, Passkeys shift your logins from your head to OS-supplied keychain management. Whether they do attestation today or not, they big, industry-wide effort to move away from "what you know" (i.e. username/password) + "what you have" (2FA) towards "platform-authenticates-you-to-website automatically" has both security benefits and lock-in risks.
Maybe it was too strong to say the were a "trap", but it is also too strong to say there is no worries here.
> OS-supplied keychain management
That is your choice as the user. You can use the default credential manager that is offered out of box, or you can use your own.
https://whatarepasskeys.info
No, you can't just use whatever passkey manager that you want.
I use Safari, Chrome, MacOS, a Google Pixel phone, and 1Password. I have passkeys in 1Password, but it's a crap shoot if I'm able to login on a device.
Chrome wants me to use Google Password Manager. There's no option in chrome://settings to set 1Password as my passkey manager. If I try to use a passkey to login to GitHub Chrome pops up a modal that lets me choose between iCloud Keychain, Use a phone or tablet, or USB security key. There's no option to use a different credential manager.
Safari wants to use my iCloud Keychain. There's no option in MacOS Settings to set 1Password as my passkey manager. If I try to login to GitHub I get an option to Scan QR Code or Use Security key. There's no option to use a different credential manager.
My Pixel wants to use Google Password Manager. There *is* an option in Pixel Settings to set 1Password as my passkey manager, but it doesn't work in Chrome. All I can do it select "use another device" and it shows a QR code. There's no option to use a different credential manager.
Essentially every OS and browser thinks I want to use a phone for my passkey, and this is exactly the situation that I and everyone else is bothered by. I do not want to tie my login credentials to a phone that can be lost/stolen/bricked and will be replaced in several years.
So no, you can not use your own credential manager.
Much like you could use any AOSP fork to run banking applications... until you couldn't. But hey, at least there's an explainer website[0] that completely glosses over this detail.
[0]: One great bit of environmental storytelling is the "Made with <3 by the passkey community" in the footer. "Passkey community" of course means timcappalli with minor contributions from two others. You might remember him from https://github.com/keepassxreboot/keepassxc/issues/10407#iss....
It's notable that several of the claims on that page conflict with the other info in both the OP article and the follow-on.
As for choice as the user, it's a choice "for now"... and only for users who understand all of these details (which seems unlikely).
Personally, my observation is that if one tries to properly configure 2FA with any major website lately (no, I don't mean AWS console), the level of "your choice" and properly implemented security has actually gotten worse...
TFA's author has also explicitly precluded the "platform-authenticates-you-to-website automatically" workflow, in a separate blog post [0]:
> This one can be tricky because I've seen many sites using passkeys to replace passwords, but that's not something we've done on Report URI, passkeys are used as a 2FA mechanism.
[0]: https://scotthelme.co.uk/xss-is-deadly-for-passkeys-the-hidd...
Well, they can (and likely will be) used in both modes. Either these things are just a different way of generating a password for a password manager (itself a big target of attacks), or they are a way "to move beyond password with TPM-level security". If it's the former, the security benefits are limited. If it's the latter, the "it's a trap" logic applies at least in part.
> Well, they can (and likely will be) used in both modes.
I agree - and that makes me wish that the messaging was more clear from passkey supporters. Some may be genuinely confused and talking about one or the other mode (or not even realize that multiple modes exist), and some may be trying to claim the benefits of one mode while/or handwaving away the tradeoffs of the other mode.
> If you want to be able to move your credentials around, pick a provider that supports that
The fact that passkeys are not required to be portable is the entire trap
I actually spoke up about this at a local chamber meeting today during my 30 second elevator pitch. I decided to give a brief cybersecurity awareness month pitch about having backups for your 2FA and to be wary of passkeys because you will be locked out on device changes.
I think they are a trap. A usability nightmare. So, I acquiesce to a passkey to a site while on my iPhone and now I cannot log onto it from my work desktop in Firefox. An older person sets it up on his or her Google account, gets a new phone (iPhone to Android) or Android to iPhone doesn't matter and loses access. We know that Google won't help a regular consumer with anything.
Syncing may be a thing in theory but the friction is huge.
I recently had the displeasure of using Passkeys:
- trying to sign in to Okta on my personal Linux desktop computer. It has bluetooth and I had my phone right next to me, also with bluetooth turned on. But Firefox simply refuses to even show the option for "connect to your phone" or to give a QR code... it just said "tap your security key or biometric device". I had neither; my passkey is on my phone. Then it timed out and I gave up trying to log in.
- trying to sign in on my work Macbook using Google Chrome (enterprise managed one). For some reason, upon scanning the QR code, my phone was stuck on "Connecting..." and timed out. I had bluetooth turned on on both devices, they were five centimeters apart, both were connected to internet with a great gigabit connection. It turns out, I had to quit and restart Chrome and it magically started working.
- trying to sign in on my work desktop using a physical Yubikey remotely using VNC. It's not possible by design. I had to get my coworker to press my Yubikey in the office.
- trying to get Muse and OpenAI Dot to sign in using a passkey. It's not possible by design.
Generally, the user experience is really horrible with passkeys. It is also ironic that it trusts my phone (used for shitposting; easily lost or stolen) instantly, but simply refuses to trust my personal Linux desktop computer, which is fully encrypted, securely stored in my house, and contains all my life's work and everything that is dear to me.
Counterexample: the swisspass. It's a private service from the swisspost, and they whitelist webauthn providers. For example, you can't use bitwarden https://community.bitwarden.com/t/follow-up-on-bitwarden-pas... So the danger is there today, not in the future, since I'm already cut out today from the service, unless I use some hack
What I'd like to understand is why the majority of sites that allegedly supoprt passkeys do not let me store them on Yubikey hardware but instead are pushing into "cloud" passkeys. That's what is triggering my spidey sense about the whole scheme. If they are so great all around and vendor neutral why is everyone pushing me to store my keys in some "cloud" password manager? If I'm going to the trouble of setting up passkeys I want to be in control of them across all my accounts. That means my own hardware dongle. Not some cloud vendor's pinky swear that they'll take care of them and let me use them on my terms.
Websites can't choose for cloud passkeys. That's your OS or your browser.
They can request you store the passkey in something non-exportable, but many software passkey providers simply lie about being super duper secure.
My OS (Arch), my browser (Firefox) and my hardware (Yubikey) all work fine with some sites. For example my Google account credentials are on my Yubikey passkey. But half of the sites that claim to support passkeys won't offer me the option to save the passkey on my hardware. Paypal is one such example. Facebook is another. I don't understand why. They seemingly only want to cooperate with cloud based passkey storage. I don't know what mechanics govern this.
Paypal refuses to offer generating a passkey on either Firefox or Chrome on Linux. Spoofing the UA to Firefox on Windows does work, though. Whatever they're doing, it's not normal. I'm surprise you run into it so often.
This is the first time I've seen this issue, very weird. Then again, I had to apply some kind of hack to enable TOTP back in the day (something about faking an RSA key fob), so I'm not surprised Paypal is stil shit.
Let us consider the average user. The one who manages to lose their iPhone and has no idea what their iCloud account login is because they were aware of having to log into it once when they created the account at phone purchase 3 years previously.
That's where the trap is.
That person is fucked when they lose their phone anyway, because they're also the sort of person who has never backed up all their photos/contacts/iCloud files anywhere that doesn't require iCloud auth to get at. At some point we have to either properly educate people on the fact that they need to have a recovery path, or we have to accept that they're going to need to rebuild their entire digital life every 2-3 years.
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.
This is presumptuous. Many people back up their devices and have no idea how they did or whether or not it succeeded. Seen it many times(fortunately).
> That person is fucked when they lose their phone anyway
I am hoping nowadays most people lock their devices. I rarely see unlocked in my adventures anymore.
As long as they didn't turn on the advanced protection features on their account they just go to the Apple Store who can help them get back in
Impossible. Because iPhones randomly force you to enter your iCloud password, often at the worst possible time. Such a user would have already been prevented from signing in to their own iMessage on a random Tuesday afternoon.
One of the most frustrating issues with Apple's UX.
I've never experienced that. The only time I've entered my password was when I set up the iPhone and when the phone got into a weird state after a software update.
It seems to vary with how often you purchase things from the App Store and iTunes Store and how "high value" your account seems to some sort of iOS metrics. Which is why it also often seems like "phone is in a weird state after a software update" as that is probably also when some of these metrics reset/get rechecked.
It depends. It sounds like you're all in on the ecosystem. I only have the apple account because I have an iphone. I didn't get one of those double check reauthentications since many years ago, up until last month when I got apple tv. I know because I had to reset my password and it was older than my use of a password manager.
I'm a happy user of 1Password myself, but warning that they only allow export of passkeys through a specific protocol, and it has to be done on the mobile app. [0]
[0]: https://support.1password.com/export/?ios
The problem is this:
> 1Password for iOS exports ... directly to other supported apps, including your passkeys.
They pick the list of other supported apps. There is no ability to export to a standard encrypted file, nor is there a way to develop an open source app that can receive an export over the objections of 1Password Inc.
Exactly. So much for TFA's "or whatever other software of your choosing" claim.
Passkeys are a trap, trying to lock users in to the service providers.
I did say I like and use 1Password, but I do remember that they switched from a one-time payment model to a subscription model, and have now stopped supporting the old software and only support their subscription software. If it wasn't for my non-tech-savvy, aging family I support their usage of 1Password for, I would still be on Keepass[XC] for my own private usage.
Let’s assume passkeys are the greatest thing since sliced bread.
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 hope passkeys are the same as the USB-C rollout. The internet whines and complains for a few years about their theoretical device from 1999 that won't work anymore and then everything is just plain better for years to come.
Hah, I had the exact same reaction.
So many words spent on HN articles complaining about USB-C or praising Lightning... fast forward a few years to now and I legitimately just pack one cable in my bag and charge any device I happen to bring with me.
I'm not an expert, but it's frustrating to read these threads about passkeys. The common objection I see here is "But if I lose my device I'm locked out!"
A lost passkey should be treated the same as a lost password.
Sites that implement passkeys need to have an account recovery mechanism. Granted, not every site does this correctly. Don't use passkeys on sites that don't have a recovery mechanism!
Secondly, the site you're authenticating to must allow you to have multiple passkeys. You either have a cloud-synced password manager so that all of your devices get the same passkey, or you have a passkey per device that you use to access the site. Again, not every site allows multiple passkeys. Don't use passkeys on sites that don't allow you to have multiple passkeys.
For a site implements both of these properties correctly, if you lose your device, you just connect to the site with your new device, perform whatever account recovery procedure (TOTP, email verification, phone verification, ...), create a new passkey, and, ideally, disable the passkey from your lost device.
Passkeys are such a flaming disaster from a UX standpoint. I can't recommend anyone use them.
I don't find this post convincing.
> 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.
Then guess what - people stop using those websites.
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.
Only a few people stop using those websites, because most people will use the Apple or Google authenticators and be done with it. And if those websites are essential services, those few people who don't conform will be left out in significant ways.
> Then guess what - people stop using those websites.
Wishful thinking. Sadly, the vast majority of people will be perfectly OK with a website telling them they have to use a recent iPhone or Play-enabled Android phone to do something. This is already the case for banking apps and a huge number of other phone-app-only services.
> Then guess what - people stop using those websites.
You can’t just stop using those websites if your university uses them for student/employee accounts.
Yubikey is expensive. It costs like $50 which is insane. And, for nfc we need to buy different version.
Passkeys can be tied to a root of trust, like those owned by google, microsoft, apple.
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.
I have seen an exception to this with Microsoft Entra. I was not able to store and use the passkey in my password manager of choice, I had to save it in Microsoft Authenticator. I haven't tried again lately since that was for a previous job, and I didn't look into the underlying reason it failed, whether it was attestation of some sort or something else about how they set it up.
I'm generally pro-passkeys, but also acknowledge they are a hot mess for the average non-techy consumer. And there does seem to be room for the screws to tighten, and we definitely need to resist that.
Microsoft Entra is a workforce product. An employer always decides how you authenticate to your work account. It's not your account.
Microsoft also didn't let me use a normal TOTP authenticator and it wouldn't let me sign in with just my password. Every step along the way of a corporate MS account is bullshit, passkeys are just a victim of enterprise policies.
I find the following has the right combination of mental model and security for me:
1. A password manager that generates my passwords stored on an external USB key (which is itself encrypted). I use KeepPassXC.
2. More than one Yubikey doing U2F.
I know how to backup #1 and I have more than one of #2 to handle losing a Yubikey. #2 gives me phishing protection.
I have to say the messaging around passkeys is bad. So many providers show modals with big friendly lock logos superimposed on a smartphone to announce the change without offering any explanation about why the change is happening, why the change is happening now, or how the technology works.
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.
It was usenet mods, in September 1993, with the candlestick.
> 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.
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.
As if the police in a corrupt state are going to check the public fingerprint of your passkeys. Your account identifier is proof enough.
The make and model of your authenticator is shared with about 2 million other Yubikeys, if anything they'll compare your public key, not the attestation process.
Last time I tried using Firefox on Linux with Keepass's passkey implementation it worked on the test page and a couple other sites but Facebook refused to add it, so I definitely believe that e.g. banks and various other important sites won't balk at restricting passkeys to Android, iOS/MacOS, and Windows. I am curious what other people's practical experience is with these kinds of sites.
I've set up a few passkeys to see what it's like and the experience is wildly different between sites.
State Farm is the only place I've actually liked it. I don't have to type ANYTHING in.
Open browser, open password manager, click the "sign in with existing passkey", browser and password manager talk, prompt me to confirm the passkey choice, and I'm in.
Most sites I've messed with insist on you entering a username first.
> Most sites I've messed with insist on you entering a username first.
A lot of them do that to detect if they need to trigger an SSO flow. It's awfully annoying. Things get extra fun when a website migrates from email+password to SSO and suddenly you have two accounts that both exist in their system, one of which doesn't work if you hit enter before the SSO javascript redirect happens.
The counter-argument he makes against people's concerns about attestation is laughable, all he says is that it hasn't happened yet.
Passkeys are not designed just for security, there are other corporate interests involved. It's impossible to share logins for example. He even mentioned this concern and didn't address it.
The device/app lockdowns are already real for TOTP - Microsoft and others insist on using their snowflake authenticator instead of using the standard protocol. So it's not unlikely that they will extend that kind of lock-in to all passkeys.
For me, randomly generated passwords(via proton pass) combined with remembering to check the URL stops phishing and is easier to share.
Passkeys are a solution for a problem that the users didn't have (website security).
And the solution was: make it the user's problem.
Yay.
They don't solve a problem I have. So I am not eager to adapt them
And additionally they cause problems I didn't have.
If they are not a trap, then the standard should be amended to allow third party implementations to forge attestations.
Otherwise, it is a trap. The story of the last 25 years of the internet is user hostile ratcheting away of the open web. Passkeys are obviously another step in the process.
I don't want passkeys. I want to stop being bothered with setting up passkeys, especially if I already have 2FA setup, and definitely if I already have a hardware fido key on the account.
Some context I think is missing: TFA's author claims to use passkeys for 2FA (and so, not as a password replacement as I think is often implicitly assumed in discussion):
> This one can be tricky because I've seen many sites using passkeys to replace passwords, but that's not something we've done on Report URI, passkeys are used as a 2FA mechanism.
Source: https://scotthelme.co.uk/xss-is-deadly-for-passkeys-the-hidd...
I use ProtonPass on every device I own (religiously) and have never had an issue. But it's because I'm very careful to only deal with any credential ever via ProtonPass.
I can imagine it gets annoying very fast if you accidentally put a passkey in the wrong place, ie because Chrome proposes it's own credentials store.
ProtonPass also lets me export the private parts so I'm not stuck as with some passkey managers.
Passkeys are great but require you to understand some things about them, and you need discipline in dealing with them.
Every point in that post has been discussed at length other places, some of which is in the HN thread the author mentions. And the discussions make it clear that the points being made are not seeing the problem - not that there isn't a problem.
Passkeys have benefits - but they also have problems. Many people just don't think the benefits are worth the problems. And many people are afraid that sites will just stop accepting passwords in favor of passkeys, leaving people worse off.
Almost every complaint I see about passkeys seems to be based on behavior and configurations I just do not see in the real world.
“Once I set up a passkey I can’t log in from another device” - have never seen this to be the case. Existing password / OTP codes have always worked as a fallback if syncing somehow breaks.
“I don’t want to trust Apple/MS/Google with my logins” - so don’t. Use bitwarden or 1Password or lastpass or whatever you want to store your passkeys.
“If I lose my phone I’m screwed” - see #1 and enable sync maybe?
Boils down to I believe a lot of folks looked at passkey implementation at a high level, saw some potential pitfalls, and never actually used them to discover those pitfalls have all been accounted for.
Go ahead and skip passkeys if you want, but stop preaching about evils that don’t exist.
Passkeys are great for developers who are into cryptography and security, and who understand the idea and implementation behind it. For the rest of us it's something to avoid.
I don't use passkeys anywhere for fear of losing access. I just don't care enough to study how it really works. With passwords, I occasionally print out all my important passwords and store them in a safe and I know there's no way I could lose access.
I put a reply to this article in the comment section of "Passkeys are a trap. Do not use them."
https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-...
Trap or not I don't want them and the UX is shit and user-hostile.
I'm moving my HSA because the company moved to passkeys.
I use unique email addresses and passwords, stored only on my devices(Linux, Windows, Android) using open source software (KeepassXC, KeepassDX). Passkeys add new friction I don't need.
The og article talks about future concerns even though things are fine today. This article claims things are fine today.
True, but doesn’t actually refute the original.
I introduced Passkeys in my company.
Every single IT person thought it would be an extreme mess, too complicated for regular users. In my company we work on the (gas) grid so lot's of blue collar types.
We went there, gave the pilot group a Yubikey and said: This is like the company pass you already have. Without the company pass you cannot enter any buildings. Without the Passkey you cannot enter a computer or app.
If you lose it report to the same people (service desk).
The response has been EXTREMELY POSITIVE. People fucking LOVE getting rid of passwords, password requirements and taking off their gloves to enter it every time.
We are now rolling it out to everyone and next year when we stop our silly "phishing game" contract we will actually save money while reducing a massive cyber security risk for our company: (voice) phishing.
Perfectly fine in a business environment where you don't have privacy. It is unacceptable for any personal computer(including phones) to be leaking unique ids so you can be tracked.
What's the unique id leaking issue?
I mean you're logging in to some software, surely they need some info from you?
Passkey attestation hands control of the client software to the website. Since surveillance capitalism funds most of the web, this means that, over time, the only approved clients will be surveillance devices, and those devices will slowly add more and more invasive spyware.
Initially, they will probably “just” require hardware serial numbers or similar (so they can join IDs on the backend).
There are already serious proposals to require live web cam feeds for porn site login biometrics purposes, so I can’t really come up with any hyperbole to add.
This is exactly what happens in many companies like bank of america. They are forcing their app to every employee and contractor and is actively tracking locations and whatnot from phone.
As a user if you push something too hard I immediately think what the angle is. That is how i feel about passkeys.
Reminds me of when The Powers That Be forced me to connect to websites with HTTPS. Then they stopped supporting Internet Explorer 5. What were they trying to hide?
Lot's of additional great information for consumers and prosumers at whatarepasskeys.info. Many of the questions that are constantly discussed in these comments are answered in the FAQ and content.
Contributions and feedback are welcome! GitHub link is at the bottom of the page.
Saying "attestation can't hurt you, your password manager returns `none` today so it's not a concern" is avoiding the entire point of the original article which was that that can change at any time! I'm already seeing in a corporate context, IT departments forcing hardware attestation as required everywhere. Justifiable, but also clear evidence that it's no longer in your control as the person authenticating. That's the point, passkeys are marginally more secure for you, while handing huge amounts of control to centralized platforms.
domain binding requires browser participation.
you can have a TOTP variant which has the browser display a challenge string & QR code, authenticator generates a 5-6 digit response. include more entropy in the response if you want to do away with the password entirely.
passkeys are trash, I would never opt for dedicated hardware (or a cloud service) and using them with a password manager is extremely messy when you want the password manager to be properly isolated from the rest of your system.
I think it's a bad sign when someone immediately resorts to strawmen and argument from incredulity in their counter-argument:
>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.
Not sure if this mentioned, but I setup a new Gmail account and it wouldn't let me add my yubikey for MFA. I could only add a passkey to my yubikey for MFA.
Wouldn't web browsers themselves be the ultimate passkey managers like they already do with passwords? They'd need a way to export the passkeys to another passkey manager though.
Biometrics is my main concern around this, and in that the government can compel you to provide them for device unlock, unlike a pin or password.
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.
Just don't setup biometric authentication on your device, then? You don't have to use FaceID to unlock passkeys in iOS for example
you will eventually be compelled to, which is enabled by attestation
Well, at that point I'll figure out what to do. I can't live my life constantly working around bad design that doesn't actually exist yet
This attitude is the reason design keeps getting more and more user hostile over time.
I cannot possibly game out all future adverse design choices that a vendor may make. Today, October 14th 2026, Passkeys offer more upsides to me than they do downsides, so I use them
If a particular app vendor or website changes how they accept or use Passkeys, then I won't use them for that app or site. If my computing platform vendor(s) make it harder or worse to use Passkeys then I'll bail out
There's a lot of what-ifs in every decision, and I cannot possibly nor would I want to, figure out 82 steps ahead in 4-D chess how company X may try to screw me over
what are the winning Powerball numbers next week, future knower?
if you don't setup biometrics be ready to provide mfa which is inconvenient every 30 mins....
There is nothing about passkeys that requires biometrics. Synced passkeys on android will work with your screen unlock code if you do not have biometrics enabled. Same with passkeys stored in a password manager. Same with hardware passkeys that do not support biometrics.
every time I've been prompted for passkey setup, it says things like "this is easier, just give your fingerprint"
no thanks, passwords are not a burden to me
What makes you think the government can’t compel you to provide a password?
Case law and court rulings
I figured they weren't. People smarter than me made them.
I think they've been implemented well in some cases. I think they've been implemented poorly in others.
So it goes.
I mean the desire to trap seems to be among the big corporations already.
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.
> Right now I see no compelling reason to switch from regular OTP codes. Change my mind.
The phishing potential?
I completely misunderstood passkeys.
Just came back from doing a bit of research and apparently I can use Bitwarden to generate and store passkeys.
I have been dismissing the entire concept because I assumed it had to do with hardware keys, which I would never trust. But if it's bitwarden, then I can easily do a backup, and that would be very reliable.
I think I'm going to start using passkeys... :D
The standard allows sites to ban things like bitwarden over time.
Today you are add it to bitwarden, tomorrow they will force you to use only company software lol.
This is the problem with passkeys....
I was expecting the author to at least address the thinly veiled threat to blacklist KeePassXC at [0] (via the very same mechanism they claim is harmless), but of course it's not even mentioned.
I'm sorry, but if your system allows someone to make a credible threat like this, you should make sure to redesign your protocol so that kind of abuse is not possible BEFORE advocating for it. I'm so incredibly sick of people repeating history, only to disappear once we're all roped into yet another anti-user scheme.
And yes, passkeys absolutely ARE a trap.
[0]: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
I try to avoid passkeys as the UX is just not good.
But what is the solution here does anyone know how to make this good?
What's annoying about passkeys (and not talked about enough, including in this article) is that passkeys seem to be a boon for the targeted-advertising industrial complex.
Since passkeys are tied to verified devices, they guarantee absolute de-anonymization -- and further spread that advertising "wealth" by seamlessly linking across devices, and therefore to their respective corporate stakeholders (i.e. via bluetooth to conveniently login on a laptop via a phone-domiciled passkey).
Username + password at least requires circumstantial marketing analysis to "verify" whether a user is who marketers think they are. But with passkeys, your login confirms your Windows account ID, cell phone MAC address, home address, what have you.
I truly believe pass keys are a way for yo to eventually lose access, or give someone or something else, access to your logins.
Anything that's tied to hardware is one accident away from locking you out forever unless you set of "2 of 3" or some other "let's make life even worse when it comes to authentication" solution.
Passkeys are a trap in that they're a fairly confusing implementation that ends up tying you to a specific device or device ecosystem.
"Is not a trap" does not follow from "Is currently good".
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:
Which is a statement about the near future. There is room for a conversation about the long term, but this article is not a part of that conversation.Thank you for posting on this. The last post on passkeys was utterly confusing and I have been thinking about this until yesterday. I had done some research for a client and had referenced your blog. This whole FIDO2 cryptography-based passkeys system is confusing even to a technical person, let alone convincing the general audience. After bringing together all the different types of passkeys, I had categorized them into three main categories:
1> Synced Software Passkeys (e.g., Google Password Manager, Apple iCloud Keychain): Encrypted locally but synchronized across a cloud account.
2> Device-Bound Software Passkeys (e.g., Microsoft Authenticator app on a phone): Only inside the physical device's secure hardware chip.
3> Device-Bound Hardware Passkeys (e.g., YubiKey, RSA iShield Key): Permanently burned into a dedicated physical USB/NFC chip.
I advocate for "Device-Bound Hardware Passkeys," but not many websites support them. Keeping a duplicate hardware passkey is important in case the original hardware key is lost.
These guys are so dedicated to protecting us from ourselves that they won’t provide any mechanism to export passkeys and port them between devices because it might be used for phishing. It’s just fucking annoying and presumptuous. No im not going to fall for phishing, i need to have some escape hatch to get the data.
Attestation lock down is also ALREADY a real thing. Microsoft sites (and others) frequently require you to use their bespoke 2FA app instead of using the open TOTP protocol. They will do the same thing when it comes to deciding which devices and software are allowed to login, and everything outside the corporate slop safety bubble will be denied.
I absolutely love them now that I have a Mac. They're shared between my phone and my Mac automatically so I can just sign in to anything with my fingerprint.
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.
Thats what a trap would say...
"A passkey is bound to the domain it was created for, so your browser simply won't use your example.com passkey on examp1e.com." What happens if a service you use loses its domain? For example, if I run a marxist online forum, it could happen at any time that the US regime sanctions my site and seizes my domain. Would my comrades still be able to log in with their passkeys?
"AAGUIDs are unique identifiers assigned to FIDO authenticators (including passkeys and security keys) and are used to identify authenticator models for attestation and metadata purposes."
If there is any unique id that can track you, then it's a trap. No security system should be leaking unique ids that can be used to track users.
AAGUIDs are not unique to authenticators. Hundreds of millions of people using the same product have the same AAGUID.
If it looks like a duck...
When a website forces a passkey into my password manager without even asking me (fucking Amazon), it is pretty unambiguously something that is not good for me.
QED, a trap.
This author is astoundingly trusting.
> 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...
Google forced OAuth2 because Simple authentication is absolutely terrible.
Whats so bad about it
There's absolutely nothing insecure or wrong with app passwords for a local client application.
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.
App passwords are not scoped, are they? When I set up an app password for my whole google account it is never asked whether it is for email, docs, youtube, etc... . The oauth token is properly scoped.
I mean... that's up to Google how they choose to implement app passwords. Back when they still supported them, I think they were properly scoped.
An app password is basically just an API token, it's up to the backend what powers it grants.
API tokens are usually explicitly scoped by the user when they create them. I don't recall Google (or anyone else) ever exposing that when creating an app password, but maybe it was scoped down on first use?
Google would not do something that would lock out half of the mobile device market. iOS doesn't do attestation.
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
Are you sure iOS doesn't do attestation? Google recently turned on requiring an iOS or Google-attested Android device with a camera for some reCAPTCHA challenges(i.e. take a photo of this QR code). They waited for Apple to support it before doing so.
Is that the same thing we're talking about here? That sounds like a CAPTCHA, not Passkeys. I mean iOS isn't doing attestation in Passkeys, I'm sure there's some thing on the phone that it's doing that is a version of attestation
Thunderbird is an email client, not a web browser or a web server. It had to build in support for both of those things to support oauth2 login: https://bugzilla.mozilla.org/show_bug.cgi?id=849540
I assume Mail.app had to do the same.
Okay? At some point mail applications didn't support IMAP, because it was new. Was IMAP bad because it forced POP3 clients to build new support that they didn't previously do in order to support the improved functionality?
OAuth wasn't about lock-in (since any client can support it), it was about getting off shitty legacy auth
OAuth2 solves a bunch of problems that are irrelevant for a desktop email client. https://news.ycombinator.com/item?id=50089261
You shouldn't need a web browser to read email.
Google today might not do that, but Google tomorrow, when some upper manager's multi-million dollar bonus gets tied by a performance metric on how many people are using passkeys for gmail would in a heartbeat.
> 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.
"Model of the authenticator" could say almost everything about these if the model was let's say "Google Pixel 10". TEE would refuse to sign the attestation if the bootloader was unlocked / AVB didn't verify.
YubiKey attestation is not a problem because the device doesn't work against me in such a way it would require installing custom software on it. And even if YubiKey went crazy, they're not a monopoly.
Situation with smartphones is very much different..
I hate passkeys because they're always tied to a specific account or a device like a phone. I hate being dependent on phones/devices. That being said I know they solve a lot of problems so....
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.
Syncable passkeys are a thing which the OP addressed. Apple, Bitwarden, and other password managers all implement syncable passkeys. In fact, I just did an upgrade of my iPhone 15 Pro Max to an 18 Pro Max and all of my passkeys came along with the upgrade.
I don't think it's appropriately addressed. The apple ecosystem has really good syncing between devices but only when they share an iCloud account. What happens when your work mac isn't permitted to use your personal account? What happens when your company issued password manager and your personal one fights? What happens when your company issued device is an Apple device AND you have to use a mandatory password manager from the company?
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.
you have the QR code based handshake thingie, supported by apple and windows 11 at least.
Can they go from the 18 Pro Max to a Windows 11 device? Or to an Android device? Genuinely curious about the portability.
I don't think Apple bothered to implement passkey support in their Windows iCloud password implementation yet.
You can log in by scanning a QR code with your phone, though.
Or you can use a different passkey provider that does work cross-platform. You don't have to use the one built into your phone.
Yes. I use 1password and all those platforms are supported.
Passkeys are confusing, fragmented, awkward, and annoyingly implemented. They aren't a trap, but they are far less efficient and less proven than a password and app-based MFA.
They're better than passwords but just as annoying when I have to sign into Outlook every 5 days
It's like with iso 8601.
- we support iso 8601
- really?! Like P1Y2M3DT4H5M6S?
- err, no, I mean 2026-12-31
I don't like them, they offer no advantages to logins with random passwords. They would only be more secure if they were forced to be stored on hardware devices like Yubikeys, which almost never happens in practice. In reality it's true that they can be dangerous because they can be set up in a way that doesn't allow storing them in software and using them on multiple devices, and such device-bound passkeys will eventually lock you out or be reset in the same way as password+login (usually just by email).
The standard and implementations are also unnecessarily complex and obtuse. IMHO passkeys are not a good technology.
At the end of the day, I just don't really want them. I already have passwords and I already have to put up with 2FA. Passkeys are just one more damn thing to understand in an ecosystem I already want to spend as little time in as possible.
>here’s why you should use XYZ!!
Few weeks later
>let me tell you why you should NOT use XYZ!!
Classic HN.
That being said, password and 2FA is the best combo, where you control the token of the 2FA and it’s on a separate app/platform/etc than where you have your passwords.
Thankfully someone with some sense. I saw that post title and didn't even bother to read it. It sounded like someone having argued with me a decade ago that IPv6 is a mechanism for the government to track you because you have no more privacy anymore because you don't have NAT...
I’ll be silly, but having a unique address per device, is indeed a simpler vector to track, right?
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.
It's common for devices to choose a new IPv6 address within your range at random to perform a new connection / rotate periodically.
Which in turn makes it harder to track vs. your /64 which is approximates your old NAT'd public IPv4.
This:
> Thankfully someone with some sense
Cannot be asserted with this:
> I saw that post title and didn't even bother to read it.
Why didn't you bother to read it but still think they have no sense?
Because I too understand passkey attestation and have written code to do exactly that and have worked in multiple enterprises where we've done a mass Yubikey rollout across thousands of people. So I've got a pretty solid understanding of passkeys, yubikeys, and attestation. As well as I don't read headlines of people claiming it's "tracking you".
Yay, finally an expert.
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!
Would you bother reading an article whose title is “the earth is flat. No really. “
If I was posting in a thread about an article responding to that article, then yeah -- I'd read it. But we're not.
Because, apparently, passkey evangelists are a cult.
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.
100% correct takedown of the "Trap" article
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
Google and other services like PayPal make Passkeys default if you generated one.
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...
One of the bigger issues with passkeys has been that they get locked to one provider (like apple in your case). Now i HAVE to use an Apple device to unlock passwords, same with Google and Android. Its very much all eggs in one basket.
If it was easy to migrate between services, then i would be a lot more open to using passkeys.
It's fairly easy to export/transfer passkeys (I think, I've never actually done it)
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
>It's fairly easy to export/transfer passkeys (I think, I've never actually done it)
>I've never actually done it
You can't be serious.
If it's easy, go do it, find out, and come back here to tell us about it.
I don't need to, I'm not bouncing around password vaults with the frequency of a cheap HAM radio. I've skimmed over announcements of the feature becoming available in a product or two
>I don't need to
Yes you do, if you want to claim it's easy.
Otherwise you're just bullshitting.
>I've skimmed over announcements of the feature becoming available in a product or two
See above. That's not equivalent to "it's easy". You don't have the basis to say that.
Not true. I just migrated from apple passwords to 1password. Including passkeys. It's pretty seamless.
For a few corporations yes, but not for local only like KeePass or similar. Thats the issue i have with them, if a can set them up as easy as TOTP on KeePass then fine.
Too add to my own comment: I know that its coming, but until i can export to something like. keepass and not a commercial entity then i don't consider it ready.
Many credential managers support migration. See https://whatarepasskeys.info.
What is hard about migrating between password managers? At least on MacOS you can just open passwords and export all to another app?
The problem is that they determine the other apps that are supported. There is no "generic" export.
I think PassKeys are great.
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.
> 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?
No. Ethernet, WiFi, and Bluetooth are all on.
I believe a reboot sometimes restores functionality.
Also, testing now showed that they connect successfully and copying from the Mac to the phone even works. Just not the other way around.
A reboot of the phone fixed the connection in the other way so that I can paste on the Mac again.
With that, a hardware issue or connection problems seems to be ruled out.
Apple's software is simply buggy.
Let's hope your iphone doesn't get stolen or smashed and your beloved passkeys lost
Well, they're synchronized to my Apple account so that's not an issue. They're available on all of my Apple devices, or even ones I don't have right now that I log into in the future
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
> or even ones I don't have right now that I log into in the future
How do you log in without having the passkey?
I'm sure they exist but I have yet to come across a service that both removes the ability to also use a password when you register a passkey and also has no other recovery methods if your passkey (and/or password) become unknown or unavailable to you
In theory if I locked down my Apple account with the advanced protection features that are optional, I could lock myself out, but it would be on me to save recovery codes/secondary passkeys/etc during enrollment in those optional configurations
Otherwise, I'd walk into the Apple Store and they'd be able to get me back in my account if I didn't have some alternate method to get in
You have one Apple device that gets lost. You buy another and try to log in. Apple expects you to approve the login with the lost device. What now?
You do the acccount recovery flow. Options include providing your recovery key or proving your identity to Apple customer support. Do you really think Apple did not account for this?
Why would they be lost? They are synced to iCloud Keychain, which is E2E encrypted.
It's just not a replacement for TOTP and password entirely. It's a shortcut, a super-cookie that is more secure. If I lose the device that has my passkey, I need a way to access my account from another device.
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.