"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.
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.
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.
>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.
There is heaps of context missing from this. Did the password manager itself get hacked, or did an employee leak a password for a single site that didn't use 2FA ?? The former strongly solidifies your point, the latter undermines it, and to be clear I don't think it's a good idea to use an employer sponsored password vault either.
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...
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
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.
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.
> 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.
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?
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.
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"
>>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.
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.
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.
It breaks the traditional login paradigm. I had a hard time trying to setup a single device as my passkey manager. Now I realize that you should make one on all your devices. My bank website, I have my password and two separate passkeys. Individual sites may have an implementation issue, but in that case I use the more troublesome password workflow. I still come across password implementation issues on some sites.
I still can use my password. I use the passkeys for the convenience and extra security. If I lost all my devices I would just login with my password and add a new passkey. I would also remove any for devices that I don't control or are damaged.
I suspect even if the site were passkey only, they would have some account recovery workflow.
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.
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.
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.
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.
It's not though. Passkeys are meant to allow you to have multiple. They also don't need to replace passwords. Take my bank setup. I have a password, a windows passkey and an android passkey. I saved the time needed to setup the passkeys, the very first time I used them. The passkeys are easier to use, than my password, and more secure.
you're misunderstanding: 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.
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)
If that's so then what actual security benefit is derived from it?
Of course the sites presumably will flip the switch at some dreaded point in the future where you can no longer circumvent them, but at this rate it may take a long time to reach a use by majority of users.
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.
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.)
In Coders at Work, Peter Seibel quotes Jamie Zawinski as saying that certain Netscape acquirees were people for whom "cross-platform means both Windows 3.1 and Windows 95."
You might not have heard but Lastpass got hacked fairly recently. I would be careful about storing your passwords in the cloud (or at least that cloud). Keepass / KeepassDX would be safer. Sync devices with SyncThing.
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].
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.
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.
I put passkeys in both iCloud and Bitwarden. I count on having access to one or the other, or at least being able to recover access to one or the other, but it’s the same situation with my passwords generally
In fact I quite like having separate passkeys for each manager instead of one password and -maybe- separate TOTPs (usually not) shared between them
For security? If you're not using a password manager, that means you're using the same password for almost every site. Which means every site is a point of failure for every other. This means some way of generating and saving random passwords for each site (i.e. a password manager) is absolutely required for security. You are welcome to use the password manager that comes bundled with the device you paid for (apple, android), or use paid cross-platform ones like 1password (which works well), or use free cross-platform ones (in which case you might get what you paid for).
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.
Sometimes the url for the login page changes or I'm logging into a different part of the site and my password manager doesn't recognize it. My university used Duo for authentication but depending on which resource you were trying to access, the subdomain might be different. How would I immediately know that I had just typed in my credentials to a misspelled domain or a hacked user account on a school web server displaying a phishing login? That last one would be even more nefarious because my browser might not even display past xyz.abc.edu/ and it would even have a valid SSL cert. Even if my password manager didn't recognize that URL and I manually typed it in, my passkey manager certainly wouldn't even attempt sending a key.
The real problem is that companies/institutions should procure one domain name, and stick with it. There's no reasons so need to be redirected through 6 domain names when signing into Microsoft, all of which look like a phishing attempt URL.
You still need a password to exist, so while the passkey won't activate the user can still leak the account's credentials.
To cover that gap, you get rid of passwords altogether, and now users lose access if the passkey fails to sync or isn't available on one of their devices (let's say a Kindle Fire tablet)
Passkeys being bound to the domain is neat, but not without tradeoffs and practical workarounds. At least that can't be the only aspect to look at when making a choice.
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?
Usually you can setup an alternate 2FA like TOTP, a recovery SMS, or something else you can use to prove who you are. And then once you're into the site, wipe the current passkey and setup a new one on your current device.
But if I can use any other form of 2FA, there is no way I'm using a passkey. The only way I would ever do so is if I have no other option.
I cannot think of any innovation that has required more defensive pleading for people to use it than passkeys. When a HN article has to be titled "passkeys are not a trap", the concept has already lost.
Seeing how effortlessly 1Password supports exporting to other clients really makes me want to use 1Password more. How does it handle other fields - Apple Passwords has like 5 fixed fields while 1P has dozens and custom fields?
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.
I've used a number of password managers over decades. I'm still having to copy and paste passwords from time to time due to poor/hostile website designs, needing to authenticate into a browser/app that doesn't have the plugin configured yet, bugginess on the plugin detecting the right site, etc. And in the end, if the user can copy and paste that wherever, the user will copy and paste that wherever.
Meanwhile there are other security benefits as well. With a password, that static credential is transmitted in the handshake. It can be mishandled somewhere in between, and now that entire root credential is potentially compromised. This is just impossible with a passkey. The credential never leaves the client. In some implementations, the credential never leaves a secure enclave, never even entering the client's system memory. You can't say the same for passwords, not even close.
Yeah, a lot of websites these days seem to block or mess up autofill where I actually want it: I can’t say how many websites break credit card autocomplete, TOTP code autocomplete (e.g. via Apple’s native TOTP implementation), username/password autocomplete. I can never really tell if it’s incompetence or a misguided idea of security, but it’s extremely annoying.
This would be true if websites consistently annoyated inputs correctly, but they don't. So password managers are left to guess what input is the username, which is the password, etc. and they don't always get it right.
> password doesn't show up you know there's a problem
Here is your contradiction.
The normal person will just assume that some tech isn't working today again.
A key point of passkeys seems to be that it guarantees to the site owner that the user cannot be phished, without having to make assumptions on whether the user is tech-stupid.
They have to be, because quite regularly password managers fail to detect properly user name or password fields, in which case you have to copy and paste by hand.
"it guarantees to the site owner that the user cannot be phished"
Well gee how nice for the site owner.
Problem is my priorities are my absolute ability to never lose my most critical assets through some means outside my control, not the site's convenience.
It was ok to use imperfect systems back in the days when the bank and the store and even the government all had a desk a mile away you could go to in person and get anything cleared up and override all possible "usually it works like this" with your physical presense an drivers licence and birth certificate or simply 5 people who all attest they know you.
We no longer have that ultimate backup plan, so really F anyone's attempt to justify basically tricking people into doing something unwise that puts them at actually greater risk because their life is less under their own control, and doing this under the very banner of claiming to care about the users safety!
The normal person will click the "Use password instead of passkey" link conveniently placed by the impersonator, who will then have an email address and set of user-provided password guesses that they can try on other domains.
Can you login using a password on an untrusted PC and be sure it's still safe? And there is no lock in. You can have multiple passkeys from different providers I have Windows and Android setup for my bank. The lock in conspiracy doesn't even make sense. Who benefits. Let's just say Google tried to only allow passkeys. Why is my bank going to drop passwords and enter into passkey only relationship with Google and/or Apple. If I have that power I am not going to use a web standard anyone can implement. I would use a proprietary system that nobody else can.
What's the point of a passkey that can technically be exfiltrated off a device it was created on? I thought the whole premise of passkeys is that they can't be copied, and hence can be trusted as much as the device access control. Am I missing something?
It would introduce a different usability problem to have them remain truly stuck on a device, like, locked inside a Secure Enclave. Mainly that you’d have to do the setup again for every website, on every device. Buy a new phone? Back to the Stone Age. Authenticate with a password to each site on the new device, find the “add passkey” place, and install it.
I think that is a big step down from the convenience and friction level that the native password managers get you, where you save your password once and for the rest of your life, as long as you maintain fealty to Apple/Google/Microsoft, your password will always be there in autofill.
> I do appreciate that passkey adoption has led to wider support for hardware security tokens
In my experience this simply didn’t happen. Many sites support passkeys but only the native passkey stored on the current device, but not a hardware security key. Many sites don’t even allow multiple passkeys, which is frankly required if you use hardware security because you will want multiple pieces of hardware in case one is misplaced.
On XMoney I can't access the app on my desktop because it forced me to use an iOS device to set up the account, and I guess, but don't remember it mentioning, that it created a passkey on there. There is no alternate way to log in. You're just permanently locked out. I spoke to the devs, they say that's intentional.
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).
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).
Netflix already tries to crackdown on account reuse by policing the number and type of devices you install it on at the same time. They don't necessarily need to double down on it by policing Passkeys. But also "Netflix is a bad actor" is a threat model that has a market correction: If you can't login to your Netflix account then don't pay for your Netflix subscription.
Netflix is more incentivized to keep people paying subscriptions than they are worried about people sharing passwords or passkeys. No one "needs" Netflix, it's an entertainment service. If they are truly a bad actor with respect to Passkeys then they upset too many consumers and lose a chunk of their audience.
Yep, any time you're asked to set up a passkey it feels like Russian Roulette with future access to that account. A year or so ago, a site I relied on started enforcing biometric passkey enrollment. Without thinking about it I logged into the site on my phone and enrolled there, but unfortunately (a) that meant it didn't get registered as an "other device" in the internal system, and (b) the site didn't work correctly on mobile devices (legacy system). So logging in on a desktop would then demand that I activate the passkey, but of course the passkey was on the phone. No way to access it, and the site didn't offer me the QR code / bluetooth method. I don't remember exactly why, but it just didn't work - probably had something to do with it not liking Firefox on Linux or something.
And to add insult to injury, it wasn't even a single factor login the way passkey advocates promise. The site still demanded a normal password to log in! It was actually 3 factor authentication; something I know (the password), something I have (the passkey), something I am (the biometric).
This wasn't some random website that didn't matter made by nobodies. It was a US government website for managing grant money.
And they always ask right when logging in which is the absolute worst time to ask anything.
If I'm logging in to your app or service it's because I want to do something. Throwing up a "hey would you like to setup this complicated auth thing before you're able to do anything else?" Is annoying at best.
Then they normally follow it up with a tutorial that blocks the part of the app you need, and a full screen modal to subscribe to their newsletter, and a cookie dialog asking to let you track them, and a popup asking you to rate them on the app store, and...
Only once I've beaten away all the interruptions am I finally able to use the damn app.
> Some sites, once connected via passkey, make it all but impossible to connect in another way.
That's not a usability nightmare.
That's plainly a nightmare.
Also, the very thing that passkey evangelists were foaming at the mouth 1-2 years ago here assuring me Would Absolutely Never Happen and Is Not A Concern, because the spec says passwords should still work.
To the surprise of exactly no one with half a brain, things didn't play out that way.
> though we're back to a "biometrics as password" problem in many device flows
Meaning if you're detained with the device, you can be legally required (and physically forced) to unlock not just the device, but all your online accounts.
Nothing suspicious here, not like authoritarianism is on the rise or anything, and whoever lives in those countries can get fucked in any case.
>So far, it's about 30% of sites screwing it up...
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.
Does the passkey still serve a purpose in this scenario? Why not log them in by email and set a very long lived cookie so they don't have to log in often?
In my example reset by email has only been activated as a disaster recovery scenario where the site has lost it's domain. Under normal circumstances you would not enable it.
If you lose your domain, you have bigger problems than just passkeys. If you just used passwords, users would still have to somehow locate your new site and trust it with the password previously associated with your old site. Password managers won't input passwords from one domain onto a new domain.
As someone else said, you'd have to do an email blast and hope users trust the email blast as authentic to trust your new domain.
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."
If your account is already not protected by passkeys (it has access to traditional username + password credentials), it can be phished regardless.. in those cases you just need to send them a traditional phishing email.
The point is that those attacks would be (nearly) impossible if you have a truly passwordless system.
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 u quiet password on the wrong site if you get phished.
Passkeys don’t get transmitted. They’re used for cryptographic signing.
Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
You can’t store a passkey wrong on the server, it’s a unique public key. If your entire database is stolen, it’s useless. No one else can login with your credentials because they don’t have the private key.
Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
Passwords are fundamentally broken. They cannot be fixed. Cryptography is the solution in passkeys are the implementation.
> 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.
> 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.
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.
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 and some random web form with their banks logo slapped on it created on wix.com
Several of the successful attacks that compromised 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.
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.
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.
> 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.
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 likely 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.
The argument I'm making is that the only MITM/phishing vulnerability is in the initial passkey registration and not in the auth.
So once you have a passkey and the flow supports attestation, as long as you use the passkey you are effectively immune to MITM and phishing.
Now if you input a password or recovery code or whatever and use that to register a new passkey that's initial passkey registration again and not MITM or phishing of the passkey itself. The reason this matters is because you can register as many passkeys as you want. Say you sign up and log in on your phone. Now you register a passkey on the phone. You want to log in on your laptop, use the key from your phone to log in and register one for the laptop as well. Now you lose your phone or your laptop, you use the other to log you in and set up a new passkey for that device.
Once that initial passkey was registered the auth process is pretty watertight and each device you regularly use gets a new key after auth so you generally always have at least one device that you can use to get into your others.
Now of course if you only have one device and it gets destroyed or if all your devices are destroyed in a fire or flood or whatever then you have to go through the untrusted reset/re-registration flow but in all other scenarios you always default to the passkey-based "use another device you own" methods to register new keys.
TLDR: the point is that you very rarely ever do a true cred reset. The flow itself incentivizes multiple passkey auth methods such that bootstrapping new keys from an untrusted environment is rarely if ever required. This works best for "core services" like your email/google acct/apple acct/microsoft acct where you are generally expected to want access to them anywhere you do stuff so the passkey flow is best pared with SSO to increase the odds you've used the acct on at least one other device.
The phishing site will say something like "Your passkey is out of date, click here to create a new one" I call that cred reset since it is similar to password reset, perhaps some sites support multiple passkeys, in that case the phishing site will use the register new passkey path instead of reset existing.
Phishing sites already frequently target the reset/create-new-password path because it's actually easier to get a user to generate a new password vs. trick their password manager. Plus 2FA is usually required anyway since no 'remember me' cookie is avail so a password reset is equal in difficulty to a password login.
That method still works just fine with passkeys right?
The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks. Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.
> That method still works just fine with passkeys right?
Kind of? But it really depends and there's a lot of edge cases the phishing website would have to dodge to avoid breaking the custody chain.
If you force the user down to "use your password/security questions/whatever" to auth and create a new key then yes phishing is still viable here but one of the key advantages of pushing for a passkeys-first approach is that you can make the other auth methods harder. i.e. mandate password + 2FA as a strictly backup method instead.
> The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks.
Yep and passkeys explicitly exist to eliminate this behavior.
> Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.
Well here the caveat is that the phishing website would have to force the user back down to password-auth or security questions or whatever other "weak" method and then use that to create a passkey but not have perms to do anything else.
Now if the phishing site tries to MITM the actual passkey registration flow there are a lot of ways to detect a phishing attempt and terminate the registration and alert the user through alternate contact methods.
TLDR: there are probably still ways to execute a phishing attack but to succeed they have to be far more sophisticated and there's countless ways to accidentally break the passkey auth chain in a way that halts the attack.
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.
? If a website sucks and can't support multiple passkeys that's not a flaw of passkeys. It's a flaw of the website. You could make the exact same argument for TLS or 2FA or every other security feature.
If the developer fucks up the website/app, that is their fault and not a failure of the technology.
>that is their fault and not a failure of the technology.
Respectfully, you should consider reconsidering this mindset. The best engineers and tech designs take into account not only how users will use a technology but also how they will misuse it.
> (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.)
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.
Which makes the hash the password and the hash of the hash the hash. You achieved nothing. If you truely don’t want to send the password, there are of course ways. But it’s a heck of a lot more complicated than this and no one is doing any of it because… Passkeys is what you end up with.
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?
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.)
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.
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?
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.
> 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.
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?"
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.
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.
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 sharing feature for passkeys.
Also consider the case where you use Google password manager and your Google accounts gets locked for any (or no) reason. It's unclear whether you can even still use your passkeys, much less migrate them away.
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)
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.
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.
The ability to ban perfectly good software from being used is reducing user choice. It goes against those very ideals: possibilites and consensus. We should not adopt software paradigms that are counter to those.
TOTP is already 'good'. Passkeys are worse because of bullshit like this.
Smells like FUD. Who's providing the ability to ban software? Providers are free to implement authentication requirements like SDC vs MDC the same way they can enforce minimum password entropy or maximum password age.
In practice I'm aware of more 'lock in' behavior in the form of restricting which TOTP client is accepted than for Passkeys. There are many more bespoke 'Authenticator' apps than there are passkey implementations, many of which disallow registering codes in third party wallets.
Bitwarden also syncs TOTP. Given it's the same client, why push folks to opt for a provably weaker protocol with higher potential for user harm?
The people who wrote the spec. If the spec didn't care about what software was being used to handle passkeys, they wouldn't have written in the ability for whatever you're authenticating to to know that.
The spec is bad and the people who wrote it should feel bad.
> In practice I'm aware of more 'lock in' behavior in the form of restricting which TOTP client is accepted than for Passkeys.
I've never seen this before. This reads like FUD to me. Every single site that I use TOTP with (40~ going by the number of secrets I have) didn't give a shit, and I don't see how they could, unless they use Super™ Special™ TOTP™ just because they're so special and wish pain and suffering onto their users. It's just a QR code you scan or a secret you manually type in, which then gives you some numbers you use later, and that's all it should be.
> Bitwarden also syncs TOTP. Given it's the same client, why push folks to opt for a provably weaker protocol with higher potential for user harm?
TOTP doesn't have a higher potential for user harm. If you use it with Bitwarden, the phishing resistance passkeys tout is something you already mostly get (you can still manually copy the code, which I believe to be a good thing, believe it or not).
Given how inconsistently passkeys are implemented and how it's more difficult to get at the actual data being used (unless you export them with Keepassxc (or Bitwarden?), the potential for fuckups is much higher with passkeys.
I'm yet to see someone get phished. It must happen, given that's how passkeys got started. But the far more common ways I've seen are sessions getting snatched and data leaks, neither of which passkeys protect against. It's a marginal benefit in exchange for so many downsides.
It's not FUD. It's just my opinion and a bad spec.
Microsoft, Apple, Adobe, Cisco, Steam to name a few.
>It's just my opinion
Fair enough. I find TOTP to be a PITA. I share your ire with user hostile platforms, but I see the passkey protocol as a net benefit to the status quo. It's unclear how a platform's choice to use a stricter version of the protocol is any different than their choice not to implement RFC 6238 at all.
> Microsoft, Apple, Adobe, Cisco, Steam to name a few.
I use normal TOTP with Microslop. Presumably you can opt into a worse version if you use their enterprise software, if you're evil or whatever.
The rest I presume fall into the bucket of 'wants to cause their users pain and suffering'. That's the normal modus operandi for Adobe and Cicso at least. The only one of those I use is Steam, and I haven't needed to log into Steam in over 2 years, since I'm just always logged in. Fair point though.
> Fair enough. I find TOTP to be a PITA.
I do too. Yet passkeys manage to be even more of a pain in the ass with ominous potential consequences on the horizon. If it was TOTP plus some phishing resistance without any actual downside, I'd have no beef. If it was TOTP but simpler, then there's be negative beef. There are however several clear and present downsides to passkeys. That just makes for a worse tradeoff (depending on your values) rather than a genuine improvement.
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.
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"
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.
Though obnoxiously, the public computer login method doesn’t rely solely on the QR code it shows, but also uses Bluetooth. So if you want to log in on a VM or computer without Bluetooth, or a physically distant computer being accessed remotely, you have no choice but to install your password manager on that computer. Which is a lot less secure than copying a single password and one-time code.
I am less interested in the threat models than the accidental denial of service models. I've avoided passkeys because of that. It seems like there are real problems if you use multiple devices not somehow symced.
I have started using Passkeys everywhere that I can. One of my "requirements" is "do they support multiple key enrollment". Most do, it's sort of required by the spec and semi-required in practice by the giant number of consumers in the US with iOS or Android phones and Windows PCs. The open source libraries certainly push you in the direction of implementing it properly multi-key per user. (I've also implemented Passkey-Only website login.)
I generally add keys from two very different Password Managers to every site/app I use Passkeys with. Both Password Managers also sync between multiple devices I own.
Redundancy is already an option. Choice in Password Managers to use for your Passkeys is an option.
I understand that accidental denial of service fear, but the tools exist technically to deal with that fear if you wanted to try to deal with it.
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?
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.
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.
I think the point is I can make a physical copy of my backup email and password. How do I print a passkey for safekeeping?
In other words, my email can be signed in from anywhere on purpose. It's a feature. The chances of me forgetting my password is zero, because I can back it up 7 way to Sunday.
A passkey seems to miss these basic accessibility issues. For a random website, that's fine, but for the service all of websites use to auth me, access is more important than locking it down to one device.
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.
No, it absolutely doesn’t apply the same way to password. In a PQ world anyone that has your public key also has your private key. That’s not the case with a password and stolen hash.
Yeah, you are right. I don't know what I was thinking when I said that.
Little harsh to say I have NO idea what I am talking about, though.
I still don't agree that companies won't revoke their passkeys if we are in a PQ world.
If they don't, you are still in a better place than passwords. Each public/private key pair is unique for every domain, so a compromise in one place is not a compromise in others. Many people re-use passwords (even if you don't).
Authentication is safer than encryption, because harvest-now-decrypt-later is not available. Currently PQ is not standardized for passkeys, and at least Firefox fails if the authenticator advertises unknown algorithms.
That is my understanding as well but I like to point out:
The private ssh key lives on the hardware it was created on. It never leaves the system. Even root cannot "copy paste" that sucker around and chuck it into a password manager app or even "better" on a cloud service so you can use it on any device you log into.
I liked the idea that passkeys work the same way but now for logging into services like amazon or google etc.
Imagine my face when I learned that that so many interpretations of passkeys exist that actually create that private part in a passwordmanager or chuck it into iCloud or equivalents.
I wondered if the inventor of the private/public keyexchange still lives or if he would spin in his grave hearing what happened...
I would have been on board if the passkeys only existed on your hardware period.
I would have accepted that I would need to set up access from devices of my choosing and therefore cannot log into these services from any old "cyber cafe" on a whim.
But I would, as an emergency BCM measure, expect a sort of breakglass phrase that I could obtain and keep safe like at a bank deposit box or similar in case all hardware with keys to said service would die at the same time.
I understand though, that for most all this would look like way to inconvenient and using the cloud instead is so much more convenient which is why they decided to hollow out the concept of the passkey.
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.
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.
> 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.
Just as your recovery codes already are. It's all just passwords with extra steps.
I don't know my TOTP secrets. They're far too long for me (or any reasonable human) to memorise them. The only way to use them is to have physical access to them (unless I post them publicly on the internet, which I don't).
My first factor is 'something I know'. That it my password to my password manager. My second factor is 'something I have'. That would be my 2FA codes/secrets. I keep backups of both. Someone getting access to my 2FA secrets is extremely unlikely short of someone breaking into my house and stealing my encrypted NAS or my second encrypted backup. That's not a threat I intend to counter with my threat model. On the other hand, getting locked out of an account is a threat I do intent to mitigate, and thus, not having backups is not a viable alternative for me.
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 an 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.
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.
> 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 the 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.
Adding support for something to the spec implies that somebody is intending to do it, or why would they add it? This implies that someone is acting in bad faith (or openly promoting a malicious feature), and the best way for the others to show that they aren't in on it is to evict them from the room and strip out the thing they were trying to insert.
Taking it out doesn't mean you don't have to remain vigilant that they might try put it back, but what does it say if they're unwilling to take it out?
It's in the spec because enterprises use it for corporate authentication scenarios, where they have perfectly legitimate reasons to restrict which kinds of authenticators they want to accept that have nothing to do with the consumer scenarios we're talking about.
Why is remote attestation required for this rather than just not issuing or enrolling authenticators you don't want?
Also, what are the legitimate reasons supposed to be that someone can't use an authenticator that follows the standard protocol but is made by a different vendor? The only thing the attestation actually does is make it so that you can't use e.g. GrapheneOS instead of Android, which has a tenuous relationship to being a legitimate prohibition.
To pick a boring example: you run IT at a big company. You want all your employees using passkey auth, and you want it to be smooth for them, so you buy a bulk order of a couple thousand yubikeys and some glass fishbowls and plop a fishbowl full of yubikeys in the middle of each office.
Attestation means you can trust that nobody is accidentally or intentionally enrolling some random passkey-presenting device with rogue components.
We just had a front page story here this week about folks buying what they thought were secure hardware cryptocurrency wallets that had been modified maliciously.
That's the scenario where you need it the least, because then you're providing the devices and can register the key of each of the yubikeys before you drop it in the fishbowl. Then if someone throws a handful of rogue sticks into the fishbowl, their keys aren't on the list.
Which would further impede the scenario where they have the capability to extract the key from a real yubikey and then throw some of those in the fishbowl, because then even though they're "real" they're not on the list. To pull that off when you're enumerating the keys instead of using remote attestation they would have to go to the office and grab a handful of keys, hope nobody notices that that many of them have disappeared, extract the keys from them and hope they don't destroy any of them in the process since they can't replace them, and then go back to the office to put them back in and have a second chance of getting caught. Whereas with remote attestation they go buy a bunch of yubikeys, break as many as they need to in order to extract the private keys from some of them, then show up once to exchange those for the same number out of the fishbowl since you're only verifying "is a yubikey" rather than "is one of ours".
You also don't need remote attestation to verify that the keys you bought are the expected model, because a key that can establish that can do it locally when you're registering it without involvement from the network authentication protocol.
> 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 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.)
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.
In theory, I guess, but dragging a desktop to my laptop to log in is a bit much. We need a better solution for that.
The CTAP2 protocol has better alternatives, https://github.com/fmeum/WearAuthn is possible because we already can do better. I just hope it'll be implemented at some point (though, realistically, the future is phone-first, despite how much I dislike the implications that carries).
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).
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.
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.
If you work in some hyper secure business that has custom laptops without bluetooth then you should use usb keys or any other of the ways to use passkeys without the phone method.
I’ve run into this issue multiple times, no custom hardware involved. Just virtual machines that didn’t support Bluetooth, and physically distant computers I was controlling remotely.
Which service/website shows a QR code? I don't get one when signing on via Entra to one of customer environments that we manage.
Background: the Entra login used to work fine with password + MS Athenticator notification, but recently it forced me to set up a passkey using MS Authenticator (on my phone)... which was all well and good, except that there's no way for me to actually pass the passkey to Entra, so I end up clicking things multiple times (login using other means, selecting password, selecting how I wish to MFA, selecting Authenticator notification etc).. All it did was significantly increase my login times and fallback to password logins.
So I'm not sure how I'm supposed to log in with the passkey, there's no QR code or anything.
It's part of the OS. The browser calls the API and macos or windows will show the QR code to scan. In theory Linux will get this in the future but I suspect like most things it will take a while.
Either you haven’t actually enrolled passkeys on your account or you are just missing it somehow. I’ve not used windows but the UI is extremely obvious on macOS.
If you try to sign in with passkeys but there are none found on the local machine it will ask if you want to use a usb auth or QR code scan.
I so get the prompt to insert a USB key, but I don't know why, when it never gave me an option to create one in the first place (I set mine up in the Microsoft Authenticator app). There is no option to sign-in with a QR code.
> 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".
You’re saying the majority of users have fallen for phishing attacks? That seems like selection bias. Since you only see reports about successful phishing attacks and don’t see any reports about all the people who log in safely and successfully every day, you assume a “majority of users” must fall victim to this.
It's actually the other way around - everyone likes to read about clever APT attacks, or zero day exploits, or impressive supply chain attacks. But despite what you may read, phishing attacks are the most important.
Consider: most (over 50%) of company compromises starts with phishing (or with reuse of compromised passwords, which are also usually sourced from phishing). It's even higher for ransomware attacks specifically btw. This means that if we were able to stop phishing and credential theft, we would cut number of cyberattacks by half! That's not something you can downplay.
How old are you? At 3 decades of internet use my baseline is falling for phishing about once every 15 years. I would say I am pretty good at avoiding it, but even with that low hazard rate the risk of serious consequence is real.
> 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.
Let's assume I generated the password and that the site is at least using md5 for password storage. Now the attacker does not get my password by breaching.
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.
So password managers work right up until you stop using the password manager. This also applies to passkeys magic protection against phishing. Because of limitations with passkeys, there is always an alternative login mechanism or recovery process and that is just as easy to phish. Maybe easier given the complexity of passkeys and befuddled users.
> 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 don’t have to use a password manager that relies on an account. Personally I use Strongbox on iOS and macOS, which stores everything (including passkeys) in a .kdbx file. I then sync the .kdbx file over iCloud, but if I lost access to iCloud then there would still be copies of the file on all my devices. Overall this is not as secure as the more centralized alternatives, but it does leave me in control.
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.
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.
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 KeypassXC already provides plain text export and Bitwarden provides some export as well. I guess eventually either passkey ecosystem will become locked to a few specific vendors that won't implement functionality FIDO does not like or passkeys will be extractable. In first case it'll become vendor locked corporate standard, in second - same as passwords with url verification.
Or it can stay a niche standard most people don't care much about, we'll see.
I think it's only technical users and paranoid users that care about export. Non-technical users are fine with device auto-sync and Cloud backup/restore, which is what they get today out of the box from the most common Password Managers.
We are in the era where the average non-technical user doesn't even necessarily know what a file even is, they are used to apps managing everything with Cloud sync and "just working".
Export can be handy for "offline" backup, but in practice the thing to backup offline is the device PIN or Password Manager "master password". Especially because in practice you aren't using just one Passkey, you are using hundreds or thousands. (One per host/domain/app, at least.)
> implement functionality FIDO does not like
The KeypassXC GitHub issue wasn't "FIDO", it was one guy acting like he could make threats on behalf of FIDO, without even the full backing of his employer, much less other members of FIDO. It was bad communication to write a suggestion in the form of a threat and pretending to speak for others.
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.
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’m not necessarily a security expert, but my understanding is that passkeys are better in two (or more?) fundamental ways.
- it is linked to a domain, as the article states, which makes it less likely to “exposed” in phishing attempts
- it is a challenge system, essentially a public private key system, so the private key never leaves your device. Kind of like tls/https. Which means that even if bearer/login token is lost, your “password”(private key) isn’t lost.
- also, an obvious bonus is that you get a really long “password” which is practically impossible to guess
I also don't understand why this was the only real downside off TOTPs brought up. "What if you input it in the wrong site?". Surely the exact same thing can happen with passkeys?
Initially I've also struggled with this, and the mental model I found most useful is that a passkey is used to log in into that account from that device.
If the website doesn't allow you to add multiple passkeys then that's bad ux and that's on them.
> but I do know as a user that they appear to be a confusing mess.
I'm a very tech savvy person, and understanding the ins and outs of passkeys has been a time investment, and that's the problem. Technical and security merits notwithstanding, they're a confusing mess. I understand how they work, but what I don't really understand, is how to recover when they don't work.
Selfishly, I end up being tech support for my extended family, and I don't have the stamina to try to explain to them how this works.
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.
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.
When you’re dealing with people so persistently stupid that they haven’t figured out the value of seatbelts, while still generally insisting that the costs of their medical care are socialized, my appreciation for the necessity of social control is enhanced rather than dampened.
When it comes to attestation, it's purely promoting business and state interests against yours. No security comes with it, it's purely control.
Imagine being the owner of a small business who is now required, to do business with any providers, to have a rogue executive that is loyal to them rather than you, and overrides your decisions; your provider refuses to sell you any materials if this executive is not obeyed. Do you think any business owner would accept that? I think on the contrary, this practice would be outlawed by Congress or the relevant legislative body in a matter of weeks. Those who voted seatbelts in.
Then it's exactly that, if you replace business by computer.
You’re telling a story and the story is consistent, but it’s still a story. Besides you’re making a lot of assumptions about me, my beliefs, and what might be of concrete benefit to me.
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.
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.
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.
Not encrypting by default is a ludicrously unstable position as far as trust 'equilibrium' goes. It would be an astounding feat of coordination to avoid needing it as the internet grow, probably one that would cost far more than https.
Conversely, exploiting the the lack of encryption would also be an unstable position because the world then shifts to encryption, voiding your access. So you're trading a one-time benefit to yourself against permanent ongoing costs for the whole world.
I know that humans are poorly equipped to solve these kinds problems, but it still is lamentable.
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.
> 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.
The big situation is enrolling an Apple consumer device under corporate management, which Apple calls "Declarative Configuration" and others call things like MDM. Declarative Configuration can turn on Apple's support for attestation (and is today "the only way" to get Apple's official attestation support).
Declarative Configuration is also the thing that allows the controlling corporation to remotely wipe the phone and other such things where they own the phone more than you do.
I know not every person has the luxury of telling their employers that they will not install corporate apps on personal phones and that if their employer wants to own their phone they should pay for a separate work phone. But that is the big scenario to avoid attestation becoming more common in the wild, making sure people realize that "No work apps on personal phones" is maybe something worth striking about.
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.
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.
"...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.
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.
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.
> 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.
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.
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.
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."
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")
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? USB key says 'no'; you're just an untrustworthy user given the privilege of using their devices.
Not only are Yubikeys agnostic, they cleanly slip from host to guest and present as exactly as expected without a technical fight. Passkeys? I assume they could do this in a few years..
I made some of these points on the original post and just got downvoted to silence. While there are some valid criticisms I guess you could make on passkeys, I think it was pretty clear that the author was being dramatic. Take this quote from the original post.
> In fact there are many different things called “passkeys” and the FIDO Alliance has intentionally named all of them the same thing. I believe this was done in order to deliberately confuse users and encourage them not to look too closely at the fine text.
I don't know how I was this only one in the thread to flag this as just completely unsubstantiated conspiracy. This level of assumption here is hardly worth an entire article, but for some reason people just seemed to accept it.
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.
USB-C is great for charging, which is a huge win per se. Previous versions didn't have the amperage for laptops, and Lightning existed for control reasons. USB-C is not great for everything else.
573 comments
[ 0.17 ms ] story [ 28.9 ms ] threadhttps://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.
> 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.
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.
There is heaps of context missing from this. Did the password manager itself get hacked, or did an employee leak a password for a single site that didn't use 2FA ?? The former strongly solidifies your point, the latter undermines it, and to be clear I don't think it's a good idea to use an employer sponsored password vault either.
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.
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
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.
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.
> 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...
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?
New and interesting ways to get locked out of your system.
"What happens when I go to the same site on a different platform?" = "If you meant device, then Chrome has a feature to allow you to use a different device such as a NFC YubiKey"
"What if I can't use cross-device authentication because I'm on a locked-down work machine or one that simply doesn't have bluetooth?" = "Good, Passkeys are doing their job correctly and you cannot export credentials"
"What if I want to consolidate them all in one platform just for the sake of being organised?" = "Then log in and add more passkeys to things rather than copy-pasting passwords everywhere"
"What if I lose or simply don't have the device with a certain passkey near me?" = "You should have multiple passkey's or use the various cloud versions that exist"
I'm perfectly happy to take responsibility — when using a well-designed system that isn't a massive pain-in-the-arse up front designed for vendor lock-in and to penalize small vendors.
Criticizing the new system isn't avoidance of responsibility, it is demanding a product that is worth using, i.e., NOT designed for the manufacturers to extract more money from us without providing more value or locking in their market position, but designed to be actually useful.
The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows, but every time I'm urged by a site to convert to a passkey, I wonder "is this site the sort that would screw this up?"
So far, it's about 30% of sites screwing it up...
I can’t adopt Passkeys if I’m not certain they’re going to work as well as my password manager and Authenticator app, which is to say 100% of the time.
When sites ask to set up passkeys, it’s usually native passkeys (especially on iOS). And figuring out how to get the flow to set up a LastPass key by default seems unusually difficult.
I also use a MacBook, windows desktop, an iPhone and iPad. I use Firefox, edge, brave across these devices.
When I say “passkeys are a trap” they are a usability trap where no one can attest with certainty that I won’t wake up in a painful situation because I decided to adopt passkeys.
Seems that way. Better luck next year, passkey standards(?) people. Hope it’ll be ironed out at some point.
Good tip!
Going to a concert - I'll take my phone but not my YubiKey, etc.pp
And if I enroll 2 YubiKeys, I can deposit one safely at home. I want my phone to be less important, not more important.
Other password managers do, too: https://bitwarden.com/help/auto-fill-ios/#keyboard-autofill
From a user's perspective, if the implementation sucks, the standard sucks.
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.
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.
Of course the sites presumably will flip the switch at some dreaded point in the future where you can no longer circumvent them, but at this rate it may take a long time to reach a use by majority of users.
Disable iOS passwords and set lastpass as your only password autofill source. It’s far from difficult. In settings under autofill passwords
"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 use this across iPhone, MacOS and Windows, and haven't run into any issues.
In fact I quite like having separate passkeys for each manager instead of one password and -maybe- separate TOTPs (usually not) shared between them
If the solution to smooth passkey use is “spend money” why the hell is anyone going to use passkeys over just using passwords for free?
One domain, one account.
To cover that gap, you get rid of passwords altogether, and now users lose access if the passkey fails to sync or isn't available on one of their devices (let's say a Kindle Fire tablet)
Passkeys being bound to the domain is neat, but not without tradeoffs and practical workarounds. At least that can't be the only aspect to look at when making a choice.
I cannot think of any innovation that has required more defensive pleading for people to use it than passkeys. When a HN article has to be titled "passkeys are not a trap", the concept has already lost.
It is why I never use "sign in with <google, meta, apple, whatever>"
As always you are not compelled to that. Lets others enjoy the convenience of passkey.
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 benefit of a passkey here isn't zero but it's at the minimum.
Meanwhile there are other security benefits as well. With a password, that static credential is transmitted in the handshake. It can be mishandled somewhere in between, and now that entire root credential is potentially compromised. This is just impossible with a passkey. The credential never leaves the client. In some implementations, the credential never leaves a secure enclave, never even entering the client's system memory. You can't say the same for passwords, not even close.
> password doesn't show up you know there's a problem
Here is your contradiction.
The normal person will just assume that some tech isn't working today again.
A key point of passkeys seems to be that it guarantees to the site owner that the user cannot be phished, without having to make assumptions on whether the user is tech-stupid.
If someone only ever saved passwords from the browser UI they really could have no idea how to manually copy a password, while getting along fine.
Well gee how nice for the site owner.
Problem is my priorities are my absolute ability to never lose my most critical assets through some means outside my control, not the site's convenience.
It was ok to use imperfect systems back in the days when the bank and the store and even the government all had a desk a mile away you could go to in person and get anything cleared up and override all possible "usually it works like this" with your physical presense an drivers licence and birth certificate or simply 5 people who all attest they know you.
We no longer have that ultimate backup plan, so really F anyone's attempt to justify basically tricking people into doing something unwise that puts them at actually greater risk because their life is less under their own control, and doing this under the very banner of claiming to care about the users safety!
It's freaking amazing.
What's the point of a passkey that can technically be exfiltrated off a device it was created on? I thought the whole premise of passkeys is that they can't be copied, and hence can be trusted as much as the device access control. Am I missing something?
https://news.ycombinator.com/item?id=50048312
I think that is a big step down from the convenience and friction level that the native password managers get you, where you save your password once and for the rest of your life, as long as you maintain fealty to Apple/Google/Microsoft, your password will always be there in autofill.
In my experience this simply didn’t happen. Many sites support passkeys but only the native passkey stored on the current device, but not a hardware security key. Many sites don’t even allow multiple passkeys, which is frankly required if you use hardware security because you will want multiple pieces of hardware in case one is misplaced.
That's a function of your browser, not the site.
Your point about multiple passkeys is valid though. That affects me too. I use multiple hardware keys but cannot enroll many sites because of this.
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.
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).
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).
Netflix is more incentivized to keep people paying subscriptions than they are worried about people sharing passwords or passkeys. No one "needs" Netflix, it's an entertainment service. If they are truly a bad actor with respect to Passkeys then they upset too many consumers and lose a chunk of their audience.
And to add insult to injury, it wasn't even a single factor login the way passkey advocates promise. The site still demanded a normal password to log in! It was actually 3 factor authentication; something I know (the password), something I have (the passkey), something I am (the biometric).
This wasn't some random website that didn't matter made by nobodies. It was a US government website for managing grant money.
If I'm logging in to your app or service it's because I want to do something. Throwing up a "hey would you like to setup this complicated auth thing before you're able to do anything else?" Is annoying at best.
Then they normally follow it up with a tutorial that blocks the part of the app you need, and a full screen modal to subscribe to their newsletter, and a cookie dialog asking to let you track them, and a popup asking you to rate them on the app store, and...
Only once I've beaten away all the interruptions am I finally able to use the damn app.
That's not a usability nightmare.
That's plainly a nightmare.
Also, the very thing that passkey evangelists were foaming at the mouth 1-2 years ago here assuring me Would Absolutely Never Happen and Is Not A Concern, because the spec says passwords should still work.
To the surprise of exactly no one with half a brain, things didn't play out that way.
> though we're back to a "biometrics as password" problem in many device flows
Meaning if you're detained with the device, you can be legally required (and physically forced) to unlock not just the device, but all your online accounts.
Nothing suspicious here, not like authoritarianism is on the rise or anything, and whoever lives in those countries can get fucked in any case.
>So far, it's about 30% of sites screwing it up...
A year or two ago I was told it'll be 0%.
In 1-2 years, it'll be 90%.
I'm tired.
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.
As someone else said, you'd have to do an email blast and hope users trust the email blast as authentic to trust your new domain.
What do passkeys offer users that rand strong password + password managers don't?
The point is that those attacks would be (nearly) impossible if you have a truly passwordless system.
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 u quiet password on the wrong site if you get phished.
Passkeys don’t get transmitted. They’re used for cryptographic signing.
Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
You can’t store a passkey wrong on the server, it’s a unique public key. If your entire database is stolen, it’s useless. No one else can login with your credentials because they don’t have the private key.
Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
Passwords are fundamentally broken. They cannot be fixed. Cryptography is the solution in passkeys are the implementation.
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.
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.
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.
Can you walk me through how that would work?
Several of the successful attacks that compromised 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.
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.
> 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.
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...
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.
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.
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 likely leverage your weakest enrollment option.
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.
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.
That's not the argument being made.
The argument I'm making is that the only MITM/phishing vulnerability is in the initial passkey registration and not in the auth.
So once you have a passkey and the flow supports attestation, as long as you use the passkey you are effectively immune to MITM and phishing.
Now if you input a password or recovery code or whatever and use that to register a new passkey that's initial passkey registration again and not MITM or phishing of the passkey itself. The reason this matters is because you can register as many passkeys as you want. Say you sign up and log in on your phone. Now you register a passkey on the phone. You want to log in on your laptop, use the key from your phone to log in and register one for the laptop as well. Now you lose your phone or your laptop, you use the other to log you in and set up a new passkey for that device.
Once that initial passkey was registered the auth process is pretty watertight and each device you regularly use gets a new key after auth so you generally always have at least one device that you can use to get into your others.
Now of course if you only have one device and it gets destroyed or if all your devices are destroyed in a fire or flood or whatever then you have to go through the untrusted reset/re-registration flow but in all other scenarios you always default to the passkey-based "use another device you own" methods to register new keys.
TLDR: the point is that you very rarely ever do a true cred reset. The flow itself incentivizes multiple passkey auth methods such that bootstrapping new keys from an untrusted environment is rarely if ever required. This works best for "core services" like your email/google acct/apple acct/microsoft acct where you are generally expected to want access to them anywhere you do stuff so the passkey flow is best pared with SSO to increase the odds you've used the acct on at least one other device.
Phishing sites already frequently target the reset/create-new-password path because it's actually easier to get a user to generate a new password vs. trick their password manager. Plus 2FA is usually required anyway since no 'remember me' cookie is avail so a password reset is equal in difficulty to a password login.
That method still works just fine with passkeys right?
The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks. Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.
Kind of? But it really depends and there's a lot of edge cases the phishing website would have to dodge to avoid breaking the custody chain.
If you force the user down to "use your password/security questions/whatever" to auth and create a new key then yes phishing is still viable here but one of the key advantages of pushing for a passkeys-first approach is that you can make the other auth methods harder. i.e. mandate password + 2FA as a strictly backup method instead.
> The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks.
Yep and passkeys explicitly exist to eliminate this behavior.
> Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.
Well here the caveat is that the phishing website would have to force the user back down to password-auth or security questions or whatever other "weak" method and then use that to create a passkey but not have perms to do anything else.
Now if the phishing site tries to MITM the actual passkey registration flow there are a lot of ways to detect a phishing attempt and terminate the registration and alert the user through alternate contact methods.
TLDR: there are probably still ways to execute a phishing attack but to succeed they have to be far more sophisticated and there's countless ways to accidentally break the passkey auth chain in a way that halts the attack.
It seems like one of those things that only works if you're sticking to one ecosystem.
If the developer fucks up the website/app, that is their fault and not a failure of the technology.
Respectfully, you should consider reconsidering this mindset. The best engineers and tech designs take into account not only how users will use a technology but also how they will misuse it.
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.)
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?
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.
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.
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.
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.
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...
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 https://www.usenix.org/conference/usenixsecurity26/presentat...
But that is not a flaw in passkeys. And there have been bugs in password managers that expose standard passwords as well.
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.
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?
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.
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.
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.
Wrong question.
Users don't use good passwords or even password managers. Users reuse passwords.
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.
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).
If we don't add decent sharing to passkeys then people will continue to use passwords, which is worse for security than adding a sharing feature for passkeys.
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 ...
(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)
Why, specifically?
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.
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.
Then the user still controls the passkey using a password and then everything else flows from that.
Heck, as an engineer even I don't get them. What ever happened to password + yubikey?
[0]https://bitwarden.com/
TOTP is already 'good'. Passkeys are worse because of bullshit like this.
In practice I'm aware of more 'lock in' behavior in the form of restricting which TOTP client is accepted than for Passkeys. There are many more bespoke 'Authenticator' apps than there are passkey implementations, many of which disallow registering codes in third party wallets.
Bitwarden also syncs TOTP. Given it's the same client, why push folks to opt for a provably weaker protocol with higher potential for user harm?
The people who wrote the spec. If the spec didn't care about what software was being used to handle passkeys, they wouldn't have written in the ability for whatever you're authenticating to to know that.
The spec is bad and the people who wrote it should feel bad.
> In practice I'm aware of more 'lock in' behavior in the form of restricting which TOTP client is accepted than for Passkeys.
I've never seen this before. This reads like FUD to me. Every single site that I use TOTP with (40~ going by the number of secrets I have) didn't give a shit, and I don't see how they could, unless they use Super™ Special™ TOTP™ just because they're so special and wish pain and suffering onto their users. It's just a QR code you scan or a secret you manually type in, which then gives you some numbers you use later, and that's all it should be.
> Bitwarden also syncs TOTP. Given it's the same client, why push folks to opt for a provably weaker protocol with higher potential for user harm?
TOTP doesn't have a higher potential for user harm. If you use it with Bitwarden, the phishing resistance passkeys tout is something you already mostly get (you can still manually copy the code, which I believe to be a good thing, believe it or not).
Given how inconsistently passkeys are implemented and how it's more difficult to get at the actual data being used (unless you export them with Keepassxc (or Bitwarden?), the potential for fuckups is much higher with passkeys.
I'm yet to see someone get phished. It must happen, given that's how passkeys got started. But the far more common ways I've seen are sessions getting snatched and data leaks, neither of which passkeys protect against. It's a marginal benefit in exchange for so many downsides.
It's not FUD. It's just my opinion and a bad spec.
Microsoft, Apple, Adobe, Cisco, Steam to name a few.
>It's just my opinion
Fair enough. I find TOTP to be a PITA. I share your ire with user hostile platforms, but I see the passkey protocol as a net benefit to the status quo. It's unclear how a platform's choice to use a stricter version of the protocol is any different than their choice not to implement RFC 6238 at all.
I use normal TOTP with Microslop. Presumably you can opt into a worse version if you use their enterprise software, if you're evil or whatever.
The rest I presume fall into the bucket of 'wants to cause their users pain and suffering'. That's the normal modus operandi for Adobe and Cicso at least. The only one of those I use is Steam, and I haven't needed to log into Steam in over 2 years, since I'm just always logged in. Fair point though.
> Fair enough. I find TOTP to be a PITA.
I do too. Yet passkeys manage to be even more of a pain in the ass with ominous potential consequences on the horizon. If it was TOTP plus some phishing resistance without any actual downside, I'd have no beef. If it was TOTP but simpler, then there's be negative beef. There are however several clear and present downsides to passkeys. That just makes for a worse tradeoff (depending on your values) rather than a genuine improvement.
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.
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"
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.
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.
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.
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.
I generally add keys from two very different Password Managers to every site/app I use Passkeys with. Both Password Managers also sync between multiple devices I own.
Redundancy is already an option. Choice in Password Managers to use for your Passkeys is an option.
I understand that accidental denial of service fear, but the tools exist technically to deal with that fear if you wanted to try to deal with it.
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.
In other words, my email can be signed in from anywhere on purpose. It's a feature. The chances of me forgetting my password is zero, because I can back it up 7 way to Sunday.
A passkey seems to miss these basic accessibility issues. For a random website, that's fine, but for the service all of websites use to auth me, access is more important than locking it down to one device.
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.
Also, the same risk applies, but to an even greater degree, with a password.
Little harsh to say I have NO idea what I am talking about, though.
I still don't agree that companies won't revoke their passkeys if we are in a PQ world.
If they don't, you are still in a better place than passwords. Each public/private key pair is unique for every domain, so a compromise in one place is not a compromise in others. Many people re-use passwords (even if you don't).
I liked the idea that passkeys work the same way but now for logging into services like amazon or google etc.
Imagine my face when I learned that that so many interpretations of passkeys exist that actually create that private part in a passwordmanager or chuck it into iCloud or equivalents.
I wondered if the inventor of the private/public keyexchange still lives or if he would spin in his grave hearing what happened...
I would have been on board if the passkeys only existed on your hardware period. I would have accepted that I would need to set up access from devices of my choosing and therefore cannot log into these services from any old "cyber cafe" on a whim.
But I would, as an emergency BCM measure, expect a sort of breakglass phrase that I could obtain and keep safe like at a bank deposit box or similar in case all hardware with keys to said service would die at the same time.
I understand though, that for most all this would look like way to inconvenient and using the cloud instead is so much more convenient which is why they decided to hollow out the concept of the passkey.
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.
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.
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).
I don't know my TOTP secrets. They're far too long for me (or any reasonable human) to memorise them. The only way to use them is to have physical access to them (unless I post them publicly on the internet, which I don't).
My first factor is 'something I know'. That it my password to my password manager. My second factor is 'something I have'. That would be my 2FA codes/secrets. I keep backups of both. Someone getting access to my 2FA secrets is extremely unlikely short of someone breaking into my house and stealing my encrypted NAS or my second encrypted backup. That's not a threat I intend to counter with my threat model. On the other hand, getting locked out of an account is a threat I do intent to mitigate, and thus, not having backups is not a viable alternative for me.
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.
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 an 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.
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 the 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.
Taking it out doesn't mean you don't have to remain vigilant that they might try put it back, but what does it say if they're unwilling to take it out?
Also, what are the legitimate reasons supposed to be that someone can't use an authenticator that follows the standard protocol but is made by a different vendor? The only thing the attestation actually does is make it so that you can't use e.g. GrapheneOS instead of Android, which has a tenuous relationship to being a legitimate prohibition.
Attestation means you can trust that nobody is accidentally or intentionally enrolling some random passkey-presenting device with rogue components.
We just had a front page story here this week about folks buying what they thought were secure hardware cryptocurrency wallets that had been modified maliciously.
Which would further impede the scenario where they have the capability to extract the key from a real yubikey and then throw some of those in the fishbowl, because then even though they're "real" they're not on the list. To pull that off when you're enumerating the keys instead of using remote attestation they would have to go to the office and grab a handful of keys, hope nobody notices that that many of them have disappeared, extract the keys from them and hope they don't destroy any of them in the process since they can't replace them, and then go back to the office to put them back in and have a second chance of getting caught. Whereas with remote attestation they go buy a bunch of yubikeys, break as many as they need to in order to extract the private keys from some of them, then show up once to exchange those for the same number out of the fishbowl since you're only verifying "is a yubikey" rather than "is one of ours".
You also don't need remote attestation to verify that the keys you bought are the expected model, because a key that can establish that can do it locally when you're registering it without involvement from the network authentication protocol.
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.
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.
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.
The CTAP2 protocol has better alternatives, https://github.com/fmeum/WearAuthn is possible because we already can do better. I just hope it'll be implemented at some point (though, realistically, the future is phone-first, despite how much I dislike the implications that carries).
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.
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).
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.
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.
I do this with my work laptop where the passkeys are stored on my personal phone.
Background: the Entra login used to work fine with password + MS Athenticator notification, but recently it forced me to set up a passkey using MS Authenticator (on my phone)... which was all well and good, except that there's no way for me to actually pass the passkey to Entra, so I end up clicking things multiple times (login using other means, selecting password, selecting how I wish to MFA, selecting Authenticator notification etc).. All it did was significantly increase my login times and fallback to password logins.
So I'm not sure how I'm supposed to log in with the passkey, there's no QR code or anything.
This is why passkey are a failure, no one knows how they work, and even one someone claims they know, the reality is often different.
If you try to sign in with passkeys but there are none found on the local machine it will ask if you want to use a usb auth or QR code scan.
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".
Consider: most (over 50%) of company compromises starts with phishing (or with reuse of compromised passwords, which are also usually sourced from phishing). It's even higher for ransomware attacks specifically btw. This means that if we were able to stop phishing and credential theft, we would cut number of cyberattacks by half! That's not something you can downplay.
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.
Passkeys physically don't allow you to send them to the wrong sites so the sites have to make sure they keep working.
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?
Using all that is just asking for trouble. Turn all off except one.
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.
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").
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.
Or it can stay a niche standard most people don't care much about, we'll see.
We are in the era where the average non-technical user doesn't even necessarily know what a file even is, they are used to apps managing everything with Cloud sync and "just working".
Export can be handy for "offline" backup, but in practice the thing to backup offline is the device PIN or Password Manager "master password". Especially because in practice you aren't using just one Passkey, you are using hundreds or thousands. (One per host/domain/app, at least.)
> implement functionality FIDO does not like
The KeypassXC GitHub issue wasn't "FIDO", it was one guy acting like he could make threats on behalf of FIDO, without even the full backing of his employer, much less other members of FIDO. It was bad communication to write a suggestion in the form of a threat and pretending to speak for others.
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.
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
- it is linked to a domain, as the article states, which makes it less likely to “exposed” in phishing attempts - it is a challenge system, essentially a public private key system, so the private key never leaves your device. Kind of like tls/https. Which means that even if bearer/login token is lost, your “password”(private key) isn’t lost. - also, an obvious bonus is that you get a really long “password” which is practically impossible to guess
Sorry if any of my terminology is wrong here.
If the website doesn't allow you to add multiple passkeys then that's bad ux and that's on them.
I'm a very tech savvy person, and understanding the ins and outs of passkeys has been a time investment, and that's the problem. Technical and security merits notwithstanding, they're a confusing mess. I understand how they work, but what I don't really understand, is how to recover when they don't work.
Selfishly, I end up being tech support for my extended family, and I don't have the stamina to try to explain to them how this works.
Amazon.com, UK, DE, JP, all need different passkeys. Yet my password and TOTP works across them all seamlessly.
And then some pass managers will only store ONE passkey for that login/password.
Its mighty frustrating and while I have been told and see the biometrics make it more secure…
It’s a pain in the arse to now have a stack of domains each in my password manager when searching.
:( In security, you forgo SO MUCH convenience.
Has worked for me every time.
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.
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.
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.
Imagine being the owner of a small business who is now required, to do business with any providers, to have a rogue executive that is loyal to them rather than you, and overrides your decisions; your provider refuses to sell you any materials if this executive is not obeyed. Do you think any business owner would accept that? I think on the contrary, this practice would be outlawed by Congress or the relevant legislative body in a matter of weeks. Those who voted seatbelts in. Then it's exactly that, if you replace business by computer.
You just have to remind the politicians from time to time - the French are a great example in that.
Most consumer websites won't use attestation.
Places where additional security is required (bank, employer, etc) can.
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
That's my guess, at least. I know next to nothing about attestation and passkeys.
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.
I know that humans are poorly equipped to solve these kinds problems, but it still is lamentable.
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."
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.
So the "biggest providers" very much have some champions against attestation.
Declarative Configuration is also the thing that allows the controlling corporation to remotely wipe the phone and other such things where they own the phone more than you do.
I know not every person has the luxury of telling their employers that they will not install corporate apps on personal phones and that if their employer wants to own their phone they should pay for a separate work phone. But that is the big scenario to avoid attestation becoming more common in the wild, making sure people realize that "No work apps on personal phones" is maybe something worth striking about.
hardware-bound webauthn tokens are also important since they are more secure
That's where the trap is.
This is your cue to go get your parents to add you as recovery contacts for their Apple account now, rather than finding out that exists when they lose their phone.
> 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.
One of the most frustrating issues with Apple's UX.
It is plainly obvious that the worry isn't attestation per se, it's the restrictions that attestation may in the future require when they turn the dial on restrictiveness up, that was extremely clear to me from reading the first article. If you can get attestation without those restrictions, "sure, why not", and a Yubikey seems like a way to do that which could avoid those restrictions. Most of this article makes sense, but this particular line makes me wonder how the author got it so far off the mark.
They also did nothing to quell my fears that they will in the future use passkeys to prevent people from using software they can modify themselves by saying "...the guidance for consumer sites has been to not even request attestation for years now." as if everyone always followed the guidance, and as if there aren't tens of thousands of managers that think their case is special and they really do need the extra control because they're a bank or handle copyrighted content or have PII or PCI and feel extra risk-averse today.
I don't know if they failed to do so because they can't (and this is a valid fear of the original author) or if they just are bad at reading the room at what the concern is and vastly overestimate how much people trust companies to always have their best interests at heart.
What I am getting from this, though, is "If you authenticate with a yubikey then that's attested, so they can't use attestation through passkeys to make sure your OS and browser aren't modified", and I'm not sure if that's the correct take away or even a correct statement.
Attestation is never to your advantage. To do it at all, they have to restrict you to a specific set of device manufacturers and yours may not be on the list.
Then, what does it get you? Google-approved Android phones are allowed, but any attacker can trivially get one of those so knowing it's that type of device is completely worthless. All it does is prevent you from using some other type of device.
Notice that this is different from keeping the key in a HSM, which you can do without remote attestation and without the other side having to do anything at all.
Worse, the "approved" devices often have worse security than the one you want to use, e.g. using a Yubikey as your HSM will generally be better than using a phone which has orders of magnitude more attack surface and is constantly connected to the internet, but the phone is way more likely to be on the approved list than the Yubikey.
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.
It is genuinely an ordeal.
> 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.
Passwords just suck. If we're all going to use password managers anyway, what is the point? Might as well use a randomly generated passkey.
>If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that?
The original didn't argue that, nor has absolutely anyone else concerned, nor has that been what has happened in historical examples people were concerned about. Because yeah of course that's ridiculous, it's "boiling a frog" by throwing it in already boiling water, that's not how it works. If anyone has freedom-reducing longer term plans for use of passkey attestation, the emphasis is on "longer term", being malicious doesn't mean being stupid. Step 1 is obviously getting people into the passkey ecosystem and out of passwords at all, which could well take years. And importantly as much as possible into closed passkey ecosystems. This is indeed one of the initial danger signs, because the author:
>iCloud Keychain, Google Password Manager, 1Password, Bitwarden
Is mixing together things that aren't like the other. Quick author, what's the EXPORT story for each of these ecosystems? Of those, Bitwarden can export a passkey into a plain JSON if you want. Do the others support that too, or at best only "app to app" encrypted transfer, creating a closed ecosystem? Already, can I get passkeys from iCloud/Google/1Pass into KeePass? Or is this restricted """for my protection :^)"""?
Author doesn't even touch on the lock-in that's already beginning. And right now everyone can technically claim "oh no of course you're not locked in! You just have to use an official option, or you can merely visit hundreds of sites individually and register new passkeys in all of them". Is it hard to see how players like Bitwarden would be pressured on continuing to offer plain export?
Then when most of the population is using passkeys everywhere in a closed ecosystem, now what is the response if friction slowly starts getting added. OK, you can still use what you like, but only export to other approved players. OK, you can still use unattested, but it's off by default now, "advanced users" can go enable it with this checkbox in the settings. OK, manual is still an option, but now it's buried deep and behind dark patterns and requires a text command. Hi everyone, we have statistics to show that only 0.85% of our users still use unattested keys. The support burden and security risk is now too high."
Like, we've seen this movie before.
I know where my password manager syncs, it's on all my devices. Passkey prompts always seem confusing, I don't know if it's going to save to my browser, or my OS, or if those are gonna sync on what devices. It's just more confusing.
What would I gain from using a passkey?
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")
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 the solution was: make it the user's problem.
Yay.
> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
So if I was Netflix or a bank or w/ever I'd only allow new registrations from "trusted" authenticators, which would incidentally only run on iOS and play-protected Android.
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? USB key says 'no'; you're just an untrustworthy user given the privilege of using their devices.
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.
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.