The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in. If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this. Of course this means you can never be phished for your credentials but if Apple decides to delete your key or you want to leave your iPhone behind, what are you supposed to do?
The platform lock in attempt is wild, my initial experiences with Passkeys were great on iOS and Safari, either getting pushed to touch-id or scanning a QR with my phone. But then in Chrome I couldn't get into GitHub because chrome would only push me to use their manager and wouldn't offer a QR code.
Seeing this more and more with Chrome, like Credit Card numbers used to just save and autocomplete in browser but then they had some popup that was worded in a weird way that tricked me into saying it into Google Pay. Then I had to like type in the CCV to retrieve the card but then it also charged my bank account 1c for the privilege of autocompleting the card each time. Took me good 20 minutes to delete my card, get it saved back in the free local auto completely and shut down my Google Pay account I never knew I had.
I tried. The power-grabbing garbage was immediately apparent and sent me straight for "heck no, I'll just use passwords until they figure this out, at least that can't control my password manager".
In principle I should be very in favor of them, but the wild variety of lack of support for basics, and the built-in-the-spec ability for site X to control how I store and sync stuff is utterly bonkers. It's feeling like the OpenID promise -> OAuth platform lock-in cycle all over again, but compressed into v1.
1Password is a closed-source, cloud-hosted service. At any time, for any reason, they can close and delete your account, leaving you high and dry. Self-hosted, multi-device password managers are the only real solution. Thankfully, Vaultwarden and KeePassXC fill this role perfectly.
Now if we could just get the other providers that require insecure email/SMS 2FA to follow suit, that would be great...
I’m really not sure the “only real solution” is every human needs to selfhost a password manager. That’s ill-advised; an extreme take.
The vast majority of the population will do a worse job on the availability and security of a selfhost solution than 1Password, whose core business and value proposition is password management.
I’m a very happy user of 1Password for Families and consider it the likely the best ~$50 a year that I spend on hosted technologies.
The whole original point of what underpins FIDO2 was device locked, unphishable credentials. Wanting to export and move passkeys between devices is kind of counter to that. And I would argue vendors completing the attestation process are much more trustworthy than storing your own keys god knows where.
Oh, ok. If that's the same thing as passkeys, then I finally figured out that I'm not interested. To me it looks like another vector for platform lock-in, or getting mysteriously locked out of my accounts with no recourse. I'll wait for FIDO3.
Yep. I absolutely refuse to support anything that wants to dictate what I do with my identity.
Such things do have purposes, in high-stakes environments. They prevent accidents. The vast majority of uses on the public web are not even remotely in that realm. It'd be better off being a separate spec that only a handful of internal-only systems use, ideally requiring MDM to set up conveniently (to strongly discourage normal and even high-stakes-normal website usage).
My banking website has absolutely no business knowing and being able to approve or deny what brand my authenticator is.
I disagree. While Vaultwarden may be a bit much to ask of the unwashed masses, the storage model of KeePass* is very easy to understand and works with any existing file synchronisation solution, which almost everyone already has at this point. The effort is nearly as low as with a cloud hosted solution, and the value/safety proposition is quite high.
I also think that the "self-hosted" requirement is an over-reach. It would be sufficient to require some standardized commodity that can, in principle, be self-hosted, but is available in an equivalent form from multiple unaffiliated third parties. E.g., a WebDAV folder.
That's a fundamental problem with cryptographic security: you cannot trust people to manage your keys for you (because due to lack of regulation preventing that companies have this bad habit of pulling the rug under their customers' feet) but you cannot trust yourself doing that either, because you can, and will, make mistakes.
My rule of thumb is if for some reason you need to use crypto keys that can't be easily replaced, you need to have a safe at the bank with the keys stored in 2 differente media formats, that are recreated every year.
I don't trust many people to do that.
I have everything encrypted and self hosted and I sometimes wonder what I would do if I was suffering from amnesia after an accident for example. And having a note somewhere telling me I have a safe in bank X is the only solution I have found.
> I have everything encrypted and self hosted and I sometimes wonder what I would do if I was suffering from amnesia after an accident for example.
Ah! I have the exact same recurring worry, it's very unpleasant. I'd really prefer to keep home media unencrypted, but the thought of a robber seeing my tax returns or photos of my infant daughter is constantly at the back of my mind.
> the thought of a robber seeing my tax returns or photos of my infant daughter is constantly at the back of my mind.
Even worse is the eventuality of them getting their hand of a picture of your ID card or passport, or whatever they can later use to steal your identity. Identity theft is nightmare stuff.
I know how to do that in theory (I've worked with Shamir secret sharing on elliptic curves before) but you don't have the option to do that in LUKS, so in practice you can't use it.
> [...] you cannot trust people to manage your keys for you (because due to lack of regulation preventing that companies have this bad habit of pulling the rug under their customers' feet) [...]
Huh? There's plenty of already existing legal ways to do that. Just leave your key with your lawyer or a notary, and existing regulation about fiduciary duty handle everything just fine. You can also make normal private contracts that stipulate fiduciary duties, courts will enforce those contracts just fine.
As a technical alternative (or augmentation), you can also use a threshold secret sharing mechanism to store your keys amongst your friends and/or with companies.
Now what you can complain about is that there is no convenient way to do all of this. And that's a very legitimate complaint! Convenience is important.
However, the way to get convenience is not via regulation.
> Just leave your key with your lawyer or a notary
> […]
> However, the way to get convenience is not via regulation.
Fun fact: the reason why giving it to your lawyer or a notary works is exactly because of regulation regarding these professions. Without regulations, there would be no such alternative.
I'm not sure what you mean by 'despite all evidence'?
You can also write:
> The blind faith some people have in [regulation and government] despite all evidence always leaves me in awe.
In any case, markets ain't perfect. They are made of people, after all. But they are better than the alternatives. And most importantly: if you don't like what's on offer, you are allowed to get an alternative without going to jail.
> The blind faith some people have in [regulation and government] despite all evidence always leaves me in awe.
The Western world and Asia is a pretty good evidence that government works. If you want the libertarian dream of no government, you can go to Somalia, or South Sudan, or Yemen, or whatever failed states you can think about.
> And most importantly: if you don't like what's on offer, you are allowed to get an alternative without going to jail.
Oh sure you won't go to jail, but the alternative doesn't exists so you can't get it either. Like the convenient safe storage we both wish it existed.
In totalitarian dictatorship, you can't build such a tool without getting murdered or jailed, in totalitarian Capitalism you can build it but it will eventually be blocked from reaching any significant room on the market because of big corps or if you raise money from VC in order to get the marketing you need, it will eventually be bought out by one of the big player who will close or enshitify it.
The good alternative is what's called democracy, where the sovereign people vote for things instead of leaving the power to the party or the market.
I would definitely trust my lawyer with my bitcoin seed.
But the whole thing depends on how much you own in bitcoin.
If it's a whole lot, check how other people in more traditional domains are dealing with their lawyers or notaries handling these sums. (For one, it's a bit easier with bitcoin, because you don't need to tell your lawyer or notary what you are giving them. And you can encrypt the private key data with something derived from an easy to remember password. It doesn't need to be 100% cryptograhpically secure, it just needs to lower the temptation for your lawyer.)
Btw, I think the bigger problem in practice wouldn't be your lawyer stealing from you, but your lawyer somehow losing your data.
Feels. I had half a bitcoin on a disk that I left alone. Forgot about it. Reinstalled the OS. Three times. I was a sysadmin for years, but the cobblers' children go barefoot.
Having the passwords in the cloud is useful though. Before, if you wanted to use your vault across multiple machines, you had to store your vault in someone else’s cloud. This simplifies the process.
Your vault is stored locally on each device, so if they decide to shut down you just export locally, import somewhere else and move on. It’s not as big of a deal as you seem to be implying.
Same thing with google app on ios. My wife saved a password to a site on her phone and we were trying to find it to log in again. Since she had navigated to the site through the Google app, the password ended up in her google account instead of the iPhone keychain - unlike in every other app on the iPhone.
> and shut down my Google Pay account I never knew I had
Google loves that nonsense, don't they? It's as though they think so highly of themselves that they cannot imagine they might not be strictly doing us all a favor by signing us up for their services.
Fifteen years later, I still have friends occasionally sending messages to a GMail address I never asked for, never used, and didn't even know about for most of a year while it was virally spreading through people's address books, silently diverting mail away from my actual address. The only time I used this account, after I discovered that it existed, was to delete it - but GMail apparently still suggests it when people type my name, because I get an "oops, sent this to the wrong address" forward every few months.
No I will not be knowingly using any Google passkey service, but perhaps I will someday find that they have signed me up for it anyway.
As shitified as the world wide web has gotten over the last few years, that's almost a feature these days.
Now you have lots of chaff / ablative / imposter emails to divert away all the robo-mailers, spear fishers, destitute princes, and the like. Even the tiniest little mistake and the email goes to one of a million diversion accounts.
Side Not-a-joke: On this topic, I also really hate two-factor authentication you don't sign up for, don't want, yet are forced to add to your account, because Google Play is too much of SCIF to just let you log in. Even more security theater for the most basic activities. Now I need two-factor every time I try to use GitHub. Ugg.
My wife has the opposite side of this problem coin. Her gmail address (which she does use) has virally spread through a family and circle of friends who all believe it relates to a person in the US who we are entirely unconnected with in any way. Attempts to get them to sort this out always fail because inevitably the address gets re-added to some thread or other and starts spreading again.
Never surrender any email address that a random berk can then claim.
I had my Facebook taken over because I had all notifications disabled and forgot that the email address was associated to it. Some criminal behind an Egyptian IP address took my old email and was in my Facebook within two days of me surrendering it.
The issue is not forwarding the email. The issue is people sending email to the Google address in the first place. As someone who just set up email on his own domain, I'm starting to wish I could search every database and contacts list for my old Google address and replace it with the new one which is actually mine.
That seems like an invitation for long-term pain if Google changes their policies, requiring someone to log in every X months or have their gmail account locked, for example, or some AI enforcement tool locks the account for inscrutable reasons.
I'm locked out of my Gmail and it still forwards to the recovery email address, but I can't get in to change the settings. They also won't allow me to download all my data, as required by statute, because I can't log in.
I've got some active GMail forwarding addresses that I haven't logged into for 10+ years. I don't think they could change how that worked now even if they wanted to.
Odd! I've been able to sign into desktops running Chrome both on Windows and Mac. Both times Chrome will show a QR code that my iPhone scans. The actual passkey is stored in 1Password.
The dark pattern about signing up for google pay is absolutely inexcusable though. Sorry you're going through that.
I think they changed it recently to offer a QR code because checking now it's offering it. But I absolutely had the issue for the first few months of the year.
> Then had to like type in the CCV to retrieve the card but then it also charged my bank account 1c for the privilege of autocompleting the card each time.
I believe those transactions are never confirmed and are reverted after 7 days or something like that
You are able to share an Apple passkey to any nearby Apple device at any time using AirDrop. Passkeys can also be used cross-platform during sign in via an NFC/Bluetooth handshake initiated by QR code.
Additionally, passkeys are just a synced-via-cloud implementation of FIDO2, an open standard that has other implementations you may feel more comfortable using.
For someone who requires being able to sign in to, say, GitHub from multiple different operating systems or platforms, you have a few options.
1. Use a passkey on your primary device, say an iPhone. You can still sign in to GitHub on a Windows computer or Android phone but you must have your iPhone with you. During sign in, there is an option to show a QR code on the Windows/Android, which you will point your iPhone at, and the two devices will do a secure handshake to sign you in. This is probably the worst option from a UX standpoint if you sign in on lots of devices that are not your primary.
2. Use a physical security key to store a FIDO2 key instead of a passkey. These devices are inherently cross-platform. Remember, a passkey is just a type of FIDO2 key. No one is forcing you to store it in the cloud. You can buy something like the YubiKey 5C NFC to store your keys completely offline and under your own control. The tradeoff is you will need to have it with you and you will need to plug it in every time you create an account or sign in.
3. Add multiple passkeys to your GitHub account, one for each platform you want to be able to sign in on. Unlike passwords, where an account generally only has one password at a time, it’s normal and even recommended to have at least one backup FIDO2/passkey registered with an account.
And of course these aren’t mutually exclusive, you can mix and match these techniques, perhaps depending on how important the account is or how/where you typically access it. Maybe you only use a single passkey on your primary device for your bedtime social media scrolling, but use a passkey with a backup FIDO2 security key on GitHub.
Number 2 is not true. I have a Yubikey and it can't be used on Android without a Google made app or account. It's always the same story, give a plausible option to seem open or neutral, but make sure there are "details" that establishes chain of consequences preventing it that is weird enough to allow denying intention. Even though I'm not that young I thought I just need to wait for Firefox to implement it, but as time went by I got curious and found out why it actually can't be done.
I was able to log in to GitHub using a Yubikey on my Pixel without a special app.
Check whether your Yubikey supports resident keys (aka discoverable credentials) and whether the FIDO key for your account was created with residentKey: true, otherwise it’s a completely different (older) flow under the hood, where the private key actually gets sent to the server, and it wouldn’t surprise me if that’s the underlying cause of what’s happening to you.
Thanks for trying to help but I really meant it can't be done, not that it doesn't work for me. This is the starting point for understanding why https://bugzilla.mozilla.org/show_bug.cgi?id=1678045 but that rabbit hole is pretty deep if you want to understand the whole web of consequences.
Wow. I just bought a couple of new YubiKeys for the OpenPGP Curve25519 support. I was looking forward to using the NFC feature with my Android phone. Is it just a Chrome problem? I downloaded some OpenPGP app from fdroid and it says it supports NFC keys.
I'm not sure about your exact situation, lot of the scenarios are OK, just the one without Google services which are dependent on Google account doesn't work. That is actually irrelevant for "normal" phone users that are logged to Google all the time anyway.
I consider myself technically savvy, but I end up with countless different passkeys for different devices, and then multiplied again by all of the different services out there.
I have so many keys scattered everywhere that I would need an excel sheet to keep track of them. I regret not doing that already .. or perhaps I regret using passkeys at all. I am still trying to figure that out.
No, you add a new passkey from Android and then remove the passkey from iPhone.
1. Login with the passkey from your iPhone.
2. In your account, add a new passkey from your new Android. Now both passkeys are active.
3. Login with your new Android passkey.
4. In your account, deactivate the passkey that is stored on your iPhone.
Passkeys aren’t passwords. You can have more than one active at the same time. So instead of moving a single passkey around, you add or remove them to change devices or service providers.
> If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this.
That's not true. Passkeys actually require iCloud Keychain, which is obnoxious, because you can't use the OS passkey support without using iCloud. And you can't even manually export passkeys from iCloud Keychain, which is totally opaque.
So it is still platform lock-in, just not in the way you described.
So use a password manager still (1P). You can have multiple passkeys for different devices or keychains but no entering passwords or credentials. Still an improvement and far less vulnerable.
1Password is a platform, one that has gotten worse over the years. They've taken a bunch of venture capital, switched to rental pricing, and apparently now demand that everything be in the "cloud". No thanks. I prefer to be my own password manager.
Using a good old password means you don't rely on any particular service, period. Passkeys means you do, you rely on either a particular type of device (e.g. Apple device) or a SaaS.
It doesn't matter how many SaaSes offer it or how many brands of devices adopt it. It still means that for access to all of your accounts, you either 1. Have to stay with that brand of device or 2. Have to rely on the goodwill of the SaaS not to suddenly start raising their prices (the comparison here is passwords, which are free).
Before you say that switching providers is possible, that doesn't really matter. Let's say I stored the passkeys on my iPhone/iCloud. And then it got stolen.. whoops! Now I must at the very least acquire another Apple device until I can reach any of my accounts, i.e. I'm tech-dead until I do so.
If switching is not frictionless, it's an absurd level of lock-in, almost making it impossible. I have to go into every single account and add a new passkey? What if I forget one when I switch, then I'm out of luck and can never use the account again?
If you've already got a password manager, what benefit do you get from passkeys?
Avoiding the risks of short, weak passwords? The risks of reusing passwords across sites? The inconvenience of remembering loads of passwords? The frustration of having to type passwords manually? The risk of getting phished or typing one site's password into a different site? Remembering and typing usernames? The password manager takes care of all that for you already.
And if your objective is to have a second factor just in case your password manager gets compromised? A physical button just in case someone takes over your mouse and keyboard? Or a credential stored in a secure element that's (somewhat) protected even if you use it on a compromised machine? Putting it in a password manager (or OS keyring) removes those advantages.
Passkeys can’t be phished, or shoulder peeped, or entered on a malicious domain. And for the layman, it means they can’t forget their password.
Technically the place where you store your passkeys can be hacked into, but there is no technology that protects against that. You could give a tech layman 5FA and he’ll give all 5 factors to the nice man on the phone call.
It cuts out the necessity for a password manager browser extension to handle stuff like autofill, password generation, etc. Those extensions have had fairly significant vulnerabilities in the past. So you're reducing the attack surface, as well as getting a cryptographic guarantee against phishing (the signature the client returns include the domain that sent the challenge).
Edit: The other great part is that the server just stores your public key, so it's idiot proof on their end. It makes a breach effectively useless, since offline cracking is impossible.
Except now you have vendor, browser and device lock in. So password managers are required to solve those very real problems anyway.
The value of these seem very low. Passkeys are a solution looking for a problem.
Mayve 10 years ago before password managers became a thing they made more sense? Now they're just kind of annoying and hard to share (sharing passwords is a real need for many people /applications / services)
Except we're talking about protections against phishing, and as much as I love the clipboard it will paste anywhere you like, including definitely wrong and evil places.
You're wrong, with password managers you can definitely be phished. Unless it's literally impossible to extract the password to enter it manually, but I don't think password managers make that impossible (and if it's possible, users will do it).
Could you expand on how to trick a password manager to enter the password on a fake domain ?
I'd see having the user add the domain themselves, or get the user to copy/past the password themselves on some other form. But the phishing is not happening on the password manager side, and these use cases still exist even after you chose passkeys (i.e. I'd still need to somewhat log into Google's auth from my Nest hub for instance to have it show the calendar)
It happens to me very regularly that a password in my password manager is needed on a different domain. Maybe the logon process is at id.domain.com and password is pinned to domain.com, or maybe the password was created at signup.domain.com and so it doesn't pop up on domain.com, or you have to log in to a hotel's site with the password from their reward scheme (different domain), etc...
In any case users are trained by the internet to need to search for the right password outside the pinned domains. Most of the time I guarantee people don't add the extra domains to the password records. So when a phishing site pops up they'll do the same: search for the site name/domain that they think they're logging into and go from there.
Password managers solve password reuse, weak passwords, etc. but IMO do not solve phishing, especially not for the kind of user who's most susceptible t it (little technical understand, hates this stuff, just wants to follow instructions and not deal with it), but passkeys might.
At least on Bitwarden you can just edit the domain if that comes up a lot for you (or even add multiple domains to a password). I'd rather do that than copy/paste on a regular basis. Honestly I can't say I ever copy/paste.
Yeah, I do this too, but many people I know wouldn't even think about the fact that they could do that, or why they would. They just know that whatever password manager they use doesn't find the password but if they search for it, it's there. So they do that and get on with their lives, inadvertently opening up an avenue for phishing.
These issues won't be solved unless passkeys work absolutely everywhere the user has to authenticate. Logon required or weird and funky domains is currently due to service providers being a mess themselves (I'm looking at you, Microsoft). So should we expect them to miraculously get their act together and have each of these system flawlessly work with their passkey auth. from now on ?
That's where I think we're stuck with that class of issue for as long as there are multiple auth systems, passkeys or not.
There can be vulnerabilities, this is clearly the hottest attack surface of password managers. I remember a few years ago Tavis Ormandy from Google Project Zero found such vulnerabilities in a bunch of the most popular password managers which allowed to steal credentials from a rogue website.
I'd still recommend using a password manager, as overall and in practice the risk of phishing and (re)using (weak) passwords is far greater than this kind of rare vulnerabilities (and also I work for a company that makes a password manager ^^)
The metaphor might be a bit esoteric, but that's similar to wishing that Hardware Security Modules (HSMs) allowed you "get your <private keys>" out of the HSM. As sibling comment says, that's how you get phished. The whole point of an HSM (and a passkey) is that the super-secret private part never leaves the HSM no matter how nicely you ask and no matter how compromised the machine is.
A password manager, OTOH, is happy to hand out your private key ("password" in this case) to anyone that has access to it.
It's a middle ground. You should be able to move passkeys from one vendor to another with some export process but the secret key is not exposed when you use it which reduces the risk of having it stolen
It's not that kind of impossible. It means that even if you are tricked into giving your passkey to the attacker, it's cryptographically useless to the attacker because a passkey is bound to a specific origin.
True, but it also opens me up to using the same password on all machines I use. You can argue that’s a negative, but personally I like being able to add a new machine to my collection without worrying about who the vendor is.
>> Passkeys can’t be phished, ..., or entered on a malicious domain.
> Neither can passwords if you're using a password manager to handle them.
This is absolutely not true, it depends heavily on usage patterns of the password manager and its features. Not all are browser extensions that autofill, and even if they did, sites change their domains for auth occasionally that break this functionality (or more often, signup is on a different domain from auth) meaning you must manually copy-paste your password somewhat often if you don't meticulously, and manually, maintain your domain list for a credential. The average person is *not* going to do that, they're going to go "huh, it broke again" and copy paste their randomly generated password.
Please, do not give security advice you are not equipped to handle.
> Passkeys have no easy way to extract the private key and do not request to enter the private key to authenticate.
Sure the do. All somebody needs is the password to your password manager. It's a single point of failure and by putting your passkeys in there to you've made it even more vulnerable.
Do you put a passkey on your password manager that exists outside of that ecosystem? Once you have that why not just use it for everything?
The parent wasn't giving security advice. They were asking a valid question.
> Sure the do. All somebody needs is the password to your password manager. It's a single point of failure and by putting your passkeys in there to you've made it even more vulnerable.
Not more vulnerable than if they were just using password. You're still missing my point, password managers do not give you the ability to just copy-paste the private key of a passkey into a form field, unlike passwords. Some don't give you access to it at all (*cough* Apple *cough*). Sure you can get the private key if you have access to the password managers vault, but that's not what's being talked about. Common usage patterns matter immensely in security. At the end of the day, the attack surface for passkey-based authentication is smaller than password-based authentication, which is a step in the right direction.
> The parent wasn't giving security advice. They were asking a valid question.
The parent made a blatantly false and dangerous statement and then followed it up with a question. Did we read the same comment?
I agree that it's not more vulnerable than just using a password, I'm only saying that it's only slightly less vulnerable under the best circumstances and incredibly more vulnerable under the worst circumstances (ie. if somebody got ahold of your password manager).
I also agree that passkey-based authentication provides a smaller attack surface than purely password-based authentication.
But putting the passkey on a second device provides an even smaller attack surface since now a bad actor needs both your device (or a MITM attack) and your password.
This is an HN forum. Nobody's giving "security advice," but I do feel like the parent comment's question hasn't been answered. Why would one store passkeys in their password manager instead of on a separate device?
> I agree that it's not more vulnerable than just using a password, I'm only saying that it's only slightly less vulnerable under the best circumstances and incredibly more vulnerable under the worst circumstances (ie. if somebody got ahold of your password manager).
I feel like we might have a mismatch in understanding what a passkey is. You make a new keypair for each account to authenticate to. A leaked passkey is generally no more vulnerable than a password when leaked.
> But putting the passkey on a second device provides an even smaller attack surface since now a bad actor needs both your device (or a MITM attack) and your password.
Correct. The gold standard is a hardware secured, non-cloud synced private key.
> This is an HN forum. Nobody's giving "security advice,"
It's a technical forum with statements on a technical topic. Making statements like that can always be misinterpreted as technical advice by default.
> but I do feel like the parent comment's question hasn't been answered. Why would one store passkeys in their password manager instead of on a separate device?
This is fair. The answer is: convenience. It is most definitely worse security posture to sync passkeys than to store them on a separate, physical device that can answer challenges without leaking the private key.
The reason to use them over passwords is they are more secure, even when synced to a cloud vault.
Thanks for helping to clarify what we're talking about. I disagree with some of what you're saying, but I also see where you're coming from re: the convenience of passkeys in your pw manager.
Password managers should be the default authentication method, and the current hack of having it type text into a password field is both unwieldy and completely avoidable.
The risk of your password getting stolen in between your browser and whatever hash algorithm the service you're authenticating with puts your password through before storing/verifying it.
That's the benefit you get from passkeys that no password manager will otherwise be able to give you.
It is not required that your connection has been MITM'd. The service you are authenticating can accidentally log the plaintext password, they can store it with an insufficiently secure hash function or not salt it. A malicious browser extension can scrape it directly from the input form. Etc, etc, etc.
Passwords are reasonably secure since we've been using them for a long time but there is in fact a huge chain of trust required to keep them secure and links in that chain frequently break.
It's very easy to fall prey to an Evilginx or similar AITM phishing attack. Passkeys or TLS client certificates are the only guaranteed defense. Relying on the user noticing the different domain or the lack of autofill by the password manager, not so much.
No, because they never see anything that needs to be kept secret.
Passwords are based on symmetric cryptography. When you log in to a site using a password you give the site your password in plain text, hopefully over an encrypted communication channel such as HTTPS so that no one between you and the site can see the password.
The site then takes that plain text password and decides if it matches the plain text password you gave them when you created the account or most recently changed your password. If the site is following good security practices they aren't actually storing a copy of the password in plain text. They will store a hash of it and compare a hash of the password you just send to see if the hashes match.
Passkeys are based on asymmetric cryptography, also known as public-key cryptography. When you set up an account at a site to use passkeys your device generates a public key and a matching private key. The site is given the public key and your device keeps the private key.
When you want to log in later the site sends your device some data, your device does a computation on that data that involves the private key and sends the result to the site. The site can recognize that whatever did that computation had access to the private key that corresponds to the public key the site has on file.
The attacker could pretend to be the service the user is trying to authenticate to, issue a bogus challenge signed with the user's public key. That will allow intercepting the user's interactions but by this time the attacker has control over the target system so why not just take what is inside rather than go to the effort of interacting with the user?
Passkeys use public-key authentication wherein the server only stores the public half of a keypair and the client authenticates by correctly signing a challenge sent by the server, which the server then verifies using the public key.
At no point is the private key ever sent over the network or otherwise exposed to any infrastructure or code controlled by the server.
The actual implementation of password managers is really messy. Browser extensions that try to guess which field may or may not contain your username, copy the 2FA code to the clipboard in the hopes that you’ll easily be able to paste it on the next page… passkeys offering a standardized API to provide this information makes it worth considering alone IMO, even without considering the extra security compared to plaintext password.
I've found the Bitwarden to be hit and miss. Some sites work fine with it, others don't work. I haven't debugged it enough to work out whether the problem is on the Bitwarden end or the website end or something else altogether. Given I'm wary of the benefits (or lack of) of passkeys I haven't really looked into it in depth as I have other 2FAs I can use instead.
I think it’s about platform lock-in as well, tightly correlated to pivoting away from cookies due to regs and user pushback.
If you read adtech docs, authenticated user sessions are the gold standard on enumerating user preferences for the sake of ads.
Un/pw friction is noted as a difficulty in achieving this. Cookies developed the way they did in response, +/- details.
If cookies go, then passkeys look a lot like a tangible and realistic solution to enumerating users via authn/z’d sessions, minus the friction of un/pw and a pw manager.
IMO, the impacts of passkeys will feed right into this solution, and while I’m not sure if you can safely argue passkeys are a nefarious plan to replace cookie tracking, I don’t think you can get a tech giant to support such a reimagining of user experience if it didn’t have ancillary benefits beyond solely security use cases. When has a company like Apple or Google ever done such an equivalently large amount of work solely in support of security?
Big problem with this is that enrolling the secondary passkey requires the authenticator to be present. This is super inconvenient and risky as it always requires both authenticators to be present at the same machine/physical location, exposing both to local, physical threats (faulty USB ports on your machine frying anything you plug in? Congrats, you've now fried your main and any backup authenticators before you realized what was happening).
Ideally, you should be able to get an authenticator's public key and be able to enroll one without presenting the authenticator itself, allowing you to keep it in a safe/etc.
This would enable an easy workflow - enroll main authenticator as normal, then enroll your safely-stored backup by pasting its public key. If you lose your main, go to your safe, get your backup and "promote" it to primary and enroll a new backup one which goes in the safe.
It always struck me that 2FA is a corporate suicide pact. Some percentage of users are going to lose their keys per year so your user base is going to decay like a radioactive element.
That’s why most 2FA’s are 1.5FA by default where you can recover via SMS, delayed e-mail, etc, and you can (sometimes) only disable this by clicking through three scary screens and saving your 10 backup codes.
This is why you need to enrol the secondary passkey at the same time you enrol the first one, not later when you might not have the authenticator present.
In reality websites should not allow setting up a single passkey.
Do they typically not? My only contact with passkeys has been the 2FA service (Duo) at my place of work, and I've got a passkey on my phone and laptop, as well as OTP push notifications, OTP SMS, or recovery code from IT. It's particularly handy with the Chromeboxes hooked into the big presentation displays since I can scan a QR code with my phone to use the passkey stashed inside it.
Slightly poor wording from me maybe. There have been cases where for example only one hardware key could be set up but other methods were available at the same time.
I remember AWS having some weird choices at some point too, not sure how they are currently.
But yeah, typically I think most services have had multiple choises available at the same time.
The trouble is if it is on the service to do the support, they can revoke support at any time. They could use start tightening the screws on device attestation tomorrow for business reasons and drop support for your browser or phone.
> The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in.
On MacOS you cannot enable passkeys (or using TouchID with them?) without enabling iCloud Keychain.
I'm fine with iCloud Keychain. But to enable it, you have to enable "autofill form password" which enables it in Safari. Disabling it in Safari disables the global setting and disables iCloud Keychain.
I agree. So far I think KeePassXC is the only one that allows you to export your Passkeys. I believe Bitwarden are working on it as well. That said, it's unclear whether this will provide any portability of passkeys between providers.
I assume each provider will have the ability to import as well as export. The question is whether you can do that across providers. That's not too different from the status quo for passwords and other fields though.
Thank you for posting this comment. I'm saddened but not surprised that attestation is being seriously talked about as a way to get independent password managers in line but not large corporations, and completely agree with Dan there.
Yep, I agree with that response completely. That whole thread is a great read about the reality of the passkey situation, and what it will take to really make it great.
And I haven't seen any announcements in the opposite direction.
————
Edit: so I just checked and I can confirm that it's not possible to export passkeys from 1Password. Neither of the two available export options include passkeys.
> • 1PUX A 1Password Unencrypted Export (1pux) file will export all your data, except your passkeys. You'll need to create new passkeys with your next password manager
> • CSV (Export only certain fields) A comma-separated values file (.csv) will export only certain fields. It won't export data such as custom fields or file attachments.
Well then their enshitification just continues with their unending quest for burning every user-centric bridge they ever built. Goddamn
To answer your question, "bamboo menu, Copy Item JSON" which I believe is turned on due to my "Preferences, Advanced, Show debugging tools" being checked. I actually did try the $(op item get --format=json $its_uuid) first but figured there was some sekrit env var or --fields some_horseshit that I needed to dig up and it was more energy than I wanted to spend for a HN comment
So, OT1H, what I send was half true - they are available for export but only after some hoop jumping and seemingly not in the official export packaging, which I suppose almost guarantees they will not "round trip" back into a Vault in any kind of disaster recovery scenario
It seems those 1Password jokers just get great thrills out of ensuring that anytime I have something to praise them for they ensure they have some user hostile stupidity ready and waiting to drive people away
Wow I confirm that this option appears once I enable the developer options. Don't say it too loud though — I'm sure 1Password will remove it if they notice that it slipped past their view because of just dumping the JSON object.
I wrote the initial .opvault import into KeePassXC and briefly considered going after their local .com cache file (hidden in a very obtuse place, of course) since it seems to be using their same opdata01 <https://support.1password.com/cs/opvault-design/#opdata01> encoding, at least when last I looked, but then suspected that the audience who would have already paid for 1P but wanted to switch would use 1PUX. Seems maybe that does need more consideration
This will be the straw, and now comes the “god how do I migrate off this shitshow” - enshittification pun intended. I nearly cancelled upon their choice to even add telemetry, then they made it possible to disable and off by default (though they still ask to turn it on).
The whole fucking point of a password manager, though, is to store and securely provide authn material while ensuring users can’t lose it… which necessarily includes ability to access it, and back it up.
It looks a LOT like passkeys and FIDO are, relatively effectively, backdooring what Google got beat to death for when they attempted to add “Web Environment Integrity” to browsers.
edit: But can I? I’m already questioning how hard it’s going to be, and if it’s feasible without a lotttt of hurt.
This is why I’m not interested in passkeys unless I can use it with my password manager (which I probably can at this point). It would also be nice to see the spec for these specifically address lock-in and provide anti-lock-in measures.
KeePassXC has support for passkeys now. However I've only managed to make it work with GitHub. Bitwarden does not work for now (although their passkey implementation for log-in is reportedly in beta).
The idea of a passkey is that it's bound to a device, and you can have more than one passkey. Think of a YubiKey, just that you can use your Phone or your PC instead.
You basically have designated hardware that is always allowed to just login to your account...
Because there is no way to do that at scale. If I've tied 200 services to my Windows-managed passkeys and now I want to switch to Linux, I have to manually go to each of the 200 services and ask them nicely to allow me to enroll a second key. This is simply unacceptable - and it's not like I could have done this ahead of time when I first signed up.
I've had a link to OnlyKey's user guide bookmarked for about a year[1]. They're an open hardware company that offers a key. Despite that I still can't be bothered to go through with it. The article we're talking about includes many of the reasons.
I feel bad for the author. They put a lot of their heart into something that could have been awesome.
Honestly platform-locking has so frequently and consistently been the intent of security-washing rhetoric and major breaches have become so commonplace that I now view "security" in the press to be a euphemism for lock-in first and foremost, with other usages being anachronistic or niche
KeepassXC says that it is adding (has added) passkey support. I haven't tested this yet, but if it works, that would avoid platform lock-in. Assuming, of course, that the platforms don't somehow intercept the passkey requests and refuse to allow KeepassXC to do its job.
The big tech companies (Google, Apple, MS) have all become evil.
> Assuming, of course, that the platforms don't somehow intercept the passkey requests and refuse to allow KeepassXC to do its job.
My understanding is the ability to do that is built directly into the spec with the attestation feature. The only thing that might slow it down is Apple choosing to not implement it and zero out their device string. Others can piggy back on that to protect themselves behind Apple's skirt, at least until Apple changes their stance anyway.
Platforms of course could just not allow Apple passkeys and only allow Apple users to use other 2FA options as well. Rest assured that small players like KeepassXC will be the first ones to have their passkeys blocked or not supported.
I've tried it and it works on GitHub. Sites seem to be hit-or-miss for now. Tip if you want to use it with the browser add-on, it needs to be manually enabled and you also need to remove any YubiKeys from the system because it will prioritize them over KeePassXC
This isn't a viable option in practice, because Passkeys use "Resident Keys". This means the credential needs to be stored on the Yubikey - which has a limited number of key slots. Need to log in to more than 25 (I believe) websites? Tough luck!
Because the security key doesn't store any public keys.
Basically, the security key stores a single symmetric key. It'll generate a public/private keypair on registration, encrypt it, and send it to the server. On authentication the server will return the keypair back to the security key, which decrypts it and uses the retrieved private key for authentication.
I'm curious as to why the number of slots is so small. Surely this is not some kind of fundamental limitation on what's possible (or cheap) with hardware?
Because yubikeys were designed long before passkeys become a thing. And hardware people love cutting cost to the bare bone to save one cent of $50 device.
Yes, but that provides a significantly less secure experience. All the important cryptographic operations are done in a regular computer program rather than in a HSM, at that point why bother with the Yubikey at all?
Use a better token. YubiKey is the most popular one, not the best one by a long shot. My (cheaper) alternative supports 300 resident keys per each hardware key.
Webauthn, FIDO, etc. is run by a consortium of corporations whose goal is to be your sole identity provider and own your digital life. Nobody should have been hyped about this crap from day one.
Wouldn't this be solved by just having multiple passkeys for each account?
You create one on your iPhone and another "backup" key from a desktop PC running some open source software. If your iPhone breaks you can always use the other.
Similar to a server configured to accept multiple different SSH keys.
There is a way around this. Password managers. I use 1Passwords and it acts as the vault for all my Passkeys. Can access them on all devices. Super happy with it.
Is there a way to export a passkey from 1P to use in a different manager? (Legitimately asking, I haven't tried passkeys yet due to portability concerns, and this would be good to know)
There’s some hope for interoperability between password managers someday. There doesn’t seem to be agreement on how you can securely export, transfer and import today however.
nope, and that's (currently) by design! from a user perspective, passkeys are supposed to be impossible to duplicate. here are some workarounds:
- you can log into your 1password on multiple devices
- you can sign in by QR code, with the help of whichever phone has the passkey on it
- you can add multiple per-device passkeys to your accounts of interest (for example, log into github on desktop and then add a passkey for your desktop device for that github)
- you can keep all your passkeys on a hardware dongle
- you can set up and keep all your passkeys inside an open-source manager (e.g. KeePassXC)
For first-party systems, passkeys are supposed to be stored in hardware storage (TPM chips, secure enclave, etc). Once it's in the chip, the secret key's never coming out of those pins again (unless you're a nation state with a tunneling electron microscope and a very steady hand).
(The huge exception is iCloud Keychain and whatever Google's doing for passkey sync, but that's importing from account data into hardware storage, not exporting existing credentials from a user's existing device)
Create a new passkey on the device? Or on the new device? I don't see why this is a big issue. Sure, it's slightly inconvenient to go through the 'create passkey' flow on a new device, but as long as the account you are using (let's say, GitHub) supports storing multiple passkeys per account and managing them online, there's no reason you can't.
For every single one of your 100+ accounts? What if you forget an account when doing so, then it's lost forever? If one of the 100+ websites is momentarily down I simply have to keep the old passkey provider around until it comes back up and then remember to switch just that one later?
Are you using every single one of the 100+ accounts constantly? No? Then you can do the passkey flow on demand as needed. It can be comparably simple as an email login or 'we emailed you an OTP' login confirmation flow. If you never get around to using the account ever again in your life, I suppose you never needed it?
If the website is momentarily down how are you going to access it with a password at that moment? You'd have to wait until it came back up. And then you could just as well set up the passkey.
I'm referring to the process of switching where my passkeys are stored to a different place. E.g. moving from them being stored by Apple to them being stored by Google or any other provider.
I think it is true that you can's export passkeys stored in Apple Keychain. However, the statement is false in two ways:
- Apple's iCloud Keychain syncs across devices
- Apple has APIs that allow third party apps to create and offer passkeys, presented as a first-class option in Apple's authentication system. I use this to sync my passkeys between my Mac, Windows PC, and iPhone.
Apple’s iCloud for Windows includes an iCloud Password app which allows accessing and managing your keychain stored passwords on Windows. They also have a browser extension for Chrome and Edge which does autofilling in those browsers on Windows. I haven’t used them in a long time so I don’t know if they have added passkey support to them yet.
I don't sync anywhere because I don't use the Apple keychain for my passwords. No idea if there is a solution for Android but the original claim was syncing between your devices was only possible if you stayed strictly with the Apple ecosystem. This is not accurate since you can sync to Windows even if you can't sync to Android.
However the Windows sync is only possible due to Apple providing an app for use in Windows which suggests its still within the Apple ecosystem. Apple could on a whim decide to discontinue their app for Windows.
Which makes it the same as every password manager except KeepassXC which the passkey community seems to be upset to allow exporting. So commiting to the Apple solution is no different than any other. Passwords are exportable.
Ah, yes, poor choice of words on my part. They are in iCloud Keychain (I think this is required?). But if you only have one device it's basically the same thing, or if you're trying to leave the ecosystem.
Are they not private keys that shouldn't be synced across devices? I thought icloud facilitated automatic creation of passkeys for each device, not actually sharing the same passkey across devices?
That's the crux of one of the debates... members of the FIDO Consortium threatening KeePassXC and other open source tools with blocking for sharing "roaming keys", meanwhile "Oh, Apple wants to share keys via AirDrop? No problem", which is one of the concerns, that it's yet another "push users to Apple and Google's tool of choice".
As I understood it, that's exactly the purpose and not an issue. You are supposed to create a new passkey on each device you have. The fact that they can roam around within e.g. the Apple ecosystem is just some added function that Apple offers.
If I first signup for a service on my iPhone, then want to login on a Linux desktop, for example, how would I login if the passkey is not on my system, and I can’t login on the desktop to say I’m me?
Maybe they sorted all this out so it “just works”, but there seems to be so many potential pitfalls, that I feel like I’d need to spend weeks researching stuff and testing edge cases before I could feel safe using it. No one is going to do that.
With a password, I know it works now, and it will work in 40 years. I don’t have that same kind of confidence with a passkey. Even if it’s great, if people don’t adopt it in mass, it will fade away and be removed, so how deep do I want to go? This isn’t something I want to be an early adopter on, at least not for anything I care about.
> If I first signup for a service on my iPhone, then want to login on a Linux desktop, for example, how would I login if the passkey is not on my system, and I can’t login on the desktop to say I’m me?
What's supposed to happen is when you tell the site you want to use a passkey and one is not available to your Linux desktop's browser you are shown a QR code that you can scan on your phone. The login will then take place via the phone using your passkey that is on the phone for that site.
If you want to test to see if your browser handles this right you can do so at <https://www.passkeys.io/>.
Once you are logged in with your passkey from you phone you should be able to go to your account settings on the site and somewhere in there find an option to add another passkey. You can then add a passkey generated by your Linux browser or your Linux password manager if you use a password manager that supports passkeys.
Some will object that this is not good enough because they might want to login to some desktop they have never logged in from before when they do not have their phone handy.
That's probably not as big a problem as they expect though because unless you are using passwords you have memorized the same problem applies to passwords. I've got over 400 accounts in my password manager, almost all with long random unique passwords. That means I'm not going to be logging in somewhere new to any of those sites unless I've got access to my password manager, which in practice means unless I've got my phone or tablet with me.
I have over 300 in my password manager, and I know there is no way for me to remember all do that, but when I travel I do like to have enough with me so if something happens I can get up and running again.
Once on vacation I shattered my phone. Only time that’s ever happened and I happens to be away from home. I was able to get a new phone at the local Apple Store, but the only reason I was able to get setup and running again was I happened to bring my iPad, by sheer dumb luck. Other than using it for 2FA to get my new phone setup, I didn’t use it at all.
In my most recent trip I brought my recovery key with me, and know my password for that 1 account. As long as I can get into that, I can get everything else setup from there. But I need someplace to start to make myself whole again. It seems like PassKeys make that more risky.
You get a link (or more commonly a QR code) that you open from the device on which you already have the passkey to grant access to the new device. Then you add the passkey for the new device.
FWIW I don't think that this makes passwords redundant in general, but with passkeys, password becomes a last-ditch safety valve to regain access to the account. Meaning that it can be generated, very long, and stored in a way that is optimized for safety and security over ease of access (like, say, an encrypted text file on multiple USB sticks stored in different physical locations).
One big issue with this QR thing is that phone will need to talk via bluetooth to the PC. Like every PC comes equipped with bluetooth chip. Should be some kind of pin code instead.
No, it doesn't. There only communication is happening through the site. The site issues a challenge to the PC, the previously registered phone confirms to the site that the challenge is met, and from now on the site trusts the PC. The PC and the phone can be on different continents.
The problem though is that you have to do this for every single site you access. So if you have 100 log ins and are switching PC or phone, you'll have to do this same dance 100 times in the next period. And of course, if you're switching because you lost your one device that was registered this way...
Edit: everything I say below is not just wrong, but confidently wrong...
"Communicate over bluetooth" doesn't mean anything. What app or BT device would they be using? How would a PC communicate with a YubiKey over bluetooth?
I have no idea where you got this strange concept from, but registering multiple passkeys from multiple devices on the same account on a site requires no communication between the devices - it only requires a trusted device to approve the request.
That's how it works. You open Google Chrome on Linux, press "Log in with PassKey", scan QR with iPhone, then iPhone contacts Google Chrome via bluetooth to do its crypto magic (which doesn't work 50% of times) and may be it'll work.
As I understand it the workflow would be:
* get a new passkey
* enroll the new passkey with all existing services
* unenroll the old passkey with all existing services
That is certainly onerous for the "can my mom do this?" test. Like, I'm not even sure I want to deal with this myself and I have a Solo key (in a box).
Further, seems any service I'd want to protect with a passkey, is also a service that would be very difficult to lose access to, should I lose the passkey (or it fails). Therefore I need to enroll two passkeys with each service, to have one as a backup.
Uhh, OK. So now if I were to change passkey vendors/services - it's enroll two replacements, unenroll two? I haven't ever done this so maybe it's not as onerous as it sounds?
I use 1Password to manage passkeys. It’s pretty nice. They sync across my devices, I can erase one if I need to, and generally with the exception of something odd with Firefox and one website they just work.
Because if you don't want to, it'll get in your way every time you try to use your actual passkey. Oh right, I forgot they added an option - now it just gets in your way every time you try to use your actual passkey on a new device.
Every time I see a long inscrutable discussion about Passkeys, I see a weird avoidance of the "something you know" part of security. Here in the US, courts and law enforcement have every right to get your username, fingerprint, retina scan, face ID, whatever. But they don't have the right to extract something from your brain. Unless I'm missing something basic (which at this point, I don't think is my fault since this whole thing appears incredibly difficult to explain), Passkeys skips past that whole thing in favor of making it a heck of a lot easier to replace "something you know" with "something you have". Which is a security nightmare.
PINs and passwords on HSM keys like this are typically very secure as they will wipe themselves or at least lock themselves after a small number of failed attempts. For example if you only allow 5 failed attempts a 4 digit random PIN has a 0.05% chance of being guessed and a 6 digit PIN is 0.0005%.
So the only real risk is key extraction, hardware key extraction is always possible but likely incredibly expensive, so for most threat models it is not an issue. (Software key extraction or side channels is a different problem which may be easier but in theory is not possible.)
PIN+limit is still a much worse user experience than a password:
- a PIN is hard to memorize, so people are more likely to use personally-relevant or common numbers, whereas a password can be easily be both complex and memorable
- it's easy to burn through even 10 login attempts through any combination of temporary/permanent disability, stress, being drunk, damaged device...
- a wipe-after-failed-attempts system is trivial to abuse, be it by a prankster or a real adversary
- it's much easier to see someone's PIN over their shoulder or film them entering it
No, because passwords are just something-you-know (one factor) while a passkey that’s protected with a password is both something-you-have and something-you-know (two factors)
No, because a password manager still just stores passwords (one factor!); if someone got that password they can get in
The whole point of a passkey is that it’s something you have, not know:
- you can’t guess it because it’s a really long encryption key
- you can’t phish it because using a passkey does not give the passkey to the site, it just proves that you have the key (typical priv/pub key auth)
- you can’t steal it because passkeys are meant to never be moved from the device — it’s supposed to be impossible to extract them, as they’re supposed to live on a secure enclave type chip that is impossible to extract from
Which is exactly where your passkeys can be stored too. Put them in a password manager like 1Password, disable biometrics, and law enforcement would have to enter a password to access them
password managers are growing, but I'm not sure that 'most' people use them. Maybe 'most' software engineers or techies, but the average person probably has no idea what a password manager is.
>”the average person probably has no idea what a password manager is.”
In my experience, that’s a notebook or piece of scrap paper next to the PC with all their usernames and passwords scribbled on it.
That being said, all of the friends and extended family members that I have helped with computer issues have chosen to save several passwords in their browser’s autofill. Yet, none of them knew that they could view and edit these passwords.
Which is a bad idea. Right? That counterpoint defends a bad idea. We should be against the practice of permanently-unlocked password managers, and password managers that are only locked by "something you have". People also create ssh keys with null passwords, but it's also a bad idea and we should be opposed to that.
The State of Utah instructed the jury in State vs. Valdez to infer that a suspect was guilty because he refused to provide his password to the police. On appeal, the Utah Supreme Court ruled that he had the right to withhold his password according to the 5th Amendment, and he shouldn't face negative consequences for doing so. The state appealed that ruling to the U.S. Supreme Court, citing various other state and Federal courts which have made conflicting rulings on this same issue.
Sixteen states (Indiana, Alabama, Alaska, Delaware, Iowa, Kansas, Louisiana, Maine, Michigan, Mississippi, Nebraska, North Dakota, Ohio, Oregon, South Carolina, South Dakota, and Texas) just filed a motion asking the Court to hear the case: https://www.supremecourt.gov/DocketPDF/23/23-1020/307804/202...
Quoting that brief:
"[C]ourts have issued orders requiring persons to unlock devices or provide passcodes. But courts across the country are divided as to whether the Fifth Amendment bars such orders. [...] The Court should grant certiorari to provide guidance on how the Fifth Amendment’s guarantee against self-incrimination applies in the modern context of electronic devices."
Historically, US courts have declared that giving a password is proof that you control the given asset and that this can be incriminating.
In practice, juries will take a refusal to divulge a password as evidence of guilt, the cops will use it as an excuse for even greater brutality, the FBI is perfectly willing to hold you without trial for years on end, and in most cases they don't need it anyway because everything lives on someone else's computer and they're perfectly willing to hand your data over if they haven't already. Furthermore, because the defense is founded on the principle that the password serves as evidence that you owned the encrypted data, if the prosecution is able to prove that you owned the encrypted data in any other way, that protection goes away.
> In Boucher, production of the unencrypted
> drive was deemed not to be a self-incriminating
> act, as the government already had
> sufficient evidence to tie the encrypted
> data to the defendant
I am, of course, not a lawyer. I'm just summarizing easily available information, i.e. wikipedia.
Maybe it's slightly more nuanced than I thought. This (https://crsreports.congress.gov/product/pdf/LSB/LSB10416) seems to be an interesting report on the issue, although in most cases a defendant cannot be compelled to unlock their password-protected device. Biometrics might be different, but honestly, don't use a fucking fingerprint unlock if you've got "sensitive shit" on your device. Duh...
I use Firefox as my browser and 1Password as my password manager. On my iPhone, I use 1Password + Firefox.
I look at https://passkeys.directory/ every so often and switch my logins from passwords to passkeys. This has included a lot of my common logins like GitHub, Google, and Microsoft.
There is a lot of confusing terminology. For some reason sites will say "login with Touch ID" or "login with Windows Hello" instead of "login with Passkey".
Aside from that quirk, I love it. 1Password syncs my passkeys between devices. I can use them both on my laptop and my phone. It would be inconvenient if I needed to login to a shared computer e.g. at a library or friend's house, but I don't do that often enough to care (though of course some people do, which is totally valid).
> It seems like we still have some way to go before we figure it all out.
You're 100% right, though I'm actually surprised that so many sites already support passkeys.
If passkeys is a good idea and consumers use them, then gradually sites will shift over. Changing how everyone in the world does auth is not going to happen overnight, or even in a year.
If your only argument is "wow, it's easy", you're not arguing from the perspective of any kind of security.
I can believe it's easy. But just knowing this doesn't give you any understanding of potential downsides.
Years ago I lost access to various stack-exchange accounts when Yahoo stopped offering Oauth services. Thankfully not a biggie for me but it soured me on relying on third parties for access to a given account.
Honest question, not a critique: what's the point of passkeys if you already use 1password? It unlocks with touch ID both on computers and phones, it autofills and autogenerates username and password. Plus you've got the option to fall back to manual input if you don't have 1password available in a particular device, and credential sharing (outside of 1p) becomes feasible. What's better about passkeys with 1p?
I wish there was a "fast API" for password managers. You can help them autocomplete by using `type` and `autocomplete` attributes in your login form, and there is a "well-known" URL to find the password change form, but I wish there was a way to bypass the HTML page entirely. This would get us 99% of the features of Passkeys I think, where the user only interacts with the password manager's UI.
Also a 1Password passkey user. It is the most portable implementation of passkeys I've used. Still, if you want portability with passkeys you have to trust some company to sync them. I don't want to need to rely on Google, Apple, or Microsoft to sync my keys because those platforms all have some lock-in. Guess 1Password is a form of vendor lock-in too, but it is one I don't mind.
I don't think we should consider passkeys failed already. The widespread rollout just got started, and the ecosystem hasn't had a chance to catch up. Give it some time, and see if things get better.
I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up.
I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not integrate well with password less so it’s best to stay where I am until things settle out better.
People keep trying to answer this question, so I'll try, too, but I'm going to do a better job than anyone else. ;-)
Passkeys are randomly generated passwords that are required to be managed by a password manager. All the major password managers support them, including Apple, Google, Microsoft, Mozilla, and 1Password.
By requiring the passkey to be managed by a password manager, you get some anti-phishing protection. A passkey includes metadata, including the website domain that created it, and the password managers simply won't provide the passkey to the wrong domain. They provide no way for you to copy and paste the passkey into a website, as you can with a password; there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy.
A passkey manager is morally required to do an extra factor of authentication (e.g. fingerprint, Face ID, hardware keys, etc.) when you login to a website, but the website has no way of knowing/proving whether that happened; they just get the password.
You reset your passkey the same way you reset your password, because passkeys are just passwords that have to be managed with a password manager. Some sites make it easy to reset your password, some make it hard. You know the drill; there's nothing new or different there.
If you're happy with your password manager, there's no real need to switch, but even very "sophisticated" password users have been known to fall prey to social-engineered phishing attacks.
Are you sure you're never going to copy-and-paste your password into the wrong hands? I don't trust myself that much.
Passkeys can make it harder to switch password managers because the password managers are designed not to let you copy-and-paste a passkey, including from Google's Password Manager to Apple's Password Manager. I think all the password managers kinda like that, and there's something good and bad about it.
I'm assuming tech people would also like to know that a passkey is not just "a really long password" but also one that's never sent to the server directly - instead it's used in a challenge/response protocol (like SSH keys). Which requires software, either the browser or an external password manager, to run.
I think that's what you're getting at in paragraph 3?
There's no reason you couldn't have an open source passkey manager that allows you to backup and view the key if you really want to. SSH works just fine that way.
It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves.
The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).
> The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).
That's simply false, and there are passkey managers that allow this - KeePassXC for example.
Perhaps this is something I shouldn't be feeling, but this bothers me and I do not know why.
I can see that you might not want it exposed to the user to prevent social engineering but at the same time, if I can't view then I don't feel like I actually own it. Is there a mechanism that might exist to help me not feel this way? I am totally new to passkeys as a concept as well, but I understand the larger goal.
Personally it bothers me, and I don't want to feel any different. If I can't back it up or share it, it's not something I want to use. It's different than something like TOTP where even though I can't functionally hand-calculate it, I can still move the secret anywhere I want
When it comes to Apple, or Google, remember that people keep their accounts (and therefore access to their keys) at Apple or Google’s pleasure; people’s lives can and do get upended when Google decides you’ve done “The Bad” and they revoke your account-and there’s no learning what you did. For your, and everyone else’s, security of course.
The desire for better metadata is good, because you don’t want to hand your password for microsoft.com to microsolt.com when you’re in a hurry and a sophisticated phishing email arrived. Still, as an example, I’m trusting 1Password less and less. They just helped me autofill credentials somewhere they shouldn’t have (thankfully to no ill effect) when the password was correctly set up with website information, basically where something was site1.example.com instead of othersite.example.com. Because they ignored the subdomain.
Their response from support? “By default 1Password doesn’t take into account subdomains when suggesting an item…” and if you’re using their desktop product, there you can go change - per-item (wtf?) - whether it requires exact domain match to fill.
As so many other people here are saying, it feels like a mass lock-in attempt. If it’s not FIDO is doing a really good job making it look that way, especially with “attestation” (which could just be Web Integrity 2.0 if misused).
It feels ... suspicious ... to me that in 2024, we're designing a new authentication scheme explicitly around resident keys, but challenge-response is optional. Credentials in any new protocol should never be sent over the wire, period.
> It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves.
Do you have a source for this? After reading the W3 spec[0] this seems entirely antithetical to the Passkey model and additionally raises concerns about the integrity of hardware mfa devices.
> Passkeys can make it harder to switch password managers because the password managers are designed not to let you copy-and-paste a passkey, including from Google's Password Manager to Apple's Password Manager.
This part right here is what I fear the most about Passkeys. I've read too many horror stories of people getting banned from Google (often for no valid reason) and losing access to all of their data. It is absolutely insane to hand over all your passwords to a company like this.
I have been using passkeys for a while in the form of yubikeys
Best practice is to register two keys to every website. Keep one physically in a safe.
With password managers I would say the same basic practice applies. Make sure you have a working offline backup of whatever secrets you hold dear.
There are some sites that only allow you to register a single passkey for an account (AWS Console last I checked) but these should be getting fixed as it becomes more popular
Yubikey are $50 so if you are already investing real money in your online security it’s not a stretch to expect that people will spend extra time and money to keep a physical backup
I don’t bother with a safe. I have one key that never leaves my home desk and another I have on my keychain. It’s trivial to register the second key when I am home.
Yes it is less convenient than a digital passkey but there is absolutely no way for a remote attacker to compromise it
> By requiring the passkey to be managed by a password manager, you get some anti-phishing protection. A passkey includes metadata, including the website domain that created it, and the password managers simply won't provide the passkey to the wrong domain.
There are so many apps that don't get this right. Make a login on the website, store it in 1password, and then try to login in their mobile app and it doesn't show up as a password because the associated URL is mismatched on the mobile app. Like mybank.com and auth.mybankmobileapi.com
1password has a URL field. All you have to do it add the extra URLs
Better yet, while on mobile, search for the entry of the desktop site and have it fill. 1password will ask if you want to update the entry for this site
Except they ignore subdomains. Unless you fix that on a per-item basis, in their desktop application.
I think, finally, that the reason this feels so dirty-apart from companies and lock-in and all-is that it’s taking the “something you know” as one auth factor and turning it into something that, not only do you not know, the big goal of is to make sure you can’t know but something you have.
I have been using 1Password for over 15 years and it has the ability to only show/fill passwords when on the correct site. The issue is, over time, companies shift their strategies on the web. URLs change, while the accounts stay the same. I have had to update these details many times. I've also run into situations where the browser plugin isn't functioning, for whatever reason, and the only way in is to copy/paste. There are also times where I'm not on my computer. For example, I usually piggyback on my dad's copy of TurboTax each year. When I'm over there, I will often need to pull up a password on my phone and type it into TurboTax as it logs into my bank to download the tax forms. Passkeys don't sound like they can solve that problem. I'd question if the Passkeys would work in TurboTax even if I was running it on my own computer.
With passwords and logins, it seems like there are far too many edge cases to draw a hard line to say they are locked in the password manager forever. Having a way to copy it out, or export, is also a way to ensure portability, if the password manager being used ever becomes bad and a different option is needed.
Password managers put users in a vulnerable position, as once a user is invested, they've got you by the short hairs. The thing that keeps this from being a big problem, is that there is always a way out. Eliminating this way out, or raising the barrier to exit, can temp these password managers to extort their users, which is not good.
This is a huge difference from regular passwords, and the source of a lot of confusion about lock-in.
You can’t easily move a passkey out of the service managing it—true. But you should be able to easily add another passkey from another service. Then you deactivate the first passkey.
It’s a different mental model and the key is in the name. Passkeys are like keys. You can have more than one.
It's not a problem of mental model, it's a problem of scale. If I'm switching phone, the last thing I want to do is to go to every website I have an account on and essentially do a second sign up. This is simply a non-starter, and is a big part of why companies like Apple and Google are pushing for this spec: it nicely ties you in to their ecosystem and gives you a huge reason not to move to a different ecosystem.
I use selfhosted vaultwarden [0] instance (its a rust implementation of the bitwarden server), and the bitwarden apps (i point the apps to use my server instead of bitwarden).
Vaultwarden + bitwarden client apps (for desktop/browsers) have passkey support, and i've been using them for a month or two without any issues.
That being said, bitwarden client apps for android and ios are going through a rewrite (from xamarin to native iirc), and are yet to support passkeys. However, the bitwarden folk said passkeys are the next feature coming to these apps.
Bitwarden, which you can self-host (I do this) seems to have at least partial support now, and I know they're working on improving it. However, I'm not sure if their client and server are both fully FOSS.
... with some of the functionality of SSH keys removed, like being able to use one key for many accounts, or many keys (on many machines) all for the same account.
>But not the second: on Github for example you can have multiple passkeys for the same account.
People mention the "only a single passkey instead of multiple passkeys" issue because they run into some websites such as PayPal that only let you add one passkey. E.g. :
Unless I'm missing something these are nothing like SSH keys. They would be closer to regular password auth with SSH where you store the password in a file that's only readable by SSH.
SSH keys are asymmetric such that I can make a public half available publicly and then use that to generate signatures of any challenge the server sends.
With passkeys either the server needs to store the value raw(making it susceptible to data breaches or malicious actors), or store the hashed value(making it impossible to do a challenge-response, and making it susceptible to MITM/replay attacks).
It seems to be all the downsides of SSH keys(aka losing it having implications), with none of the upsides, plus additional downsides(hardware devices can only generate 25 unique ones instead of using 1 and sending the public to all services with confidence it hasn't exposed any private info).
> there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy
This is a deep, fundamental flaw in passkeys. It's just another example of enshittification disguised as denying end-user control "for their own good." There is no for-profit organization anywhere that I trust more than I trust myself, and there's no threat model where it's more likely I'll be socially engineered into giving up my long random password than that I'll suffer data loss.
Good for you; I'm ashamed to say that I've hurt my data sanctity far more than any criminal has, with 2am tinkering with my systems.
I have vaultwarden at home but I don't use it because I just know I'll fuck up my tunnel while I'm travelling or something.
This is my threat model: "hi mum. I need you to drive to my house and fish a keyboard out of the cupboard. Plug it into the big black box and type exactly what I tell you..."
I feel like most of the replies to your comment talk about the technical aspect of it.
What’s stopping me is that I don’t have a mental model of the management of the passkeys for the whole lifecycle of my account. Can I use it cross platform? Can I allow someone else to use the same account? What happens if I lose or don’t have access to my phone or laptop? What if I die, can my spouse log in my accounts?
With username/password, it’s very clear what I need. I could write it on paper and give it to someone and it’d work. I feel more at risk of losing access to my accounts if I were to switch to passkeys, because I don’t fully grasp their long term lifecycle.
> I feel more at risk of losing access to my accounts if I were to switch to passkeys, because I don’t fully grasp their long term lifecycle.
It's my understanding that you can't switch password managers without generating a new passkey for each individual service you use (I'm not an expert here, so someone feel free to correct me). That's already enough for me to not switch.
This is why, for me, the problem is not the passkey model per se as much as it is the inability to export/backup/convert my iCloud Keychain database to another account or platform. Apple could arbitrarily delete my data or lock me out of my own account. Or it could just randomly break with no solution besides deleting the database and starting fresh. And according to the author, this has already been occurring!
>Externally there are other issues. Apple Keychain has personally wiped out all my Passkeys on three separate occasions. There are external reports we have recieved of other users who's Keychain Passkeys have been wiped just like mine.
> I’ve avoided passkeys so far because I just don’t have a good mental model of them.
OK, so the simplest way to understand is to first know about the previous generation.
U2F keys are designed to be used alongside a username and password, as a more secure replacement for phone apps showing 6-digit codes.
In U2F the key has a hardware 'secure element' where secrets can't be extracted, even if you plug it into a compromised machine. You get a separate public/private key pair for every account and website (so it can't be used to track you between websites) and that key pair can be used to authenticate with the website. A physical button has to be pressed to authenticate, keeping it secure even if an attacker has control over your keyboard and mouse. The browser integration takes care of letting the USB key know which website is asking to authenticate. U2F keys have to be used alongside a username and password.
For a variety of reasons U2F keys never really took off. Partly cost, partly the 'what if I lose it' issue, partly lack of uptake by websites, partly difficulty using them on mobile, partly competition from 'log in with google' type systems.
So the trade group behind U2F said "Hey, maybe we could just emulate the hardware secure element in the smartphone's OS? And while we're at it, we could save the username, and use fingerprint/faceid instead of a password, eliminate that tedious button press, and automatically back up the public/private keypairs to the cloud". They kept a USB option about for the sake of tradition, but it's on life support.
So that's the mental model of a Passkey: It's like an impossible-to-clone USB hardware secure element that does challenge-response authentication to websites. Except it's emulated in OS software, and is no longer impossible to clone.
Another way of thinking of it is: It's very similar to using the 'Log in with Google' / 'Log in with Apple ID' buttons you see on many websites, you're authenticating to a service by proving you have access to a cloud account. The implementation details in the background are very different, but the result is broadly the same.
> "and use fingerprint/faceid instead of a password"
This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now?
Security guru Bruce Schneier has written about this w/ much more eloquence and authority.
The fingerprint/faceid is just a local proof to unlock the actual asymmetric encryption key. It is not your actual identifier to the remote server. So if you need to redo your auth, you just rekey and stash the new key in your authenticator (or have your authenticator originate the key material and never expose it to main memory at all).
Think an SSH key protected by a passphrase. Your passphrase isn't the thing that actually logs you into the server, its just what you use to unlock your actual key material you use in your SSH handshake. Your fingerprint/face identity is just your local unlock of the actual key material stored in some other secure enclave.
Not quite. It's easy to create a duplicate of your metal key, and many people do exactly that to avoid a situation where they lose it and have no way of opening their door. The fact that you can't do that with USB keys is my biggest gripe with them. I understand that inability to copy even if you have physical access to the original has its security advantages, but 1) most things don't actually need that much security, and 2) it could still be done by e.g. allowing you to buy them in premanufactured batches where all keys are identical.
Somewhat personal ancedote, but I've had pretty good experiences with Yubikeys. I've had one on my daily keychain for over a decade now. Its been run through clothes washing machines too many times to count, I've left it out in rainstorms, its been baked in the sun on hot summer days multiple times, its been dropped in pools, its been run over by a car, I've dropped it some pretty significant heights while hiking. It is still working just fine. That and a PNY 16GB metal keychain flash drive have taken a ton of abuse and are still working just fine. Other than a higher melting point or ability to take high energy RF I don't imagine there is much more abuse a traditional metal key would have compared to what I've done to my Yubikey.
Maybe it’s the old USB version? I haven’t had so much luck… I had a couple of nanos, and those broke pretty quick. More recently, I switched to a usb-c version…. And while it still works and stays attached to the key ring. The plastic housing has broken already. I got a corp branded one now, that I’m trying and seems a touch more robust
I've only had the full USB-A style ones. Every device I've had that I've needed a yubikey with has either a USB-A or supported NFC. The >1 decade device is a Yubikey NEO, I recently got a Yubikey 5 USB-A variant and also have one of those FIDO-only blue Security keys in USB-A.
What kind of failures did you have for the nanos? They just became unresponsive? Did they suffer any obvious physical failure or any particular kind of event cause their failure?
If there was a NFC only version of these (and laptops came equipped with NFC), then we could make a block-of-metal key. No ports/holes and no buttons. Would be water proof and crush resistant. Assuming that you can send NFC signals through metal.
The biometric stuff is simply allowing access to the keys. It’s not being used for anything else.
Your face or fingerprint being out there isn’t a concern because that’s not, ultimately, the thing being used to generate the keys or anything.
It’s an ease of use function.
On iOS for instance, as I understand it, these are being stored in iCloud Keychain. Which has a password. The derived key for iCloud Keychain is stored in such a way that the system has access if you allow biometrics to be used.
Biometrics then simply allow access, in essence, not part of the encryption process. The password for iCloud Keychain is necessary to add those items on a new device. Your biometrics aren’t stored by Apple anywhere other than in the device.
Honestly I am blown away how few people on this site understand how this stuff works. It’s fascinating and I’m surprised more people aren’t interested in understanding it. But so many people assume the biometrics are being used in the encryption process and that if your face is somehow stolen your whole life is doomed. These features have been on Apple devices for what.. a decade almost at this point? More? The process for Face ID is the same as Touch ID. Developers make zero distinction between the two in code, as that whole process is passed off to the system and effectively results in a bool value (or access to the secure item requested). At no point does a developer ever get your biometrics data.
I don’t know how Android or Windows do it but it is similar enough I suspect.
The FUD around passkeys feels like some sort of propaganda campaign to discredit it.
Agree. I actually wanted to acquire a biometric signature to do something with it on iOS and was super bummed once I dug in to see how it works -- all Apple exposes is a function that returns true or false hahaha
This is the part where you have people dismissing a security from a simple assumption and reverting back to another assumption of their current state. Is still dangerous
Your fingerprint/faceid/whatever is used to access the passkey. It is not the passkey. To that end, yes, if you are worried about clandestine access to your phone (if that is your passkey), then you probably don't want to allow access using fingerprint/faceid. And if someone can copy your passkey off of your phone, you are again compromised.
Your faith in humanity seem low, because this would never be pushed worldwide by security experts who eats and sleeps it, if it was so easily broken where you just figures it out during a comment
This sounds, to me, like a really bad and convoluted way of storing pub/priv in a password manager, and hoping the software implementation gets it right when it's trying to manage these things for me because I'm too dumb to manage passwords and too hobbled by bad IT policies that want to change my passwords every 4 weeks.
Eh, somewhat. The lost key account recovery story is much better in large organisations, where you have a 24/7 helpdesk that can check your ID badge in person, a HR department with a photocopy of your passport, and suchlike.
But for example if you're using Azure/AD? No U2F + Password allowed, gotta go straight to "passwordless" [1].
So they never took off far enough for Microsoft to support them.
The big question I have is are the keys device/browser specific?
Seems to me I need to be able to log in with a password from any place (my phone, my machine, my office, my wifes phone, her laptop, my friends laptop, etc.).
I mean, who knows when I'll want or need to get into Something.
Also, my wife and I share accounts (such as Amazon). So, it needs to work seamlessly across all of her devices.
Then there's always the "F-with it factor" that I loathe. At least I understand passwords. Can (mostly) always recover a password (I recall trying to recover my Apple ID password -- they bluntly said "ok, but you have to come back in 2 weeks", so I was locked out for 2 weeks).
And, of course the level of patience my wife has with Technology is less than zero.
I rely on my Safari auto fill, when I use another browser, I just copy the pw from Safari.
And I don't use any of the cloud services. I have an iPhone, but don't use iCloud.
A few weeks ago, I was unable to log in to Google on a new device with my 2FA token (Yubikey) because Google insisted on authenticating with a passkey/resident key, but the token had only been set up with non-resident TOTP or whatever it's called (and had been working properly in this mode for over a year). I was able to log in on another device and register the Yubikey with a passkey/resident key, but it was really scary! There is so much complexity here, and so little visibility and control afforded to users, that I feel very uncomfortable trusting it as my only login method for any moderately important service.
It's possible this was a Mac OS problem, but I don't think it really matters. Either way, this stuff needs to be absolutely rock solid and frictionless if normal people are going to use it safely, and it obviously isn't.
It's a Google sign-in workflow problem. I've seen the same issue more than once - for whatever reason it decides that this one way of signing in is the one that you want to use right now, and it can be impossible to back out until some timeout kicks in.
I'm not entirely sure Google is trying to "make it right" so much so as funnel users to its own products (i.e. Android devices and Google Authenticator).
The super simple explanation is: SSH keys for websites.
You have a unique private key for each website account stored on your device, in a local password manager, or in a cloud synced password manager (iCloud account, Google account, 1Password, etc).
The website only gets the public key, so unlike password auth your secret is never given to the website.
When accessing that website, the website can send a challenge which your browser answers using your private key associated with that specific domain.
(I'm not a passkey expert and there are a lot more technical details to this, but this is my 10,000ft mental model of what's going on)
It's still not a great multi-platform/multi-device story. I use multiple machines regularly (and I've migrated away from 1Password to the KeePass ecosystem, by the way) so syncing passkeys from my Mac(s) to my iPad, to my Fedora machines and my Windows working environment is simply not happening any way I look at it.
Passkeys are great for consumers who use one or two devices (or browsers - I also switch browsers frequently). For anyone with more than one platform or one device in their lives they suddenly become added complexity, because even though you _can_ have more than one passkey per account per service, in practice there are all sorts of weird edge cases.
You shouldn't ~~necessarily~~ need to "sync" your passkeys across all your devices; each device should have its own passkey. Then if you lose a device (or that one device gets compromised), you revoke the one key and everything else is fine.
Similar to SSH keys. No reason to use the same key on all your machines, use a different key from different places.
The passkeys on my laptop are different from the passkeys on my desktop which are different from the passkeys on my phone which are different from the passkeys on my main yubikey which are different from the passkeys on my backup yubikey.
Edited due to acknowledging people may choose a variety of alternative workflows.
> You shouldn't necessarily "sync" your passkeys across all your devices; each device should have its own passkey. Then if you lose a device (or that one device gets compromised), you revoke the one key and everything else is fine.
If he's storing his passkey in his password manager, it wouldn't matter that he lost the device. They can't get to it, it's AES-somebigassnumber-ed up the wazoo. If the passkey is cached outside of the password manager, then passkeys are a horrible idea, where you have to "go home and call the 800 numbers to cancel the credit cards", and worse still, people with few devices might end up in circumstances where they have no valid devices left to bootstrap access.
I am resigned to the fact that I will die with humanity never having solved the problem of passwords adequately, but being that I will live another two decades minimum, I will get to see two more of the stupidest possible non-solutions.
That's assuming the user does have a strong passphrase to protect their local password safe and the device wasn't compromised while the password safe was in an unlocked state.
If an attacker managed to get root on my machine right now, they'd get my whole password safe as its currently decrypted and in memory. However, they wouldn't be able to access any of my passkeys.
And if they get the passkey's private key, when you're signing some ticket to send off to prove identity? That has to be unlocked for that too, it's in memory somewhere.
Then they privilege escalate, lock out all your other devices after adding a new one, it's the same issue. And it's opaque, reinforces the ideas that users are too stupid to do anything right, so that we shouldn't even try.
> That has to be unlocked for that too, it's in memory somewhere.
Its in-memory on my physical hardware token or a TPM or a secure-enclave, which only activates and unlocks after a valid identity challenge (fingerprint, physical touch, face scan, pin, etc.) not my main system's userspace memory. A massively different target.
I use far more sites than I ssh into servers, which makes this much more of a pain. Like, every time I sign up to a site I need to grab all 5+ devices I might ever use and add them to every site, or I can't e.g. log into my D&D game while travelling because I forgot to generate a key on the work laptop? If all my devices are destroyed in a house fire again, I'm locked out of everything? These have been my big concerns.
> every time I sign up to a site I need to grab all 5+ devices I might ever use and add them to every site, or I can't e.g. log into my D&D game while travelling because I forgot to generate a key on the work laptop?
You don't need to log in to every app on every device the instant you register a new account. Just make a passkey on a couple of devices that you're likely to have around and you'll probably have what you need when you need it. When I register on a new site that uses passkeys, I might create a key on whatever computer I'm on and a portable authenticator like my phone or my security token.
So, say I'm at home on my deskop, and TotallyCoolService has the option for a passkey. I'll make one on my desktop, and then go ahead and make one on my security token. Later I'm out and I want to check in on TotallyCoolService on my phone. No worries, I just tap my security token to my phone and I'm logged in. Later I'm in the garage working on my motorcycle and want to reference something on TotallyCoolService on my laptop and my USB token is in my backpack inside. No problem, I can sign in with my phone. Now I've got security tokens on most of my common devices and its not like I had to spend time gathering all of them at account creation.
I don't instantly run home to my desktop and log in the moment I sign up for a new site while out and about. But I do go and sign in eventually, even if only to ensure there's a backup key there.
This really doesn't contradict the problem of needing to sort out M sites x N devices, where M can be very large.
Whether you do it eventually or do it straight away. Unless you can predict which devices you will have and which sites you will need access to at any given point, then it degrades to needing everything authenticated just in case.
I'm pretty much never too far from either my phone and my security key, seeing as how at least my phone is my car key and my wallet the majority of the time and a security key lives in my backpack.
Sure, M devices can be quite large, but the odds of me being at only one device and not any of my portable devices is extremely small. As long as I have at least one other device I've previously logged in to somewhat handy, I can still easily get in. Maybe that initial login is marginally more complicated, but IMO the ease of future authentications more than makes up for the small bit of initial friction the first time.
And in the rare instance where I'm suddenly on the moon and realize I left practically every other computing device and physical authenticator on another planet, I guess I just won't have access to a DnD tool. Oh well.
> No worries, I just tap my security token to my phone and I'm logged in.
What allows you to tap your token on your phone and register a passkey-stored-on-phone registered with TotallyCoolService? Did you previously set your phone and token to be "mutually trusted devices" in some way?
Or what's preventing a thief from tapping my token on their phone to register it on TotallyCoolService?
I see. So the weakest link in the security chain is that someone discovers the <6 digit pin on your usb key (easy on a security camera), and then manages to steal it for 2 min.
Not terrible for anyone whose threat model is not targeted attacks. But quite bad for people whose threat model is exactly that.
Great in theory, but in practice there are still a frustrating amount of websites and services that put a low upper limit (usually just one or two) of the number of keys you can enroll.
This effectively makes it impossible to do what you’re saying. It sucks.
I hear this a lot but it hasn't generally been my experience. The only site I've personally come across that supports webauthn/passkeys but doesn't support multiple is the AWS management page. Which I essentially bypass by just configuring SSO and using an IdP which does support it.
Every other site I've come across that supports these things supports multiple. What common sites support only one or two?
Yo. Thank you so much for posting in this thread. Turns out I was thinking about Passkeys wrong this whole time and you're the first person (I've seen) to really explain this workflow. Thanks again!
Actually, I much prefer to use the same SSH key for deployments from any of my machines, so that example doesn't really work for me (I do have multiple keys).
The first time I log in to a service on a new device it'll prompt me to sign a challenge with a previous passkey. If I've got my yubikey handy I'll just plug it in and sign it and add a new passkey to my new device. If I only have my phone the site will flash up a QR code I scan with my phone which signs and posts back the proof to a callback URL for the site. I only need to do this once per device if I add a passkey to the device.
Is the fact that you need access to an already- enrolled device to create additional passkeys part of the threat model that passkeys resolves, or just an annoying detail? And is this for every site, or just once per device? I can just look it up, this thread has been great to improve my mental model enough to start considering trusting it.
Its per-site. So the first time I log into GitHub on a new device, I need to do the handshake with another device. The first time I sign into Coinbase, I need to do the handshake with the other device.
So this typically means when I get a new device I'll have my Yubikey in a bag or something with me for a while and pull it out from time to time. Eventually practically every site I use gets enrolled on the new device and I never actually need to reach for the Yubikey or my phone or whatever.
I don't really make any concerted effort to go through each and every account when I get a new device, it'll pretty much just happen eventually. When I do sign up for a new account that supports passkeys I do try and make an effort make a passkey on at least two devices though, often at least whatever device I'm using to initially register and my yubikey. Then I'll make a point to log in sometime in the next few weeks on another computer and create a passkey there. Eventually I'll probably end up logging in and making passkeys on most of my devices.
Needing to auth with an existing passkey is a major part of the model. If you could just log in and create a new passkey with just a regular password, what's the point?
I've installed KeePassXC on my Mac and Linux machines and it stores Passkeys. Low-tech syncing is by Signal Notes to Self. If there were an audited app for iPhones I'd still be using that method; there isn't, so I've moved to Bitwarden. Passkeys seems to work fine on Bitwarden.
I currently use the 1Password passkeys, and when they work, it's pretty good. I get all the fun of showing up on a website, and with three clicks, I'm in. But I've used them on just a few websites (email and GitHub), and they work correctly maybe 10% of the time.
First, I had to figure out how to get the website to request the passkey. Then I had to figure out that I didn't want to use the browser's passkey but 1Password's, which is different on different browsers and platforms. And good luck if I'm on mobile, I don't think it's ever worked.
At this point I'm taking a break from signing up new passkeys. I'll stick to UN+PW+(TOTP|Yubikeys).
PS: Why is it that no financial institution lets you use anything more than a SMS U2F?
How do you back up the private key? With ssh I know to back up .ssh with the rest of my home folder. With a passkey I'd have no idea where it was, and get the feeling the "modern" software won't tell me on purpose, so that it can manage/sync it for me. Which leads to a lack of a mental model.
KeePassXC is not Big Tech. It is open source and self-hosted. It supports exporting the private keys, although Big Tech is not happy about that feature: https://news.ycombinator.com/item?id=40167782
Nice phrasing, I lack that mental model as well. Anyone here willing to distill down the whole thing to a few sentences? Who stores what kind of secret, and is there some kind of challenge/response at auth time?
A physical device which is not your computer stores some secret information which can authenticate you. This can be passwords, passkeys, GPG keys, your retina etc.
The physical device can be password protected. So you have two step authentication:
1. your physical device
2. your password to that device
Phones are currently being promoted for various reasons, but I believe something like Yubikeys or other FIDO2 fobs will be a better device. You can have multiple of them, you can store one of them in your bank safe. Someone stealing it of you is proper theft which can be traced in a usual manner by police. Stealing is not enough because you still need the password. The difficulty of asking you for password remains equal to difficulty of hitting you with a wrench. You don't need to remember stuff anymore, because you can just use your physical keys. You will need to travel with those keys, but its just same as your house keys. It is probably an extra key in your key fob.
To add to it, the U2F/FIDO2 standard will make it vendor independent, and so no lock-in.
What I find rather confusing is what happens on each device. There appear to be multiple places where passkeys can get stored (iCloud Keychain, Google account, Chrome profile, Bitwarden, ...?) and depending on where it's stored it may or may not get synced to various other devices, browsers and apps.
So my problem is that I keep forgetting which device, browser or app I used when I created a particular passkey. I'm never asked where I want to store a particular passkey and where I want it to be available. This is all an implicit function of a combination of factors apparently.
It's like misplacing my keys has been taken to a whole new level of abstraction :-)
Many places let you enter and name multiple passkeys. So you as your keychain one and name it "keychain". And also add phone and call it "whatever phone" then use either.
Personally I only use devices that don't sync and can't be copied for security reasons.
Safari on macOS uses passkeys without phone. So unless you consider security chip inside macbook a separate device, that's not true, that's just one of modes.
Thanks! A bit late to the party, but if you still see this, I presume the authentication exchange between the web server and the device is some kind of challenge response? And if so, does the challenge/response depend on the type of credential that's in the device?
Back when I implemented webauthn for the first time I remember the interactive tutorial webauthn.me provided by Auth0 was very helpful in wrapping my head around the process.
Most important feature imo: The effective "password" being sent over the wire is essentially some hash(secret, uri). Think about the consequences for phishing!
The signed assertion includes the clientDataJSON, which contains the origin of the relying party. Assuming the server properly validates that assertion, it should prevent the use of a phished assertion by a third party.
Nice to hear I'm not the only one. Part of the problem is that it's always presented post-login when I'm already in the middle of doing something. And my password manager works well, so I don't see a clear benefit and I'm not really motivated to investigate vague claims.
I agree, plus the added abrasion from passkeys being implemented inconsistently and seemingly in a way that promotes vendor lock-in. Do I need a different passkey for my iPhone and an android tablet? Do I need a different passkey between iOS devices? Why does this service allow me to use a passkey in Bitwarden, but that service doesn't? These are all questions I've never had to ask about a complex password in a password manager.
The primary advantages of passkeys are phishing resistance, uniqueness per site, and breach resistance.
Phishing resistance is improved over what a good password manager can provide (unique passwords per site, checking web origin before providing options). Since WebAuthn is a protocol, the origin of the requesting site is stamped into the authentication response; even if the user had the option to override a passkey to be sent to a different malicious domain, it is meant to be rejected if replayed on the legitimate website. WebAuthn really needs an attacker to compromise the legitimate site or to compromise DNS and TLS infrastructure for phishing to be successful.
The uniqueness is really two benefits in one - you don't need to think of multiple unique passwords (if doing manual password management), or suffer with password complexity rules (if doing either manual or automated password management). It is just a public key, usually a P-256 curve point. The security of the user authentication process is abstracted upstream, so it is secured with the local password/biometric or via an activation PIN (same as password managers).
The breach resistance means that if XSS gets onto the page, if a hacker gets read-only access to the password database, it is still infeasible for them to leverage anything they gain to answer future authentication challenges. If your passwords aren't unique, a breach is a big deal and can create a lot of lateral movement. Even if they are unique, attacker visibility of the password means account compromise. The private key in a passkey is separate from the website infrastructure, so that attacker is not going to be able to authenticate from anything they observe.
>All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up.
The basic logic here is pretty clear imo. Passwords are still symmetric factors, and they're also completely unstandardized. So you still have to do a significant amount of manual management crap that should not exist, deal with UI that should not exist, and you still have to do some stuff if the other side (service provider) gets hacked. If we used bog standard pub/priv keys instead, then everything could become universally better. There'd be no need to worry about password policies, whether there is a character limit or not, how well and consistently individuals handle it, or anything like that ever again. Nor care if a site is breached, literally no action required because the site would only have the public key, they could publish it in clear text and it still wouldn't help attackers authenticate a single iota. Plus things like phishing and so on go away, because same thing, if the user has their agent browser to a malicious link or the like, and then it presents their pubkey, it still wouldn't do anything and the agent can't be fooled by similar looking to humans domains or anything. The agent would expect the service to present the proper signed request and anything else wouldn't work. Conceptually everything could be automated and standard without any sort of silo, all software could speak the same standard simple key format and everyone could back that up and sync it any way they wanted.
Unfortunately as is so often the case these days there's a lot of perverse incentives and players who can't resist the urge to try to add extra functionality in on top rather then just going for the low hanging fruit in a solid way first. So we've seen a confusing muddle, of existing players with financial interests who make money by helping lower the pain of the garbage that is password based mutal auth, those who see new chances to try to silo, those who want to shove in attestation and differences in password backing for good and bad reasons, mixing in concepts of hardware backing that are unnecessary, etc. I'm still hopeful something will come out of it in the end but it's been a real bummer to see how it's played out.
Yes but what I'm still confused about is that:
1) Is one/some of your public key reused on different services
2) Or is there a different public key for each service
1) In the first case what will prevent different services to track users by comparing public key... and if so I would be more at ease with a site specific randomly generated password
2) In the second case when one service is breached you'd still have to manage rotation of public key somehow, how trivially is that done with current implementation ?
>2) In the second case when one service is breached you'd still have to manage rotation of public key somehow
Why would you need to rotate your keys? If they're storing passwords/hashes it makes sense to rotate because they might be able to brute force the hashes on a GPU cluster, but you're not going to be able to brute force a randomly generated public key.
If I have any fear that the associated private key have leaked. For instance if my off-site encrypted backup is stolen. I sure would want to rotate my private key because my secret would be only as safe as the encryption method at the time the backup was stolen. I'm still not entirely sold on the "quantum will break any current crypto" but better safe than sorry.
>If I have any fear that the associated private key have leaked. For instance if my off-site encrypted backup is stolen.
That sounds like a totally separate threat compared to "when one service is breached". In your last comment you were talking about your password manager being hacked, but in the post before that you were talking about the service (ie. the website you're using) being hacked?
Also, while I do agree that if your your password manager database were hacked you would need to rotate both passwords and passkeys, but I would hope that occurs far less frequently than some random service you use getting hacked.
The whole point of a public key is that it is not secret. A breach where a service leaks the public keys of its users does not harm your security posture at all.
The problem Passkeys (and FIDO2 and WebAuthn and U2F) solve is phishing. The core concept is mutual authentication: not just you to the service, but the service to your authenticator.
Totally agree. I have used fido2 and webauthn before and I liked it. Particularly with a hardware key the mental model is quite straightforward. Now with that Microsoft, Google and syncing business I am left totally confused. Why the hell should alI store a private key in some cloud?? What happens if that provider decides to terminate my account, if it gets pressured to release the key? Also how does this all work with Windows Hello and other things in between??? I know a bit of crypto and security protocola but the passkey concept and possible attack vectors totally escape me.
I agree, framing it as a mental model makes sense.
Here’s the issue: when a site rejects my password, I understand the potential reasons—wrong site, wrong account, or forgotten password update. But what does it mean when a passkey fails? How can I resolve this? Is it even fixable?
My lone attempt to use a passkey for login involved an unrecognized fingerprint authentication, leading to repeated failures and ultimately, a return to traditional passwords due to the opaque nature of passkeys.
What the parent says. I'm hoping this HN thread will help clarify this.
Currently, I view the entire paradigm as asking me to trust resources (software, hosting, etc.) that I am not ready to trust. Both from a knowledge standpoint, or lack thereof on my part, and out of experience. Re the latter, third party resources die, go bad -- technically or morally -- and... just observing the nature of "online" resources over years and now decades.
They’re basically an advanced username/password that’s automatically generated by your device. I believe one of the benefits is they require an encryption component that is known only by the devices that you own. This is better than a password that’s stored on a server and can be lost.
It is a different technology with some different edge cases so I wouldn't call it a rebranding but in the broad scope yes. The problem with this stuff was always the integration, not the tech.
The mental model is very simple. If you use things like Yubikey, it is exactly like a key you use to start your car. A single password protected key maybe. In essence, it is your password manager but something that everyone can use. And something that doesn't need to be on the cloud.
It is like a key to start your car, except you can register it with multiple cars. And it has 25 or so "slots" for car registrations. If you lose the key, you cannot order a copy from the car manufacturer. You also cannot make a copy yourself. But you can (usually) register multiple keys with the same car. You do this by plugging two keys into the same car, and the car learns both keys belong to the same owner. You just have to be careful and keep track of which car is registered with which key, and vice-versa. Sometimes the key will not work with a particular car. Also, after you plug in the key, the car will not start right away. It will first ask you to select which key to use. If you use Bitwarden, it may hijack the key insertion interaction and will offer to use its soft-key instead. So, some small differences ;-)
Well that doesn't help understand: How passkeys can be backed up? Where/how they are stored? What if I loose my phone, computer? How can I login to some app using pc/mobile?
I haven't been into passkeys as you see, but some easy login like that leaves me with a lot of questions.
The TL;DR version in my opinion is that passkeys are quite similar to a SSH key pair, like one you'd use on GitHub. Basically you generate a key pair, the server stores the public key, and the client stores the private key. When you want to authenticate, the server sends a challenge, you sign it with your private key, and send it back. The main debate is over how to manage those keys after generation.
- Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.
- Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up. So the passkeys are stored encrypted on disk, and the decryption key is stored in the keychain/keystore. Other options include passkeys actually stored in hardware (eg. Yubikeys, but then you can't back them up) or 3rd party password managers.
- Login: It's pretty seamless, just click "login with passkey". The browser handles finding the right passkey, and part of the signed challenge includes the domain the passkey is for, preventing MITM-style attacks. There's also a whole separate thing for authenticating a session on a different device via scanning a QR code or Bluetooth.
The big problem is that most passkey providers do not support actually giving users their passkeys.
As the article stated: "I want you to remember this quote and it's implications. Users should be able to use any device they choose without penalty."
As you've pointed out:
>> Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.
and again:
>> Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up.
How can I get my passkeys and back them up on my own storage media? (e.g. USB drive, encrypted cloud storage, burn to a disc, etc.)
How can I import passkeys generated elsewhere?
If you cannot backup or import the passkeys, then you do not control them. They are not your passkeys--they belong to Google or Apple, etc.
And as the article states, in most cases these passkey providers do a piss poor job of managing their passkeys that they claim belong to you.
Agreed, they unfortunately seem to have gone the vendor lock-in route. The big players don't have export utilities for passkeys, despite it being technically feasible and pretty straightforward to implement. That's a pretty major gap in the spec, there should be a standard export/import format, and vendors should be required to implement it in order to be compliant.
It's probably possible to extract passkeys from a rooted Android device, but it would definitely be out of the grasp of 99% of users. I have not looked into it in detail, but I'd expect a Frida script hooking the keystore decryption function would get the raw data, then it would be a question of interpreting whatever proprietary format Google is using for their password manager.
This has always been my objection to them, as a user, as they have been presented. As an employee, I don't care. Businesses have sufficient relationships and mechanisms to self-serve any issues that come up, like lost keys. But as a user, I do not. It is a drop-dead requirement for me for any authentication material that I have some way of backing it up and modifying it in case of compromise.
Besides, give the Silicon Valley venture capitalists and Harvard MBA bros a whiff of the possibility of full control over something as important as your primary authentication material and before you can whisper Richard Stallman they're out having a happy Bacchanalia toasting the name of Portunus [1], whom I will now resurrect out of our ancient past to name him the God of Platform Lockin, and us users aren't going to get a word in edgewise over the debauchery and slides projecting Total Addressable Markets.
Fortunately it seems they all got a little too drunk with power this time, but honestly it's only a matter of time before they arrange another Portunus summoning lock-in party again. This target is irresistible and the annoyance people have with passwords is too good an angle to pass up.
I'm not quite sure if even the corporate case works properly with iOS & Android devices as the article states, otherwise you could become a 'corporation of one' and side step all of this stuff. Even the corporations look like they have to use apple or google's crap for employee devices and accounts?
I mean in principle. If I throw my authentication material into a lake, there's an IT department that can have authorization to re-establish it. If I throw my personal authentication material into a lake, there's really nobody who can help me. I can try to convince a large company that I'm really me, but that is indistinguishable to them from a social engineering attempt, and dealing with that is high touch and expensive. I need to be able to back up my stuff. If the aforementioned "large company" is the one holding my authentication material and anything whatsoever bobbles it, then I'm back to trying to convince them I'm me.
A "corporation of one" is still just me, so I'm not talking about trying to technically hack around things by pretending to be a corporation.
When you see it this way it becomes really clear that Google, as a corporation, is an absolutely atrociously awful company to be the ones holding the keys to my identity. But there aren't any good, big, easy, safe options. I need to be able to self-service. Or we need to create much smaller, more local (in some sense, not necessarily geographical) holders of the auth material that I can convince I am me and they can reset it if something goes wrong. But that gets into a complicated web-of-trust and that's never worked out.
I reread your analogy a few times, and while I think it's probably accurate, there is absolutely nothing simple in it. It reminds me of the "It's like Uber, but for mortgage insurances" kind of startup pitch. It perfectly encapsulates the concept, but the concept itself is just crazy niche.
To note: the key to start a car is provided with the car with no specific operation, is locked to no other device, doesn't care about who's handling it, can be duplicated and passed around. It would be closer to the traditional password system in all of its aspects IMHO.
I understand passkeys as authentication through a private/public key generated by the client when creating the credential, with the private key staying client side and the public key kept server side, with some more details around it to make the whole thing discoverable/automatable.
To me the best explanation was just to go to the passkeys.io site, the subject is complicated enough that analogies tend to introduce a lot of cognitive noise IMHO.
I think I'm a tech guy and know my fields. I still have no real clue how passkeys work, how it is better, what it really is.
When your security feature is not as simple as - remember a name and a password and store it somewhere safe - it doesn't work.
Something about keys that are on devices. But what happens when I use a phone and a pc? How to get access then? Do I need a User/PW for the first time? Or do I need one of those keys I have to plug into the device first?
SSH is nice because you don't have to think about it. Your private key sits in your .ssh folder, and then everything is transparent. You _can_ put an SSH key in a smartcard if you want, but you have to opt-in to this kind of pain. And even if you do, almost all SSH servers will support that login method without issue.
Passkeys don't sit in your .passkey folder. Your browser doesn't look for passkeys in a standard folder at all. You don't just do passkey-keygen like you would ssh-keygen and forget about it.
Websites might support various combinations of FIDO/U2F/TOTP security keys, your USB security key might support various combination of FIDO2/CTAP/WebAuthn, and the user will be left confused what any of this mess means, why there are so many competing standards, and why they're asked to scan a QR code when they plug in their dongle, and it doesn't just work at all.
Passkeys ought to be exactly like SSH keys. Unfortunately, they are not.
The attempts to restrict when and how they are stored, and how you can access them - those are going to cause a lot of pain and confusion.
I have all of my SSH keys stored in KeepassXC, which (imho) is a lot more secure than having them hang around in my .ssh directory. Open KeepassXC, and the keys are available. Close it, and they're gone. Synchronizing the KeepassXC-file across devices means that I have access to the keys on all of my devices.
The big companies pushing passkeys are trying very hard to prevent this kind of convenience.
They shouldn't be exactly like SSH keys. With SSH keys, you can go and copy/paste your private keys on a scammer's website because they asked you nicely. People will totally do it as they don't understand what they're doing.
The main thing with passkeys, and key dongles in general, is that you simply can't do that as the keys are inaccessible and you can only prove possession of a key when asked by a domain you've explicitly registered with (the proof-of-possession is never sent to any other domain than that which you registered with).
What OP says is that opens the possibility for key providers to lock-in users, as that seems like an unavoidable side-effect of the legitimate goal of preventing phishing (phishing is the biggest security issue today, to increase security means making phishing impossible, so I still support passkeys as the best solution for that).
There's a big difference between "can't just hit the copy button and paste in the key" and "can't export the key as part of a backup." Physically preventing users from ever accessing their own keys is an absurd user-hostile proposition. Even more absurd when the they're software keys stored in a database the user can decrypt. The FIDO alliance is just ensuring that password managers will require 3rd party backup tools to be useful.
Password managers have prevented phishing just fine by binding passwords to particular domains, ssh keys prevent phishing with IdentitiesOnly and passkeys are bound in the same way as regular password managers.
There has been a pretty insane number of times I've asked someone for their SSH public key and I get a response of ---- BEGIN RSA PRIVATE KEY ----. From people employed in tech jobs. Now imagine someone who barely understands how to use a computer, they're an easy target to get their identity phished.
I don't think the answer to these problems building system that treats users the same as an attacker when it comes to accessing and backing up their own private keys. Because at the end of the day the ability to export your private keys and store them somewhere securely is the account recovery of last resort.
Passkeys aren't HSMs -- the fact that you can sync them via your iCloud or Google account should dispel any such nonsense. It's fine for Apple or Google to store your keys at your request and they should keep them secure but the model of "here's my key, now don't ever let me look at it but let me use it via what is effectively DRM" is silly.
If a warning message on export "Never share this with anyone. Even someone you trust. Even your IT department. There is no reason anyone but you should have access to this key." isn't enough to stop people giving it away then no security was ever going to work for them. They would give away the credentials that lets them use the key in its absence.
> Because at the end of the day the ability to export your private keys and store them somewhere securely is the account recovery of last resort.
Or just have multiple passkeys for the same account. It doesn't matter if I lose the passkeys on my laptop because I've got other passkeys to those accounts on several other devices.
> Passkeys aren't HSMs -- the fact that you can sync them via your iCloud or Google account should dispel any such nonsense
Resident keys practically are HSMs, aren't they? None of my passkeys are backed up to a Google or iCloud account.
> If a warning message on export "Never share this with anyone. Even someone you trust. Even your IT department. There is no reason anyone but you should have access to this key.
In those conversations with people who should be experts I usually made a point to tell them send me the public key and told them to never share the private. They still sent the public. People have been told to never share passwords either but I still often hear "yeah my password for this is blahblah123..." when asking for help.
Any security solution that involves lay people having access to keys is NOT secure. What you call "absurd user-hostile" is actually basic security in the real world with non-technical people.
Technical people can already be secure using appropriate protections, but even for them it's very difficult to do it properly.
Lay people will, without understanding what they're doing, ask the password manager to give them their password to enter manually on any phishing website as they'll think that it's not working because it's "broken". So , absolutely no, password managers do NOT prevent phishing.
If you think I am exaggerating, well, I work with this and I assure you it's even worse than that.
I would say the exact opposite, traditional ssh key management should eventually give way to resident keys. Aka, treating them just like passkeys.
We've been storing ssh keys directly on our yubikeys since before passkeys were a thing.
Not only is it clearly more secure it's also been a usability lift. Plugin your yubikey, start an ssh agent, and run ssh-add -K to get all your resident keys added to your current session.
I understand this, but the person who responded said Passkeys are exactly the same as SSH and used the same, when asked what they are. If that was true, then we would just teach non-technical users to use SSH Keys.
You should produce a key per device, and produce a backup key that is safely stored & not used anywhere.
You can recover if you lose all devices via your break-glass backup key, and you limit the blast radius of "my key got stolen" from rotating all your keys to just a single device (or maybe the more likely "I screwed up and pushed my key somewhere public")
... which is completely nonviable if you connect to more than a single service.
I agree that you should use a different key per device, but when you connect to over a dozen different services/machines it quickly starts to become a serious chore to add another key. Have fun spending an hour enrolling your new device - provided you can even remember every single usage it should be enrolled with.
Unfortunately SSH certificates have really poor uptake in practice, and it's essentially unheard of to have a personal CA instead of a per-company CA.
But yes, having a single long-living "primary key" everyone can trust which you'd use to generate short-living per-device "secondary keys" would indeed be the ideal solution.
Sure, but then limits you to a handful of keys. The WebAuthn people don't like this, they want one key per service, so basically YubiKeys no longer really work with WebAuthn (unless you're fine with only ever using a max of 25 services).
For me that means having multiple keys in `authorized_keys` for the same user and never transferring private keys between devices. From what I gathered from the discussion here, this is not a given.
Why would you want to? Just create a new passkey on the other machine. If you're saving them in a password manager, just create a new entry, "Another Machine's Passkey."
Usernameless always seemed like an optimization too far to me.
I think it's totally reasonable, and probably a good thing for users having to use their username at login. Especially as it reminds them what username they are using for that service.
I could totally see a situation where a user uses a Usernameless passkey for years to access a service and for some reason loses access to the Usernameless passkey, and then has also forgotten the username for the service, so cannot even start an account recovery process.
> Usernameless always seemed like an optimization too far to me.
I think it depends on the service. But aside from the occasional forum or social site, usernames are just an extra step. I don’t want or need one for banking/administration/ordering a product. For better or worse, email is usually a better identifier, assuming you already need one for other reasons (like you say recovery is typically needed).
> Especially as it reminds them what username they are using for that service.
Like passwords, forced usernames are hard to remember, if you use different ones. If you use the same, then it leaks privacy across services. (Technically usernames can be private but the expectation from decades of social sites is they are public)
> […] loses access to the Usernameless passkey, and then has also forgotten the username for the service
Correct, no identifier at all can’t be recovered. Hence, email.
No, your person is your identity. Passkey don't pay for services, people do. So there is always a recovery process, at least for any business that actually values you as a customer.
No, that's like having only one key to your house.
If you have two passkeys from different providers, they serve as backups for each other. And there are other alternatives, like a printout of recovery codes.
I've never tried to use passkeys, but determined a while ago my hard, non-negotiable, a priori requirements which would have to be met for me to be willing to use them:
1. I can, if I choose, have a passkey in software (no hardware enclave, no
captive key, no TPM) even if the security of that sucks:
=> Implication: I can backup and copy a passkey without restriction, e.g.
putting the key material in an airgapped password safe, and without that
being visible to a website.
=> Implication: Websites can't discriminate by whether I have a passkey in
software or have any part in deciding whether I get to backup, copy or
transfer a passkey.
2. I can disable any attestation functionality to do my part to prevent
any online service from making it mandatory.
I haven't looked into this yet, so: do, or can, passkeys, or the contemporary WebAuthn implementations in Firefox or Chrome on Linux, meet my requirements?
> I can backup and copy a passkey without restriction ...
We were so very nearly there with U2F... I did extensive testing and you can have a U2F (Fido2/webauthn) device deriving it's private keys, never leaving the device's HSM, from a BIP-44/BIP-39 seed. You write 12, 18 or 24 words down (out of a dictionary of 2048 words) and with these words, you can always reinitialize another Ledger Nano (a cryptocurrency hardware wallet but I didn't care: I was after the U2F "nano app").
It just worked. It was beautiful. My seed were written on paper sheets which I'd store in a safe at the bank / at my parents' home, etc.
As a bonus the hardware device would display, on its little screen, if you were enrolling or login (a useful info) and, for known provides, it'd display the name. For example "login to google?" / "enroll to dropbox?".
Pure beauty.
Then sadly this trainwreck that passkeys are happened, greatly lowering not only the security of 2FA (someone is in control of all your keys and they can be "backed up": what a concept!) but also making you lose the ability to backup your own keys/seed.
I do really hope at some point we see a future "passkeys nano app" for hardware devices on which the user is in control of the master seed used to derive the keys. It worked for FIDO2/webauthn. I hope it'll work again at some point in the future for passkeys.
I wish Yubikey allowed users to import their own FIDO2/webauthn seed and overwrite the factory generated one, and then also allow the resident passkey functionality to be disabled.
It should be up to the user if they want to have multiple duplicate hardware authenticators and be able to backup their seed however they wish.
Firefox and Chrome display a permission dialog when a website requests attestation, and you can deny it. If you deny it, the website has no idea how your passkey is stored, allowing you to use a pure-software solution if you so desire. The website could discriminate against you for denying attestation, but note that Apple always denies attestation for passkeys, so websites intended for the general public are unlikely to discriminate against users who deny attestation.
So yes, I believe your requirements are met in practice.
1Password includes Passkeys in archive/exports of the 1Password database. Safari developers have stated that it is a planned feature to support Passkey exporting (but not currently supported) including between apps.
I'm not aware of any restrictions at this time on your second point. I also haven't seen any examples of attestation and Passkeys being used in practice.
As someone who happily uses Yubikeys, I really don't want to use a Passkey. I want to still use a username/password and the Yubikey. Not just username and Yubikey.
Google tries to force use of passkey now that if you enroll a Yubikey it will now be a Passkey, instead of a second factor. With no option to disable it. I have to run the Yubikey Manager tool and then disable "FIDO2", so that I can force it only be used as a 2nd factor.
You can open your Firefox about:config and set security.webauthn.ctap2 to false.
This will cause a fallback to FIDO/U2F where possible and your browser will appear to not support FIDO2. I've observed this with the default Keycloak flow for Security Tokens. May be a bug, too...
I don't know if this works with Google but if you try it, let me know :)
This needs no restart of Firefox, so you can use it to quickly disable it instead of fully disabling it on your Hardwaretoken.
Because of the whole "multi-factor" thing, and not making account recovery impossible?
Passkeys are always going to be less secure than username + password + Webauthn, why would you intentionally make your account less secure and give yourself a massive failure mode in the process?
Password and other factors are not going anywhere. You can set password, TOTP, email, phone and passkey at the same time. And use passkey because it's convenient. But use other combination of factors, if you need to access website without passkey. At least if website owner allows it. But I think that most websites will allow it.
Account recovery is a separate issue. There's nothing about a pass key that makes account recovery any harder or easier than if someone loses their MFA TOTP device or forgets their password.
You can (and are generally required to unless you purposefully use a "non-compliant" implementation that ignores it) set a PIN on your passkey.
> Passkeys are always going to be less secure than username + password + Webauthn
It's less secure in the same way that a door is less secure if you put a single strip of duct tape across that same door. Technically yes, but not in any meaningful sense.
If you use Google Workspace you can set 2FA directly from the admin console, so you don't need to disable FIDO2 on the key. Does not help with gmail, though.
Not in my experience. In the Admin console I said do not use Passkey and it still created it as a Passkey :( This was about a month ago, so maybe they fixed it. Turning off FIDO2 made things work.
If you add a FIDO2 key as a security key in the admin console, it will show as a "passkey" in Google account settings, but it will actually be a non-resident key used only for 2FA and won't be able to be used for anything more than that.
Keys that do not support resident keys (or when you turn FIDO2 off) show differently in Google account settings which makes it all very confusing. The UX is inexcusable, really.
As a side note, turning on Advanced Protection also turns off passkeys.
> But of course, thought leaders exist, and Apple hadn't defined what a Passkey was. One of those thought leaders took to the FIDO conference stage and announced "Passkeys are resident keys", at the same time as the unleashed a passkeys dev website (I won't link to it out of principal).
I'm trying to follow the developments in the 2-factor-auth space and this was one thing that confused me a lot. I've read a lot of hype on Passkeys being the next big thing but it was really hard to find an actual explanation what they are and how they work. And once I found out that these are keys that are stored on the security key, I was rather disappointed, because I really like the idea of generating keys on the fly based on the domain name that I'm authenticating against. This way I can "store" an infinite number of keys. The upside of Passkeys is supposedly that you do not need to remember which username you have on a website, but I think that's a minor upside.
Related question: What is the official name for the (FIDO2-based?/WebAuthn-based?) technology that calculates and reconstructs keys on the fly based on the domain name of the service that I'm authenticating against? It is really difficult to learn the right terminology in the area.
> At this point I think that Passkeys will fail in the hands of the general consumer population.
Actually, I think it might be worse. The predators like Apple/Google have already pounced on passkeys as a consumer capture mechanism, so they'll ensure it doesn't fail.
They're a consumer capture mechanism insofar as password management tools are, and we want users to use those because they make security tolerable. The problem is that it turns out the OS vendor was in the best place to win the password management game.
The lock-in situation with passkeys seems far worse than with password managers, though. There is no "export" option for iCloud passkeys - despite being cloud-synced across your Apple devices.
If you decide to switch from an iPhone to an Android phone, you're looking at an arduous process of enrolling a new passkey for every single site.
Just you wait for governments to require platforms to only accept gov-signed keys.
I was sceptical about something-you-own auth vs. something-you-know auth from the beginning and recieved backlash from my tech peers for it. I hate to be able to go "told you so" on this one. Lets hope im wrong about the government involvement, but i dont think i will.
not to diminish your point, but since at decade or so I'm a more worried about corporate surveillance capitalism than I'm about government surveillance.
Why? Governments can do so much harm by incarcerating, fining or even killing you.
Don't get me wrong - corporate surveillance can be very annoying, especially in insurance / credit scoring / price discrimination etc, but it seems a comparatively lesser danger.
Probably because governments can just buy the corporate surveillance results, bypassing any shoddy protections that even exist completely. So corporate surveillance is government surveillance.
You can’t avoid these corporations if you want to remain active on the internet. They keep shadow profiles. They sell and share your data from one service to another (I stoped using Facebook for example, but Netflix shared its watch data with Facebook.)
I don’t think it’s possible to avoid them. Confuse them maybe.
I mean, same, but only because I realized a new undesirable thing was becoming a tacit reality that we'd have to accept on top of already undesirable thing
The part I hate most about Passkeys is that it essentially killed the FIDO1/U2F ecosystem.
Just about every website which implemented Passkeys removed the option to use hardware tokens with "non-resident" credentials. This means you're stuck using your Yubikey as either an insecure TOTP token, or as a practically-useless Passkey.
We had the perfect 2FA method with U2F hardware tokens, why did they have to take that away?!
> We had the perfect 2FA method with U2F hardware tokens, why did they have to take that away?!
It deeply saddens me too.
But I think we shouldn't discard one of the obvious reason: the U2F system was too secure.
Let's not forget this: the original U2F system even had a way for the user to know if its device had been cloned, for they'd be using a counter. And they silently removed this.
When Apple+Google+MSFT team up to lower security, I'm pretty sure three-letters agencies and their backdoors aren't very far.
The whole concept of passkeys that can be copied around is honestly hilarious. FFS: we had the perfect solution...
I don't think it's only incompetence at work here: there has to be mischief or at least mischief shouldn't be discarded.
Passkeys are a godsend when compared to weak passwords and SMS 2FA. Try to think through how to protect a bank account or retirement account for the average consumer, some banks send you a OTP and have you read it back to prove who you are when you call CS, some think the OTP is sacrosanct and will never be read back.
I 100% agree with you but there has to be something for regular consumers to safely log into a website that may have 10s or 100s of thousands of dollars on the other side of it, and be secure.
For folks who don't know how passkeys work at a technical level, take a look at this implementation guide: https://webauthn.guide/
I don't get the passkey hate -- moving to public key challenge for authentication is a strong step forward for web security. Each browser / OS safeguards & backs up the private key (and even if that's lost, you can still reset your auth credentials using a normal "forgot password" flow).
The linked article does a quite good job explaining why hating passkeys make sense.
Here's a key quote, but I do recommend reading the whole article.
> Since then Passkeys are now seen as a way to capture users and audiences into a platform. What better way to encourage long term entrapment of users then by locking all their credentials into your platform, and even better, credentials that can't be extracted or exported in any capacity.
I don't believe this is necessarily true, as far as intent goes. I think Apple and Google focused on a core use case, shipped it, and subsequently lost interest or fired everyone involved.
Unfortunately, this scenario is indistinguishable from one in which they deliberately mishandled the specs in order to lock in users.
Thanks for your faith. I work on the team shipping passkeys at Google. We are very much hard at work to realize the full potential of passkeys. Platform lockin serves no one. That is no one's intent - independent password managers storing passkeys is already a thing today. More interop will come once relevant standards are blessed.
This is precisely like the imaging standards trying to replace JPG. After two decades of vendors like Google trying to establish a new standard, I can’t send anything other than an SDR sRGB JPEG to anyone, especially to an Android user.
The current post-JPG formats may as well be called “the Apple format”, “Google image”, and “Netflix pics”. There is no practical interoperability to speak of.
I’m seeing the exact same dynamics play out with PassKeys: lip service to interoperability, meanwhile consumers are left twisting in the wind, locked out of their lives because Google can’t play nice with Apple. Or Microsoft. Or anyone else.
“Interoperability is coming” is a statement in the same category as communist dictatorships promising true socialism and freedom… you know. Eventually. Just not now. Or next year… maybe later.
There is a significant amount of interop that already exists, that folks are looking past or just already taken for granted (which is actually fine too!). While on a Windows machine using Edge, you can save a passkey for your Google account to your 1Password vault, and use it to sign in to that Google account on Chrome on Mac (if you have signed in to the same 1Password account on the machines). Or you could use a passkey you saved to your iPhone / iCloud to sign in to the Google account on ChromeOS. This is the level of interop that exists today. This did not just happen magically - all these companies (and more) worked hard to make it happen.
Also speaking for Google accounts, passkeys are an additional option for users. Using a passkey is not preventing you from keeping any other sign in method on your account that you feel has less of the lockin risk.
If you can enumerate the few specific scenarios that work, after “companies worked hard to make it happen”, then there is no interoperability to speak of.
This is like someone from North Korea saying that they are free because they’re allowed to go to three specific cities in China for work.
Interoperability is an afterthought.
Even if that NK citizen is allowed to go to dozens of foreign countries, he’s still not free. There’s a fundamental difference between enumerated positives and enumerated negatives. Interoperability would be if every combination worked with only a handful of exceptions.
PS: Literally just after I made the comment above I had to add a PassKey to PayPal and only 1 of 4 scenarios that I tried worked.
I notice you responded to this and not any of the other critical threads (at least, at time time I'm posting). Tell me you're defensive and have no leg to stand on without telling me you're defensive and have no leg to stand on.
> This is precisely like the imaging standards trying to replace JPG. After two decades of vendors like Google trying to establish a new standard, I can’t send anything other than an SDR sRGB JPEG to anyone, especially to an Android user.
Android supports WebP since Android 4, HEIF since Android 8 and AVIF since Android 14. They are only missing JPEG XL, but to my knowledge neither iOS nor Windows support that format natively either.
Regarding interoperability and support for open formats Android/Google is way ahead of Apple or Microsoft in my experience.
Having a library in the OS and actual interoperability are vastly different things. Not only do most consumer chat apps completely disregard HDR, but even worse, sending HDR images via almost any such channel has a high chance of the colours being mangled or -- at best -- silently converted to 8-bit SDR.
Also, unlike Apple iPhone users, people with Android phones tend to get stuck on older major versions and can't upgrade. Easily half of all Android phones out in the wild can't correctly tone map or display either wide-gamut or HDR still images.
You can absolutely do public key challenge authentication with passwords. You can use argon2 to derive the secret key for your account from your password and use that to encrypt a challenge message
Passkeys can't actually replace passwords, right? I will always need a username and password with a website, then can generate a passkey as a separate auth mechanism, which if I lose, I will recover by setting up again using my username and password? I don't get how we can get to a place where passkeys are all, how do you get a passkey on a new device when you only have passkey auth on some other device enabled?
That's not the idea, no. The idea is that - instead of a password - you have a cryptographic key. Like an SSH key. This key is managed for you, so you never have to see it or type it. You ought to be able to either have just a few keys, or else a different key for every service you use.
Unfortunately, the big players are trying to force this (really excellent!) idea into platform dependency. They want to store the keys on physical devices, which (a) eliminated portability and (b) restricts the number of keys you can have. If your device fails, you will also be faced with account-recovery problems.
Great idea, but the implementations are looking...not great.
Both iOS and Android sync to other devices in the same ecosystem, so there is at least a limited form of device portability.
If you have both, register two passkeys with each account and that's even better, since they back up each other if the vendor somehow deletes your account.
Wouldn't transferring the keys around just massively increase the attack surface? There's a security reason why we want them stored on-device and never moved, right?
Think of all of the password leaks you've heard of. How many were due to syncing password vs password reuse, poor site security (e.g. storing in plaintext, weak encryption, etc.)
I'm not saying syncing is 100% secure (nothing is), but for most people it's not the main attack surface to be concerned about.
The KeepassXC file is encrypted (granted, only with a password). Sure, that file is now on multiple devices, so somewhat more vulnerable.
The problem with storing on-device comes when you use multiple devices. I have three devices (PC, laptop and phone) that I use regularly and interchangeably. What am I supposed to do, if the keys are tied to a single device? Worse, what do I do if that device dies, or is stolen?
This is how I'm using them. Still have a username/password, with a passkey as an additional factor. I use 1Password for passkeys rather than Apple's solution, which enables me to use them wherever I have 1Password.
To get a new passkey on another device, the provider needs to allow you to prove you have possession of your other device first. They can do that by sending you a one-time code, for example, when you authenticate using your existing device, which you can then type in the new device, and that lets you associate your new device-generated key with your existing account.
With iCloud, you don't need event that because Apple can, and does, sync your keychain across all your Apple devices. So as long as you use the same Apple ID on different devices, all passkeys are automatically sync'd.
If you lose ALL your passkeys, you may be in trouble and for that reason, it's common that when you register your first passkey, you should also be given a long recovery code which you must keep privately in a very secure physical location (as that will allow anyone who can get it to reset your account). You could say that IS a password, and perhaps you're right, but there's a difference in my mind that's pretty big: you're never supposed to use that "password", nor keep it easily accessible or even anywhere in digital form.
Finally, a lot of people in this thread are missing that passkeys prevent phishing, and are basically the only way we know to prevent phishing. And phishing is extremely high in the ranking of security issues we currently have to try to solve.
If you know a better solution to phishing than passkeys, please let us know (Passwordd Managers are not that if they allow the clueless user to extract the password and manually enter it anywhere)!
A long recovery code that both you and the provider need to know in order to authenticate you IS a goddamn password no matter how infrequently you expect to use it. It just changes what knowledge a hacker looks for either in your digital storage or in a company's databases.
If you get rid of all knowledge-based authentication in order to increase account security, then you necessarily increase the chances of permanent lockout. You can't square a circle.
As for phishing, maybe google should put its AI capabilities to good use, and if the text of an email matches enough patterns of examples it's seen before, there should be a banner at the top of the email warning "this looks like a phishing attempt: common tactics include X, Y, and Z. Confirm authenticity before reacting to this email."
I don't think you know what phishing means. By "dropping malware on endpoints" I think you mean having a website serving malware? That's not phishing. For an attack to be "phishing", the website needs to be pretending to be some other website that the user trusts. Passkeys completely prevent the user from logging in to another website than the one they've created an account with.
Your attack only works on people who basically "trust any website" at all. For those, yeah there's no salvation.
I’m a security engineer, I’m pretty fluent on the topic. And phishing comes in beyond the methods you describe -> malicious attachments downloaded, etc etc.
I do agree but in this discussion we're talking about the general problem of logging in to a website.
That's the case where phishing is the most devastating. Solving that problem is a huge step in making people's online lives more secure. Just because we didn't solve all problems, doesn't mean we shouldn't solve what we can solve. If you're a security engineer, it's your job to promote ways for people to be more secure online. And this is what I am trying to do myself.
The discussion you brought up is, which I object to:
> Finally, a lot of people in this thread are missing that passkeys prevent phishing, and are basically the only way we know to prevent phishing. And phishing is extremely high in the ranking of security issues we currently have to try to solve.
And I can point out several ways phishing is currently prevented without passkeys. And several ways it occurs without logins, such that it’ll still be around after passkeys. And phishing is difficult, but per defense in depth concepts, it is not the mission critical focus you label it as.
So to turn it back around, I don’t think you understand phishing threat vectors well haha.
Platform as in "ecosystem". iCloud Keychain, Google Password Manager, Bitwarden, 1Password, your Yubikey. Anything that can store passkeys.
If you want to use both you simply enroll both your PC and your iPhone. There's nothing stopping you from doing this. You can register multiple passkeys from different providers to the same account.
You can also log in to your PC with your iPhone by scanning a QR code. And then afterwards enroll your PC as a secondary passkey.
Did you know that you can turn every $2 Raspberry Pi Pico clone board into a FIDO2 stick, and even make it Yubikey compatible?
https://www.picokeys.com/
Well, not as secure as a commercial key, because the Pico doesn't have encrypted storage, but still much more secure than login/password.
I still use Keepass (well MacPass) and naively "cache" what I use regularly in Keychain because I completely distrust anyone else handling the keys to my castle. Whenever I get a Passkeys notification it's an irritation as I don't actually see what the supposed benefits of this are and I'm not really interested in changing how I work. Just feels like I'm being dragged into something complex I will never be able to escape.
If you’re asking in earnest: For the majority of users, Passkeys offer a pragmatic alternative to passwords that is far superior in terms of security.
For you, based on what I’ve read in your comments, I would say that Passkeys are the first workable alternative to passwords. They are built on WebAuthn which (roughly summarized) was the standard developed by Google and Yubico in direct response to the Operation Auora attack.
While the Apple/Microsoft/Google implementations of Passkeys likely won’t meet your personal standards, they’re built on a proven and well designed open standard. Which means you can benefit from the technology without buying into a corporate ecosystem.
> If you use a software-based password manager, passkeys are indistinguishable from passwords both from a UX perspective and a security perspective.
That's not correct. Passkeys use public-key cryptography and a challenge-response authentication mechanism, so an adversary in possession of a read-only copy of the database of the service you're trying to authenticate with won't be able to authenticate as you - which is very much a security improvement over passwords, even when both are stored in a password manager.
> an adversary in possession of a read-only copy of the database of the service you're trying to authenticate with
True, but GP is referring to the private key on the (user’s) device or computer being stored in a password manager. The main protection that passkeys offer in such a case is that there’s no case of passkey reuse across services and accounts, which is something that’s possible with passwords even if one used a password manager (albeit poorly by not generating unique passwords for each account).
Since the passkey is the private key in the private-public pair, if it’s stored on a password manager it can definitely be stolen by malware (if you could have a key logger, you could have something else too). The only solution is to have the passkey (actually private key) reside in hardware or be protected by dedicated hardware.
I've added a few passkeys to 1Password. It works pretty well on github.com, and sometimes on google.com. But apparently, passkeys.io bypasses 1Password and asks the OS for passkeys? So passkeys.io doesn't actually work for me, unless I want to store the passkey in the OS keychain. Which I don't, because I don't want to be locked into that.
How can it be that the website decides which password manager I should use to store the passkeys? That's crazy and goes against all intuition.
Hey, founder of Hanko.io here, we run passkeys.io. That behaviour is not intended. We've recently changed the demo to require authenticator attestation on passkey creation, that may have an impact on authenticator selection. But a quick test on my system (macOS, Chrome) resulted in the 1Password UI intercepting the "Create a passkey" flow - as expected. It would be awesome if you could help us understand why your experience is different.
With that being said, we are not happy with how password managers have implemented passkey intercepts, but ultimately that's a decision the user can make, as it can be disabled in the browser extension settings.
My assumption is that there's no proper browser API for third-party passkeys, so this extension probably monkey-patches website JavaScript which is not reliable.
Paypal has a really obnoxious failed implementation of passkeys where if you have totp configured, their login flow takes you to TOTP after your passkey auth.
If you want your passkey to “just work” you have to turn off TOTP. But thats a bad idea because passkeys are an alternate method of auth with paypal, not a replacement for passwords. So then you are left with the option of a password only sign in (no TOTP) or a passkey.
The problem with passkeys, beyond the painful UX that will scare any casual users away and the fact that they are being wielded as an extreme vendor lock-in mechanism is just that the design and implementation is so over complicated with second system syndrome.
If you’re going to push a replacement for passwords and want it to be universal, it should be EASY to implement. Even if the backing cryptography is complex, the actual handshake / implementation shouldn’t be. TOTP as an example is insanely easy to implement. Password auth of course is as well, despite needing to know what you are doing to get it right. Both can easily be handled entirely without JS.
I should quite frankly be able to just <input type=“passkey-public-key”> in a standard POST form for registration and be able to call it a day. It doesn’t justify how complex it is to set up.
A fitting password replacement should just be as smooth and easy as ssh. I give a website a public key, I use my private key. I manage my private keys however I see fit. I don’t need a third party involved holding my private keys hostage.
I've had Apple silently delete music from Music when I had iTunes Match, and I've stayed paying for Dropbox despite wanting to use iCloud, which would be no extra cost for me, because their mechanisms for dealing with conflicts are different - Dropbox saves a version with "Name's conflicted version 2024-04-26" in the filename, whereas AFAIK iCloud silently decides what to keep and drop so you can't manually decide how to merge a conflict.
I too find it hard to imagine how someone can lose all their passkeys three times, and I guess they may be doing something funky given their profession, but I think many of these events just happen too easily in the Apple ecosystem and my trust in them managing things like that is relatively low - hence my use of 1Password instead of iCloud keychain. The Music thing in particular really stung as I never got a good handle on what was missing - I'd just occasionally come across a "this file is missing" error when I tried to play a song, and I'm left with this kind of cloud of unknowing when it comes to my Music library.
Passkeys only encourage the need for a password management tool, which is funny because if everyone had password management tools to begin with then we wouldn't need passkeys.
Passkeys still protect you from additional things that password managers don't protect you against:
1. Your credential can't be phished as it's cryptographically bound to the domain. You could stil be tricked into entering your password and TOTP into a malicious website.
2. Your credential can't be leaked by sloppy servers as it's public key crypto. This makes your security not depend on believing the website your logging into does proper password hashing and doesn't accidentally log password in plaintext.
Most password managers tie credentials to domains. In fact, this is a good indicator of possible phishing attempts when your password manager doesn’t offer to auto-fill your expected credentials.
True, the technical aspect of passkeys does that. But in practical Apple and others want to heavily push for the smartphone as that tool, because it locks people further into that system.
> Passkeys only encourage the need for a password management tool
The dependency on a password management tool.
Be it Yubikey or Apple secure enclave or whatever, it's a shit piece of hardware that will eventually break. Have fun replacing all your credentials at the same time when your phone dies.
This is quite concerning, because I've recently started a project that uses webauthn-rs. I want to minimise spam on the project while I don't want to collect PII like emails for login.
I wonder if it means that the author will stop working on the library after their next release, and more importantly, if the UX is going to be horrible with people unable to log in and other issues they mention.
On a tangent, I share their discomforts about travelling to the US. The last time I was there, I felt uncomfortable being out on the streets alone. Maybe the portrayal of police brutality towards POC is a factor (for me).
I just went through the dance of logging out of all my google accounts and then logging back into them. While I was doing that, I added passkeys as a security layer.
Using bitwarden, it adds them in just fine. But, if you go and try to log into a Google account with Brave, it tries to use the Brave system builtin instead of the Bitwarden one. Presenting a dialog too.
As an end user, I don't know if it is bitwarden, brave or google screwing this up and I can't be bothered to figure it out, so it is back to just using passwords and 2FA...
It's Brave, the browser is responsible for handling the WebAuthn (or alternatively, the Bitwarden extension for Brave, assuming that Brave exposes some API to extensions which Bitwarden has not implemented correctly)
No, I don't want to be tied to a single browser for my passkey, what happens if I want to log into a site on my phone using safari or chrome? I also don't want it tied to my apple keychain. What if I want to share my passkey with my partner?
lol it’s a passkey… why would you want 1 that can be shared and… lost you just register another one
Being like “I don’t want to add another passkey” is really a semantic issue what exactly is the difference to you or adding a passkeys to an account vs copying a passkey to another device except the fact that if you can copy it/share it… it’d be far less secure with more ways to leak
My partner and I share a single account for XYZ service. We don't want separate accounts.
> it’d be far less secure with more ways to leak
There is nothing "less secure" with sharing an account credentials with my partner through bitwarden. Especially for accounts that are things like "pay my electric bill" or "online shopping".
I like the idea of Passkeys, but the implementation of them being exclusively tied to my super account of Apple or Google makes me very cautious. I’ve read too many stories about automated systems killing someone’s account and the resulting havoc.
I understand that, in principle it’s your device, and not your account, but it feels like the fingers are too deep to hand over one more thing.
Adjacent to this, I really liked Steve Gibson’s SQRL. I wish that had taken off.
> "If you really want passkeys, put them in a password manager you control. But don't use a platform controlled passkey store"
That is my main reason for avoiding Passkeys;
I will only use Passkeys, when i can export/backup them easily and store an offline backup, without depending on some Big Tech company or whatever.
(KeepassXC can export them, but not sure if it's released and fully functional in the stable build yet.)
What also worries me however, is that apparently if i read correctly, each server/service/website can decide/restrict "which password managers/apps" are allowed to be used for the Passkeys they offer...
Honestly, I think a big part of the problem is that passkeys have been tied to hardware devices and they don't have to be. A passkey is just a public key credential, and it can easily be provided by software as well as by hardware. You would still get many of the benefits (better UX, automatically secure, prevents phishing) and the overall customer experience could be a lot better. Imagine if passkeys could be saved, transferred, and imported as easily as a PDF. Instead, we get a bunch of walled gardens where Apple/Google/Microsoft/etc are trying to be the only provider you use.
I gave up on passkeys after running Google's passkey demo and getting started example. They impement session expiration client side only. I reported it, but they said it had been reported already and they didn't intend to fix it. Seems a little careless for a tool promising improved security.
I've noticed a few websites I frequent have quietly started using passkeys (or something very similar) outside of the normal channels. My bank now asks me to go through a second factor on my phone app that seems very similar to how passkeys work and Outlook has a similar login flow but with an additional 2 digit challenge code for some reason.
With both of these I have little sense of what is going to happen if I lose my phone or switch to a new one. So typical passkey problems.
Somewhat related: last New Year the company I work for gave us, the employees, presents. Something I assumed to be a USB disk. Couple weeks ago I had to migrate from my old personal laptop to the desktop I finally put together and needed a USB key to put an OS on the new computer.
I recalled I had what I thought was a spare USB key... plugged it in only to discover it wasn't a USB disk. Wasted some time trying to figure out what it was only to discover it was some form of electronic key. Not sure how exactly it works... but, of course, Linux had no drivers for it, so it couldn't even recognize the device.
I tried to think about any possible uses I could want from it and whether it's worth the effort of trying to find an out-of-kernel driver for it... and after some time pondering this idea, I realized I have no use for this thing. There's no scenario in which I would like to have a device to perform this function. So, bundled it with the broken pieces of my old laptop and together they went to the garbage dump.
Passkey would be virtually the same thing. I cannot imagine what problem does it solve, no matter how it works. Everything about this idea seems like a bad idea. So, I'm kind of happy it's a shattered dream now. Better late then never, I guess.
Bitwarden now official released passkey support on mobile app on iOS/Iphone in Version 2024.4.2.
If there will be a way to backup and restore between competitors, for example from bitwarden to 1password or vice versa, im fine to go with bitwarden now.
Backup and import passkeys from Bitwarden to Bitwarden already supported.
So please FIDO'S contributers, find away to standardize backup&restore passkeys.
The solution to most of the author's criticisms lies in not forcibly mixing Passkeys and WebAuthn-based 2FA.
As long as you are satisfied with passkeys being "usernameless" (i.e. discoverable), you can offer a nice login flow with a "Sign in with a passkey" button and Passkey Autofill.
For 2FA use cases, you should provide a second WebAuthn configuration that does not require discoverable credentials, for example, and does not necessarily require user verification.
This allows a user to have both fully-fledged passkeys and, for example, security keys as a second factor to secure username/password-based login.
Users can choose what they want to do (create a passkey on e.g. iCloud or add security keys as 2FA without using precious key storage resources on the hardware tokens).
GitHub has done a very solid implementation of that model, and we are working on adopting it to our services and it's looking very good so far.
Oof, the Passkeys ecosystem is incredibly complex. Even as someone that deals with it day in and day out at $CURRENT_CO, it can be a headache.
As an exercise from a developer's perspective, try creating a chart of every device type (mobile, desktop etc), browser, and Passkeys platform provider (Apple, Microsoft etc). Then fill out how each behaves across each combination, it is a nightmare!
I'm hopeful that we'll see more cooperation across Passkey providers to align both the devx and UX to increase adoption where it makes sense. Not holding my breath too much though.
I am exploring this now, actually got 2 students doing their thesis on this. It's very complicated and unnecessarily so.
My conclusion so far is that it's a promising technology, but no way as mature as I'd like it to be. Unfortunately we are stuck with emails and passwords for the foreseeable future, at least as a back-up mechanism for credentials recovery, which, funnily, makes the whole thing pretty much pointless.
Definitely this. I think the worst aspect of Passkeys is that the noble goals (public key crypto! unphisability!) seem to somewhat unavoidably wipe out one of the--in hindsight--really valuable aspects of passwords-in-a-password-manager:
That you can always just copy them out, put them in a different password manager, or write them on a post-it.
That said, I think this is a byproduct of the design space being complex (as you suggest) and not, as the author seems to feel, "thought leaders" or malice.
I've been using Passkeys saved in 1Password, I thought that gave me the power to transfer them, but I just looked and apparently the export feature of 1P doesn't allow exporting the Passkeys, it just tells you you need to create new ones in your new password manager, so that's pretty crappy...
Yeah I agree. I am familiar with crypto and public key authentication and password hashing and so on, and I cannot follow all of the terms and use modes. To the average user it's going to be a complete black box. They won't have a clue what's going on.
With passwords it's fairly obvious. Even if you don't know about password hashing, semantically it is the same as how you would obviously expect. Same with password managers. It's obvious what they're doing.
So I think this would fail even if it didn't have all the problems the author mentioned - it's simply too complicated for normal people to understand and trust.
Yeah, unfortunately passkeys are confusing and the UX is generally fucking awful. I hesitate to just blame the tech companies for being greedy, as a result of my experience with passkeys I'm starting to wonder if maybe they've legitimately just lost the skills and knowledge necessary to actually make usable software.
What's most disappointing is, password managers have already solved the problem of syncing credentials securely between multiple devices across different form factors and ecosystems, and they're perfectly usable for providing software passkey support. So of course.. there's no standard API for them to implement it. Instead, vendors are patching the WebAuthn APIs using WebExtensions.
FWIW: MacOS and iOS allow third party password managers to ingrate directly into AuthenticationServices and list passkeys in the native passkey UI through a "Credential Provider" extension. And it's documented how: https://developer.apple.com/documentation/authenticationserv...
This is the same Credential Provider API they already have to integrate with to show the password autofill in iOS so there is already _some_ code for this.
1Password _could_ just integrate with the native UI. But they chose not to.
This however means shipping a native app which is a lot more heavy-weight than shipping a web extension.
I opened an issue in the webauthn repo about giving an API for WebExtensions to hook into the passkey autocomplete but there hasn't been any traction or appetite for it unfortunately :(
> 1Password _could_ just integrate with the native UI. But they chose not to. This however means shipping a native app which is a lot more heavy-weight than shipping a web extension.
I mean, I kind of understand this; they're going to have to do the WebExtension either way, since there's no standard API across platforms.
On the other hand. They already integrate with this API for their iOS app as it's the only way to do password autocomplete on iOS. Why not extend that use to MacOS?
You can have multiple passkeys (using different devices or passkey providers) for a single site too. You don't need to fall back to another login mechanism.
> Within enterprise there still is a place for attested security keys where you can control the whole experience to avoid the vendor lockin parts. It still has rough edges though.
Just use PKI / X.509 with hybrid smartcards for enterprise use cases. Sure, it’s “legacy” and you need an PKI expert to set it up, but it actually works and is genuinely platform-, vendor- and protocol-agnostic. FIDO is smelly poo poo in comparison.
Also, smartcards had usernameless for 30 years.
Edit: actually we’ve been here before. Remember the <keygen> tag? Platforms (browsers) could generate a key pair for you, store the private key in their key store (I think <keygen> actually supported smartcards as well), and forward the public key to the server for enrollment. The server then sent the signed certificate back. That’s pretty much exactly passkeys. This was somewhat widely used for “high security” applications at its peak, circa 2007.
Similar problems like passkeys caused issues, it was difficult for users to get their keys and back them up, most people were just one hard drive crash away from loosing access.
Just wanting to get rid of "passwords" means getting rid of "something i know" as an authentication factor. That should not be the goal. The issue is that the other authentication factors have real drawbacks. It's tradeoffs all around.
'something i have' means carrying something around and also the possibility of it being forgotten/stolen/broken/taken by authorities (legally even!) and the repercussions of that. i'm fine with this, only if i am allowed to access/export/copy/store the keys myself. I can do that with totp auth and i do. people say this "breaks" security. but the point is: i control what i own; i control me (not you).
'something i am' has the worst drawback. you can't change it! the other issue is you are not the unique snowflake you think you are. Also, side note of a personal experience: India has mass fingerprinted everyone, yet in trying to do some bank transactions in India the fingerprint read/auth kept failing for an acquaintance.
There is no auth panacea. There's too many different use cases, too many players involved. You cannot create one "thing" that solves all the problems for all the people. It was hubris.
Instead, if "the industry" wants to solve "the problem", they need to write down all the use cases. Then we can argue about how to do that, and the result will probably be a couple different things that solve a couple different groups of use cases.
But what will always suck is letting "the industry" dictate to us "tech peons" how that should happen. They always come up with bloated standards that are a pain in the balls. So rather than let "the industry" solve the problem, I think we need a loose confederation of open source contributors and corporate goons to meet on some forum somewhere and hash it out. Let the solutions (plural) come organically without a single player controlling the conversation.
I am fully invested in the Apple keychain ecosystem, I’ve got multiple Apple devices (laptops and a phone) and passkeys have been incredible. Haven’t seen any of these issues.
I can understand the frustration from the author’s point of view, but I live with the other side of 2FA through weak SMS every day. My users can easily be tricked into giving up their 2FA code while being social engineered, and passkeys offer me as a developer a way to give them a more secure solution that I don’t have to worry about them reading aloud to someone calling and pretending to be CS. This is a weakness in the core of 2FA via SMS, and the author seems to be just hand waving away from that. No one SIM swaps their way to compromising a passkey, and no user can share their passkey with a scammer as far as I know.
How about we stop reinventing the fricken wheel every 3 years and let users adopt something? U2F keys were pretty danged good and they were easy to explain to my 70 year old parents "This is like your front door key to your house, it's a physical key to your Google account".
I use iCloud's Passkeys extensively and have never had saved Passkeys "wiped out". I am not disputing that data loss bugs can happen, but three times for one user sounds pretty weird given the maturity of the ecosystem.
The most obvious explanations seem to me to be:
a) Apple loses data (presumably not just Passkeys, but also photos, passwords, and other highly noticeable stuff) all the time, and I've been lucky for the last ten years. Hundreds of millions of Apple users just learn to live with this.
b) The author is doing something weird.
c) This is hyperbole.
I'm probably picking nits, but it's like an article raising a bunch of legitimate criticisms of the internal combustion engine mentioning that the author's car has, while sitting in the parking lot, simply exploded on three separate occasions. Like, maybe?
It's not hyperbole. I recently (few weeks ago) got locked out of my GitHub account after iCloud Keychain thrashed my passkey and after analyzing the root cause it turned out to be a bug in webkit (that is now fixed in Safari technology preview after me raising it with the Webkit team)
The author is the main dev of an identity management platform and called kanidm, so yeah I'd wager their usage is fairly non-standard. That said, it should be almost impossible for it to happen anyway.
One thing that comes to mind is with the earlier WebAuthn implementations in iOS, before they were stored in iCloud and called passkeys, there was no management interface for stored passkeys and 'clear website data' (to delete cookies etc.) would actually erase all credentials permanently. It was useless this way.
I do not mean passkeys in general but early iOS implementation was useless since it deleted passkeys along with your cookies and other website data. The passkey iOS implementation is useful in its current form.
You generally enroll a passkey for a single device or connected group of devices. My icloud-syncing devices has a passkey. My windows laptop has another. My desktop has yet another. I have also enrolled my yubikey.
I could stop using my idevices tomorrow and not be negatively influenced.
I can't speak for OP, but for every service that I use passkeys with I enrolled both iCloud Passkeys (for convenience) and several YubiKeys (for portability and backup).
This is not different at all from a SSH public/private key combo. You are not supposed to duplicate SSH keys!
Your answer is totally reasonable, but I admit I don't have time for that in most cases.
1. Most services are not Passkey-only--most people are using it as a password alternative (e.g. eBay) or a second-factor alternative. So losing it won't lock me out.
2. A very small number (e.g. Google) let you configure Passkey as your sole second factor. For those, I am indeed careful to do what you do and have duplicates.
I do think this is kind of bad? So the grandparent totally has a point here: services find it hard to do only Passkeys (and thus realize the security benefits).
But, as a user, it's not something I worry about a lot, to be honest.
I was about to type something similar to this as well! I use passkeys pretty heavily, with iCloud sync. Never had an issue.
The only similar issue I can think of is sometimes my Macbook will loose the contents of the on device wallet, including in one case an ssh key stored there. That was somewhat annoying!
Agreed. I'm not so sure that some of the iCloud data loss bugs people talk about are actual data loss bugs. I've had a few issues over the years.
Firstly I spent weeks chasing down what I thought was a data loss bug in iCloud. After much effort I managed to reproduce it. Turned out it was an issue with TeXshop rather than iCloud.
Secondly, the one time I had a photo lost, it wasn't lost. I just couldn't find it in the 12000 photos I had. It wasn't where I'd left it.
The third one was a data loss bug, was reproducible, was reported to Apple and was fixed. This was due to how Numbers handles three devices and how it decides the winner of a conflicting change and was an edge case as number 1 awkward customer.
YMMV but user testimony may be as reliable as eyewitness reports.
To be clear, I don't work for Apple. :) And I'm not discounting that there are usage patterns that might lead to persistent bad experiences (like your example with Numbers).
But the implication that Keychain just kind of forgets saved Passkeys once in a while seems alarmist and probably unfounded.
Yeah exactly. It is possible that some expiry or provider specific bug may lead to revocation? I am not sure how it works entirely.
I will say that there are some very well known backup and restore issues with keychain however so I keep anything critical in MacPass as the primary copy.
> Apple Keychain has personally wiped out all my Passkeys on three separate occasions. There are external reports we have recieved of other users who's Keychain Passkeys have been wiped just like mine.
i have been using passkeys on apple since they launched it. i have also converted all of my 2fa’s to passkeys (where supported) or enabled them as password alternatives. a lot of website support passkeys nowadays. i never encountered what the author encountered and it seems like something seriously wrong happened.
did anyone encounter this issue? is it logged somewhere?
i seriously considered dropping passwords completely for future projects, but it looks like there are still issues…
I always set up two passkeys, one in iOS and one in bitwarden. I use the former on my phone (obviously) and the latter on desktop, in addition to “normal” logins with 2FA.
I haven’t had a single issue yet, and while I accept that it would be annoying if iOS suddenly wiped my keys, I really feel like it shouldn’t matter: ideally you shouldn’t have only one passkey to begin with, but even if you lose it, all services I use still allow “normal” logins as long as you can 2FA with a phone number or email.
> This library ended up with Kanidm being (to my knowledge) the very first OpenSource IDM to implement passwordless (now passkeys). The experience was wonderful. You went to Kanidm, typed in your username and then were prompted to type your PIN and touch your key. Simple, fast, easy.
> For devices like your iPhone or Android, you would do similar - just use your Touch ID and you're in.
The fingerprint scanner on my phone is so finicky this would've been a dealbreaker from the get-go. I regularly have to just enter my PIN because it refuses to recognize my fingerprint.
Authentication has become incredibly complicated for normal users.
I work in cybersecurity and need to think hard and draw diagrams to understand how modern authentication systems work (modern = something more than passwords). The implementation part is hidden from users but they only understand "password". Sometimes "fingerprint". Anything above that is really tough.
While Passkeys are an interesting development, it will take time before they are part of the authentication routine of standard users.
I may be mistaken in its implications, but given the 9th Circuit's decision in U.S. v. Payne this week [1], I don't know if moving all our password knowledge to biometrics is a secure idea.
I can't help feeling this... In an adverse world software and electronic data is too ephemeral to entrust with authentication and authorization. What if we had something solid like a Yubikey, but:
Just to clarify Estonian Id-Card most certainly implements the PIV applet while Yubikeys implement both PIV and the OpenPGP Card (the latter has a benefit of natively supporting ed25519: https://github.com/wiktor-k/age-plugin-openpgp-card).
within a business where we have policy around what devices may be acceptable the ability to filter devices does matter.
Is a solution to this on desktop to use GPO policy to add a mandatory "attesting" extension (that you build yourself which just verifies the device is what it says it is), and on mobile to use a webview inside an app with similar attesting info injected into the page context??
I think passkeys can be used just like biometric authentication is used in mobile apps right now: you sign in just like you usually do (e. g. username + password + TOTP or something), then on subsequent visits you can skip that and go through passkeys instead. New device? Just sign in with a password again.
This feels overly cynical to me. The article is a bit rambly so let me try to distill the problems:
1. Most relying parties support resident keys only. This makes a bad user experience because users are surprised when they run out of space, and may have to wipe their device to get more.
2. Most authenticators do not allow you to export your keys. If a relying party only allows a single credential per account, this creates authenticator lock-in, which is a bad user experience.
3. Chrome is uncooperative about the Authenticator Selection Extension, and that can make a bad user experience if the relying party rejects the device attestation after enrollment.
Yes, these are all bad user experiences, but they don't indict the technology. It sounds to me like the relying party can mitigate all of these issues:
1. Support non-resident keys. Seems like it really doesn't have to be a bad user experience. Usernames are easy to remember. Just use their email address.
2. Support multiple keys per account. Most users will have multiple authenticators. Let them enroll several and they're not locked into any one in particular. Most users won't care about this, but for important services it's an option.
3. As a relying party with strict authenticator requirements, just explain those requirements on the passkey registration page. People can read. They don't have to be that confused when their unsupported key doesn't work.
I get that there's nothing users can do when the relying party creates a bad experience, but if a relying party has all the power to create a good experience, is it really worth being this gloomy about the technology?
If the underlying technology is poorly specified and confusing enough that it doesn’t get implemented well in 95% of cases, then yes, that does indict the technology. See also: PGP and email encryption in general.
But even if on balance the tech is worth implementing, it’s clearly not easy and your suggestions to “just” do several things that aren’t happening ring a little hollow.
I only used "just" twice, and they were both justified. Having people remember their email addresses, and explaining something in a couple of sentences, are both pretty easy.
Points #1 and #2 are not entirely trivial, but they're not much more complicated than the alternatives. A relying party has to store the public key counterpart to a user's private passkey no matter what. Is it really that much harder to associate that public key with their user ID? Point #2 is probably the hardest to overcome if you already baked in the assumption of 1 key per user. That's concerning. But that problem can also be mitigated by the authenticator, by supporting export.
I'm not saying the article fails to identify real issues. I'm saying it fails to identify insurmountable issues. The nice thing about software is that a good canonical implementation can be used by everybody for free.
1. SSH keys, as they're normally used, let you be tracked between hosts. That's fine for SSH, because nobody's trying to SSH into their Grindr account. But for web login stuff you want a different key pair for every site.
2. Adds a bunch of 'attestation' features that corporate types think they need.
3. Tries to make it so an attacker who gets access to your machine can't make a copy of the credential. The success of this is implementation-dependent.
4. With barely any setup, Google/Microsoft/Apple will keep a backup copy, in case you lose your phone. This is useful for non-technical people.
> With barely any setup, Google/Microsoft/Apple will keep a backup copy, in case you lose your phone.
Not Microsoft. Their implementation has no synchronisation feature and provides no way to back it up or transfer to another device either. You lose the computer you lose the passkey.
Their implementation is very daft and goes counter to the point of passkeys since you will need a less secure way of authentication to remain enabled on the accounts you use a Windows Hello passkey for, for the sake of being able to recover those accounts.
Remember, the best security schemes are only as secure as the least secure scheme that is available to access the account. If you're still on an account that can be recovered by sending a 2fa code to email or SMS/texting then you have achieved nothing.
Passkeys are pretty useless for me. At first I was somewhat hyped, but it seems that everyone just ignores them. Chrome does not support them. I set it up on mac, today I tried to login to icloud using passkey, but it just didn't work. Few websites implemented them, but overwhelming majority of websites don't.
So, yeah, useless technology for now. Passwords and TOTPs are the way.
Linux most definitely has a TPM interface, it's called /dev/tpmrm0 and plenty of libraries for accessing it (eg. https://github.com/parallaxsecond/rust-tss-esapi/ full disclosure: I'm co-maintaining it). Systemd is not needed for that.
IIRC, all these hardware exist. Software is not 100 % fine for them. The point is to have OS and password manager trust each other. Once this is done then all should work. That should allow for the browser to query the password manager for appropriate info. At the moment, password manager is poorly integrated onto OS.
So where are things falling down? I seem to be unable to get passkeys to work in linux; Chrome or Firefox. I’m suspecting the issue is something to do with bluetooth.
Likewise frustrated by the passkey implementation but like the idea. I’ve been experimenting with passkeys leveraging SSH tunnels. You can read more about it with a demo here: https://pico.sh/tunnels
You use it because a concensus of security experts is cool with them, a normal person has no way of analyzing it properly. I see a few post regarding “I rather stick to generated passwords and have a program memorize it for them” it’s rather funny the way they rebuke new vetted tech
At TableCheck we rolled our own passkeys SP implementation primarily for our internal users, so they can access admin-level accounts without passwords.
Personally I love the convenience of passkeys (coupled with 1Password pw manager), however, for whatever reason it doesn’t “feel” like Passkeys replace passwords but rather they complement them. I treat Passkeys as ephemeral—it is lovely when they work, but sometimes I still need to fallback to trusty ol’ password login.
It seems like most of these gripes are due to the web app's implementation, and not passkeys themselves. It's a bit harder supporting multiple passkeys, but certainly doable. As others have said, this is just FIDO2/WebAuthn.
I use Strongbox and store my Passkeys in a Keepass File. Vendor agnostic, private syncable and locked by my passphrase.
I like them and wish more services would implement them properly.
Passkeys has a good UX and security balance. The other method would be to memorize a 20 length random password all inside your head or let grandma create a “password” so she can easily memorize it.
Tech articles have gone the way of online recipes. I had to read his grandfather's biography to understand he had a bad experience logging in with passkeys
I suppose this means OTP's would continue gaining traction as an alternative to password managers, a convenient approach but a risky single point of failure
Hm. The main criticism is you get locked into a cloud platform storing your private key(s) when using „passkeys“. This can be convenient as you can use your favorite smart phone to authenticate everywhere or even choose to rely on local TPM storage on your laptop or PC through MS Windows. This trades convenience with the risk of a vendor lock-in. But AFAIU the FIDO2 protocol you are free to use a dedicated USB key storage instead to store your private key (protected by a PIN or passphrase) on your own. This a bit less convenient but gives you peace of mind if you hate MS/ABC/Apple.
In theory there's no vendor lock-in. As long as Azure adds your vendor to the Azure-approved list, and as long as every other provider refrains from making their own list.
In theory any FIDO2 implementation could work with any service that accepts passkeys. In practice, compatibility matrices and allowlists are the reality.
In both cases, you can put secrets into the hardware but can't extract them back out. You can _use_ the secrets stored in the hardware via your fingerprint to facilitate logins but you can't extract/copy the digital data from one Yubikey to another Nitrokey. This restriction for USB vaults is deliberately designed for security but typically isn't disparaged as "vendor lock-in"
However, increasing website security via "trusted hardware" by making everybody spend an extra $50 for a USB vault is not ideal. Instead, a bunch of security experts noticed that billions of people are already carrying smartphones that have built-in biometric security such as face-id and fingerprint readers. Ok, let's just piggyback on existing smartphones and make them "act like the $50 Yubikey/Nitrokey" -- which means mobile passkeys managers like Google not allowing simple export/copying of passkeys.
Yeah but desktop managers like 1Password, Bitwarden, KeePassXC allow export of passkeys! True, but there's controversy and disagreement about that because they're not restricted like the Yubikey hardware is. Will some websites that are very strict reject some clients that allow passkeys export? It's a wait & see.
If the "ideal" passkeys ("ideal" from the RP Relying Parties point-of-view) are for them not to exportable/transferrable to another device, how do they expect people migrate from Apple to Android or whatever? By generating new passkeys for that new device and adding it the list of approved passkeys the website accepts. Instead of transferring the secrets, you re-generate new secrets.
> when the room is in a country that has a list of travel advisories including "Violent crime is more common in the US than in Australia", "There is a persistent threat of mass casualty violence and terrorist attacks in the US" and "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance".
Indeed, the author is not alone. It may be subjective but there are worries one needs to reconcile when planning a trip to the US (both for work as well as private trips). It’s often that we choose another destination or “can we find a way to make this remotely”.
"I'm Australian so I wont be attending either (I am not comfortable to enter the US due to a preexisting medical issue)."
That's the "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance" part of the text.
I do not know if travel health insurance generally covers complications from a pre-existing condition, and as other mentioned, getting travel insurance which covers the US is already a special case.
The last time I was in the US, specifically in Seattle, there were two separate shootings within blocks of where I was at the time, and one at a bar an hour after I left it.
As an Australian, seeing it on the news the next mornings made me very, very uncomfortable.
I understand that these shootings are unlikely to ever involve me, and I’m not discomforted to the point that I won’t go back to the US, but it is worth understanding that gun crime in the US is seen as uncomfortable and concerning to many. That my US friends who were at the same venues with me were completely blasé about it left me a little nonplussed.
I think it's a hefty chunk of paranoia. The US is absolutely a non-issue unless you have previously pissed them off. This is the same for every country.
What is not is walking 30km in the middle of nowhere in Central Asia because you didn't have enough cash to pay the driver's bribe. Stuff like that is a far more realistic concern than the security border paranoia stuff that goes on. Know where you are going, plan ahead and stay out of obvious trouble. That applies everywhere. The US is not special.
(Incidentally when I got to the first town, the guy in the shop laughed at me and invited me in for tea and dinner on him and his wife and I got to learn all about their history under Russia - it's not all bad)
Apparently... of course, the threat of "mass casualty violence and terrorist attacks" is real, but you're probably still more likely to die in a plane crash while getting to the US (or in a car accident while there) than in a shooting or terrorist attack. And if you insist on only travelling to countries that have a lower level of violent crime than Australia, you probably won't get around much (https://worldpopulationreview.com/country-rankings/violent-c...)...
Oops, you forgot the other 2 travel advisories the author quoted in that part:
- "Violent crime is more common in the US than in Australia"
- "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance"
I think some Americans don't realize that, outside of America, many people don't ever consider the risk of gun violence in their day-to-day lives, or owing thousands of dollars for visiting a hospital.
That second one needs to be pointed out in particular - the US healthcare system is so expensive that if you have healthcare insurance as a foreigner, they're typically excluded from the international plan. You have to specifically go out of your way (and pay more) to make your local health insurance cover the US.
To be fair I've been to the US a few times and I've never been shot and I did end up in hospital and it was smooth as butter. Because I didn't hang around where I was likely to get shot and actually checked my insurance cover and had the cert on me.
Note I live in London and everyone tells me I'm going to get stabbed too and die from the pollution...
London's homicide rate is (roughly, depending on which source you use and year you take) about one-fifth of the average US homicide rate; you are safer in London than in almost anywhere in the US.
13 per million per year in London. 60 per million per year in New York.
That's an 0.006% chance of getting murdered killed in NY every year.
And that doesn't account for (a) putting yourself in a good position to get killed like being a gang member and (b) the aggregate reduction in risk by only travelling there.
I've heard horror stories about hospitals not accepting insurance. Wouldn't want to be in a situation of being ill and having to pay more than I can earn in a lifetime.
They will accept it. The cover has to be specifically for US hospitals otherwise the insurer won't pay out and they know that and won't accept it. You have to avoid insurers who only cover certain providers as well.
You have to read your insurance contract and info sheet properly rather than go for the lowest price.
The homicide rate in Australia is particularly low. But in terms of overall homicide rate the United States is higher than the vast majority of other developed countries, and indeed most developing countries.
Most of the world sees the United States as a dangerous country.
For example, using the source you've just given, the US homicide rate is over 5 times the homicide rate of the United Kingdom, France and Germany, and over 10 times that of Norway.
Granted, you're more likely to die in a car accident than to be murdered in the US, but that's no reassurance; this is partly because the vehicle accident mortality rate is so high in the US, at over four times the rate in the UK. And your comment about dying in a plane crash is completely wrong: the air travel mortality rate is very close to zero, with under 200 deaths for over 800 annual million air travellers; a rate of less than 0.025 per 100,000 per annum.
I know that US is vast, and there are millions of good places where one could feel safe, but I assure you, from the outside sometimes is seems you live in a mad max alternate universe
Sure, but those rates are also really low. That’s a bit like saying you’re scared of using your car because a plane is much safer. The chance of getting hurt while visiting a meeting in Silicon Valley is still one in a million.
Worse than that, having a gun doesn't make you safer; it increases the risk to everyone in your household. But I can absolutely understand why fear drives people to own guns -- it's a vicious circle as increased gun ownership drives fear, which in turn drives even more gun purchases...
Good riddance. Any system that limits my options as power user I will not promote. Lots of services only let you enroll single passkey and "hardware attestation" would only make it even bigger lock-in.
I like passkeys as idea for stonger security, but author somehow thinks that discrimination against devices is a good idea.
Sorry, no. Just no. I dont want my bank or paypal require me to use iPhone in order to login to my account.
The main thing that hurts Passkeys was how the implementation was so deeply tied to letting the browser do stuff rather than making it something like TOTP where any password manager can implement it and it's usable, agnostic from the browser. Everything about Passkeys is defined around using your browser as the agent that authenticates.
The problem is that browsers are infamous for randomly losing things like localstorage, settings and saved passwords. It's way too volatile software to do authentication with besides a "stay logged in" checkmark. In both of the main desktop browsers, a corrupt profile is often only "fixable" by just nuking it and having the browser recreate it.
That's what killed Passkeys; people you want as early adopters (technical folks) don't use it because browsers aren't a trustworthy storage and the implementations all severely stalled in providing alternative methods that are tied to more reliable storage mechanisms. The hyper aggressive vendor lock-in is also not helping much (to the point where KeePassXC got yelled at for providing an export mechanism).
Because if something is new, then it's automatically better, even if it's not, so it gets a hype cycle.
Honestly I'm just relieved this appears to be crashing and burning on the runway. Crypto bullshit's gone through several destructive hype cycles by now and the main consequence of the latest round of the AI craze will be a nuclear wasteland of an internet.
I get the capitalist inclination and desire to make things easier for people (and often infantilize them) but this just ain't it.
There is no easy solution here. Security is difficult and there are no shortcuts that involve "make things easier for the general public" that don't ALSO involve "make things MUCH HARDER (either in complexity or LIABILITY for getting it wrong) for the company providing the security."
This was so obvious from the start. Whenever big tech creates "standards" now you already know it's going to be total horse shit. Look back at the old threads when passkeys launched. HN was full of fanboys thinking it's the best since sliced bread and passwords are so yesterday. Managing your passwords takes a bit of effort like everything in life where you don't want do give away control completeley to some corporate aholes. Whenever you let someone else manage your stuff you set yourself up to getting ducked.
Passkeys are being pushed by Government and Law Enforcement because PASSWORDS WORK and frustrate them. Police access 95% of the phones they seize so they want passkeys to be the norm because once they own the phone they own EVERYTHING you secured with passkeys.
