In some parallel universe, each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys). Instead of "many cooks" mentioned in the article, there is one standard.<p>I cannot bring myself to agree to any "switch to passkey" prompt from any device because I have no idea (and too tired to figure out) how and where that key will be stored, how do I deal with different devices, etc. I already have a universal solution for credentials: 1password, which is cross-platform. With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account and at best synced between devices from the same manufacturer. But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.<p>Like with many other solutions, the current approach with passkeys is designed for an imaginary "user in vacuum" model each company dreams about, where people are 100% into one ecosystem, forever.
The article author skirts around the key true observation here, which is that passkeys were a great idea until cloud vendors waged war on hardware keys.<p>The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.<p>The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise.<p>The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware - they want you to use a cloud-hosted passkey instead of using a Discoverable Credential on a Hardware Authenticator, and instead of using a password manager providing its own sync facility. This is shown in the screenshots in the article.<p>The ideal future state is:<p>* the provider for newly registered credentials would be a browser setting<p>* the setting would come configured to use the OS vendor out of the box<p>* installing a password manager providing passkeys would prompt to change the setting to use the password manager instead<p>* one of the options in this setting would be "prompt me every time". Approximately nobody would choose that option<p>* there would never be a prompt for what to use on authenticate() calls, only register(). Authenticate would use whichever valid credential you provided first, whether that's plugging in a token or scanning your thumb to unlock a TPM or whatever<p>In this world, 99% of people are using OS-vendor-provided cloud-synced passkeys, but technical users get what they want too and everybody has both a secure and an easy experience.<p>The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor, and they have a conflict of interest because the OS vendors are also cloud services vendors.
TOTP suffers from a similar issue - I use 1Password to store my TOTP codes, but both Google and the UK's HMRC tax website talk about using their own apps for codes rather than anything agreed like "one-time passwords". The digital world is rife with this kind of jockeying for position through language. It took me far too long to understand that "podcasts" are just mp3 files from an RSS feed.<p>Likewise, in the heyday of interactive TV in the early 2000s, when it was going to conquer the world because everyone had a TV but not a computer, an agency I worked for were invited for a demonstration of a choose-your-own-adventure game they were developing. They kept referencing a "carousel system" where all pages were sent in a looping system and when someone made a choice it waited until that page came round in the "carousel". I kept asking whether that was like Teletext - <a href="https://en.wikipedia.org/wiki/Teletext" rel="nofollow">https://en.wikipedia.org/wiki/Teletext</a> - but they absolutely refused to say that and kept saying "well, it's a carousel system".<p>This refusal to deal in everyday language, alongside trying to get people to use their own apps / sytems, really hinders the adoption of useful technologies.
Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.)<p>Bitwarden is one of the few that don’t - you can export passkeys, although for now, there’s nothing to import them to unless you want to run a roll your own open source solution.
While I agree with many of the points raised by the author, I guess I just had much much more pessimistic expectations than they did. If I were to write an article on the topic, I'd probably end up listing the exact same factual information, but with the opposite spin: "This is progressing much quicker and more smooth than I would have anticipated!"<p>Switching from passwords to passkeys is a <i>big</i> change in the entire security model of the modern user-facing internet. We shouldn't be at all surprised that people are both cautious and opinionated about how it should be done, how to migrate users, and how to deal with fallbacks.<p>Yes, the current situation is one that is messy and not significantly more secure than the previous status quo, but the direction of travel seems at least promising.<p>I wouldn't actually want my bank to overnight decide that passkeys are the way to log in, and if I use a passkey there should be no insecure fallback options. I want my bank to roll out a passkey, and figure out the infrastructure around it, probe for problems, and allow fallbacks that are equivalent to their previous systems. Similarly, I wouldn't want every passkey management implementation to instantly coalesce around one specific set of management practices and UX. I want various ideas to be tried out and see what comes out of it, even if some of those experiments are bad.
I think passkeys are a failed product. Time to give up and start over again.<p>I don't say this casually. I have been arguing for ending passwords for nearly 20 years now. I'm a software engineer and broadly understand a lot of security protocols. I spent hours understanding passkeys and figuring out how to use them in my environment. The core idea is great! But the usability is garbage.<p>I still can't use passkeys reliably. The combination of bad implementations in Windows, Chrome, 1Password, and various websites has defeated me. All passkeys do now is clutter up the one login flow that works for me (1Password form filling, as awful as that is.)
I seem to be in the minority of HN users that love passkeys. I use them for any login that I reasonably can. When creating a passkey I create one in iCloud Keychain as well as in 1Password. I do agree that there needs to be a better import/export story, but I have confidence that will come.
It’s invisible. A black box, non transferable. There’s no mental model that maps and you can’t back it up as a normal person. Implementations are half baked and still require all the rest, all the attack surface is even larger.<p>Was super excited, totally not anymore.
As a technical user who understands how these work and has none of the confusion issues the author describes, my biggest problem and the reason I stopped using them for google is they seem to arbitrarily set the session length for passkey authenticated sessions much lower. I found myself needing to reauthenticate with google every day or 2 when signing in via pass key. I assume the developers thought this would be seamless, but it is a very annoying interruption to workflow. Especially since I use 1password as the backend with my laptop screen closed it results in me needing to type my (long and complicated) password manager password every time and usually when I am trying to access something timely like a meeting invitation.
I think the elephant in the room is the total lack of website/framework/library support Fido has. Trying to implement support on any random site is about as insane as rolling your own crypto and having the single sign on bolt on is sort of how people selling FOSS+enterprise want it.<p>The end result is that it was more a standard for them more than for direct use by the little sites, and password managers getting involved only furthers that enterprise industry standard feel.
It gets worse. U2F keys were stateless, the site key pair was stored by the site (encrypted to, and by, the u2f key). Now, passkeys are stored <i>in the device</i>, and, you guessed it - they have a limited number of slots.<p>The fido2 situation is really bad.
This piece reads very nitpicky, and I just don't identify with what it's saying. My use of passkeys in Safari on Apple platforms has been basically seamless.<p>I guess if you use tons of different browsers on tons of different platforms and want to work in hardware tokens, it's a pain, but most people aren't doing that.<p>The problems highlighted are real, but they don't rise to the level of "Passkeys aren't usable security". For users that would have otherwise not opted into 2FA at all (or don't know how to set up TOTP), passkeys are fine. I'm sure there are some warts to iron out, but they have to be evaluated within the context of the practical alternatives, not the context of the author's own personal security priorities.
This matches my experience perfectly. As someone who is technically skilled but has no particular security expertise, I've tried to gradually implement passkeys where available across the most important and frequently used of my accounts, and... I'd have to go read the goddamn spec to have any idea what's going on. Pretty much all I've learned is that sometimes I can use touch ID to log into stuff now, and sometimes I can't, and the reasons are totally damn opaque.
Passkeys are simply over-engineered. A passwordless login system need only the following:<p>- $AUTHENTICATOR is one of (browser extension, browser, OS, hardware)
- $AUTHENTICATOR stores mappings ($SITE,$PUBKEY) => $PRIVKEY
- $SITE can ask $AUTHENTICATOR to generate a new $PRIVKEY and give it its $PUBKEY
- $SITE can ask $AUTHENTICATOR to sign a challenge with the $PRIVKEY corresponding to one of the $PUBKEYs for that $SITE
- the user can pick which $PRIVKEYs are synced and which can be exported (depending on $AUTHENTICATOR capabilities)<p>Bonus points for adding a way to do the authentication off-device through QR codes, so $AUTHENTICATOR one one device can authenticate a session on another device (like using a phone to log into $SITE on the desktop, perhaps for the purpose of adding another authenticator there).
Anyone know what adoption rates for passkey looks like now? I think they are cool too, but the constant prompting to create them and invisible/variable UI everywhere is a problem. It presents as inconsistent as compared with the standardized username/password form that grandmas understand.
I will never use Face ID or Fingerprint for any device, but I agree, passkeys are a bit too much. Also, the OSs I use may not support passkeys. They are not on the list.
The magic of password is that you can write them to paper or keep them in your mind. No interoperability issue if suddenly having to use it temporarily or permanently with another device, like if you lose your phone. And you can also pretend they don't exist and no one can prove otherwise. Also if you don't use a password manager, no one (hacker or else) can extract it from your head like it can be forced from your devices.
Passkeys deployment reminds me of a cartel agreement among FAANG without the actual coordination. It's too good of a new tech frontier not to colonize.
I haven't used passkeys, I have not been prompted about it, asked to create one, been reminded to change to it, or anything like that. It is like they don't exist to me. Am I supposed to be nagged about it in order to change to it? Or is it something you have to hunt for in the account details of a site? Unsure if I am a late adopter or if the technology has not found me yet.
> chosen to sync the passkey using my 1Password password manager. In theory, that choice allows me to automatically use this passkey anywhere I have access to my 1Password account<p>I have never used passkeys and don't know much about them, but isn't the main point that they're distinct per device?<p>If one syncs pass keys using a password manager, what benefit do they bring over passwords?
I'm so unimpressed with passkeys. It's just like blockchain, trying to solve a poorly defined social and legal problem with pie in the sky 'elegance' and overly complex technological solutions.<p>I don't think cryptography is the way to solve phishing. I mean sure it <i>can</i>, clearly. Bitcoin also works as a currency, but it hasn't stopped people scamming and stealing money.<p>If you're a person wondering if you need passkeys: you need a password manager instead. If you learn some basic safety habits and always trust your password manager, you get almost all the benefits of passkeys with almost none of the downsides.<p>Passwords— if used responsibly— are fine for 99.9% of what anyone wants or needs. To be responsible with passwords, you just let the computer do it. That's really the problem passkeys solve, just in the most typically obnoxious way.
The best way to solve a big problem is to break it up into lots of tiny problems.<p>It seems like, IMO, the best way to get the general public to adopt passkeys, and to refine (cough debug cough) the UI, is to use them in low-stakes situations, in a gradual rollout.<p>Instead of focusing on high-stakes use cases, like banking, perhaps:<p>1: Focus on low-stakes situations, like blogs and news sites<p>2: Services need easy ways to "add a device," such as opening a link in an email or SMS on the device they want to use.<p>3: Don't bother syncing passkeys across "devices." Instead, focus on syncing within the browser, where passkeys sync however bookmarks sync.<p>4: Work on APIs for a user to <i>elect</i> to use a 3rd party passkey manager<p>At that point, services like iCloud, OneDrive, Google Drive, ect, could also provide passkey synchronization. It's up to elect to use such services; because otherwise, re-signing-in on each device the user uses might be "good enough."
regular people strongly disagree. from what i can tell, people who aren't HN commentators or tech bloggers <i>love</i> passkeys.<p>you click "sign in" and you are signed in. that's the dream. my non-technical family and friends have been lamenting not being able to do that for years. my customers are asking for it.
I recently switched from Android to iPhone (and had to get a second iPhone because in <2 weeks I got more scratches on my screen than I have on my multiple droid devices used for 5 years...).<p>I learned a lot about 2FA from that experience... not in a fun way. The problem really comes down to this: let me register >1 devices for authentication! Luckily Google does this but many places don't. So you're kinda fucked if you exchange your device and don't convert everything first. Interfaces are crazy bad. Firefox is a good example: go to manage account, scroll down to "Two-step authentication" and you'll see "Enabled" with an option to "Disable" or "Get new codes". But I registered this into Ente!<p>Even FIDO keys say you should buy tap two. One to lock in a safe (they should make this easier by allowing some way to clone a key). Why can't I register 2 devices or multiple methods. More so, why can't I set some priority leveling like prefer security key, email if OTP is used, require message to fall back to email OTP.<p>This isn't just a problem with passkeys, this is a security problem in general. I really don't think there's enough thought put into how things happen in the real world. I'm pretty techy so got my issues solved but if it were my parents? Well they would swear at me for having implemented that security and never trust me again, falling back to much lower security. It's hard to blame them.<p>So does anyone know the real way to solve these issues? We're on Hacker News. Yes, the best security is if you lose a key you lose access, but this doesn't work for the real world and for most people. You shouldn't be at risk of losing an account if you lose or destroy your phone. We should also have solutions that don't require internet or reliance on big tech 3rd parties that get
Metadata as is the case with single signons. Yes, provide that option, but there's got to be a better way (that can also permeate into standard practices!!!)
I'm really not convinced by passkeys as a socio-technical phenomenon because it seems to lock people to their OS. As a technical user, having them in 1Password which is OS-neutral (and plans to support export eventually - I'll change my mind on passkeys if this never comes), they're great.
> And forget about trying to use a passkey to log into PayPal on Firefox. The payment site doesn't support that browser on any OS.<p>I had no idea! That’s pretty awful.<p>> Somehow, the mysterious entity responsible for this message (it's Google in this case) has hijacked the process in an attempt to convince me to use its platform.<p>I do <i>not</i> want Google to be managing my passkeys or passwords. Even if they promise to keep them device-local, I frankly don’t believe them: the temptation to make it easy for users who have lost a device or forgotten a password is too strong, and at some point they will take the plaintext, and then it is game over as far as security is concerned.
I'll be avoiding them until I'm sure that the attestation object is not being used as a nefarious back channel between the vendor of my authenticating device and the service that wants to authenticate.<p>The way the protocol is set up now feels like a slippery slope towards a world where I can't be sure that my new accounts aren't actually containing information about whether I had been to a protest recently or whether, at the time of sign-up, my biometrics indicated that I was in an altered state and likely to be easier to fool than usual.
How about every site and service let me use my username+password combination and stop bothering me with 2-3-4-5FA bullshit? I can manage my own passwords, thank you!
I don't know. If you're in the iOS ecosystem and using iCloud syncing and Safari things are super easy and default more secure than without passkeys. The author's examples of Firefox, chrome, a password manager and a physical key apply to very technical users who seem quite capable of navigating the complexities he complains of.<p>The vast majority of people are just not going to encounter most of his issues. I sympathize with his issues, but he's kind of complaining that fighting the ecosystem is complicated.<p>My guess is that <<1% of people use his combination of multiple browsers a non-iCloud pw manager and a physical key on MacOS. And they're not substantially less secure than his setup.<p>My only issue with passkeys is sites that don't seem to have them figured out yet. They'll let you setup a passkey but then offer to let you sign in with a password first. These seem to be becoming more rare, but even amazon's passkey seems random when it lets me use it. And even then it wants to send me a text message code anyway (this is probably a setting somewhere, so my fault I'm sure).
This article links to a bunch of pages at FIDO Alliance, the official passkey info source, pages like <a href="https://fidoalliance.org/fido2/" rel="nofollow">https://fidoalliance.org/fido2/</a><p>FIDO Alliance's website is pure garbage.<p>On first load all the content is covered by a demand you "sign up for updates!", a modal blocking the rest of the page. Also there's a surveillance consent popup that opts you in to tracking.<p>It takes 9.9MB to load this content-free page. Closing the distractions so you can read the content loads another 3MB.<p>Why would I trust this alliance for anything to do with website creation?
Why is it defaulting to passkey if i want to use a security key... probably because 99% of people will be using the builting apple passkey and not a third party hardware device that few have... hence why the hardware device is considered "other"
Forcing a new key pair for every single website was a mistake. If the crypto is secure than a single key pair should be suffice. That is how we use public key crypto almost every other use case and we get to avoid vendor lock in completely.
Every additional factor just weakens the chain. None of these solutions addresses the social attacks due to decreased usability. Users are more confused and have less control now. They will spam every factor to get to their resources.
I guess I am a bit dense when I create Apple passkeys for the few websites that support it, I don’t have any issues with using chrome or safari and macOS or windows? I will test again but I don’t remember experiencing this.
As an Apple ecosystem user i really like passkeys. I don’t have to remember passwords and once i set up a passkey on a device it’s synced to all my other devices.
It’s just really convenient.
Why not use something similar to SQRL instead?<p><a href="https://en.m.wikipedia.org/wiki/SQRL" rel="nofollow">https://en.m.wikipedia.org/wiki/SQRL</a>
I wasted an inordinate amount of time trying to fight Apple Vision Pro to get it to read my Yubikey.<p>I failed. My apple vision pro was rendered useless because of a single passkey.<p>Dumbest tech ever.
"Most try to funnel you into a vendor's sync passkey option"<p>Therein lies the problem.
Every vendor's profit motive and #enshittification means they want to own your passkey
and all the personal data associated with it.
None of the care to interop
or work with decentralized solutions.
They need your data,
and they'll do everything they can to lock you into their jail.
I like the idea of using a password manager, but I think we should be aware that can create a single point of failure. For example, the LastPass breaches.
Maybe someone can explain it better to me.<p>It seems that the primary goal for passkeys is to eliminate password fishing.<p>You still need a password for the site. Even with passkeys, you can still login with a password, either from a different machine, or, if nothing else, to recreate your passkey.<p>But passkeys offer a bit more security to enforce that you're actually sharing the credential with the proper site, correct?<p>Am I missing something?<p>I mean, there's the whole syncing passkeys across stuff, but that's all optional. There's no requirement for that. You should be able to configure multiple passkeys to the same site across your various machines (for whatever reason), right?<p>And I assume the sites won't "auto login"? Even with a passkey you would need to (potentially) hit a login button or something.<p>I just want to make sure I understand it clearly.
I agree with many of the downsides but the only devices I use are Apple. Macs, iPhone, iPad. For me, passkeys are universally simple.<p>Sorry other OSes and browsers other than Safari, which I switched to specifically for passkeys and Apple Pay, aren't as elegant.<p>That's Apple's advantage. Their hardware and software ecosystem.<p>And that's why I never look at anything else.
The most common lock and key ergonomics that everyone is familiar with is the following:<p>1. You have a lock, you have a corresponding physical key. You can have more identical physical keys. All of them will unlock the lock. If you lose the physical key, you can call the locksmith to change the lock. Physical key is anonymous. Only you know which key unlocks which lock. If a random person finds your physical key on the street, they shouldn't be able to find their way to your lock to try and unlock it.<p>2. That's all well and good. Now, comes a magic key. That's your personal magic key. Any lock you are permitted to unlock, your magic key can unlock it. Any key you are not permitted to unlock, your magic key cannot unlock. Now, you can more than one magic key – where only some of the locks you are allowed to unlock can be unlocked by one magic key vs another.
And if you happen to lose your magic key, you can call your locksmith to cancel your magic key – actually, that's a keysmith than a locksmith!<p>3. Your magic key is still anonymous. Only you know which magic key can open which locks. A random person who finds your magic key shouldn't be able to find their way to all the locks it can unlock.<p>4. When you see a lock, you are prompted to insert a key. The prompt doesn't say which key. You try one of the magic keys have that you think should unlock it. If it happens to the wrong key, not a big deal. You just try another magic key you have, and if that's the correct key it will unlock it.<p>5. When you buy a new lock (sign-up), you decide which magic key you have that should be the one to unlock it. This pairing of the key to the lock is done simply by asking pair a key to the lock. You are not being told to use a specific vendor of magic keys. You are not being peddled only magic key vendor over another!<p>6. If you want to change the magic key paired to a lock, you can do so at anytime on your own as long as you are in possession of the current magic key.<p>7. And of course, you can have multiple magic keys paired to the lock, so that you can unlock with any of the keys.<p>8. When you use a key to unlock a lock, the lock can tell which paired key was used – you can give nicknames to the paired keys that the lock remembers. The lock will tell you which nicknamed keys were used to unlock it previously and when.<p>-----<p>Here's where I think passkeys went awry. They became yet another platform war. The OSes and browsers are supposed to be neutral and provide an unobtrusive prompt for user to pair a key or use a key, that's it. And the user should invoke a keyring against that prompt. If the keyring provider has features – like portability or non-portability of keys etc that's unique to each key ring provider and as long as the user is comfortable with it, everyone should be good with it. The prompt needs to be unassuming. Today it is very assuming and that's the problem!
Lots of criticism in the article, some of it valid, none of it constructive.<p>Sure, there's UX problems as we're still trying to figure out what good looks like here. But in the absence of specific, concrete suggestions about how we improve usability for unphishable credentials, it seems that passkeys are a pretty good go. Perfect? No. Better than passwords? Undoubtedly.