Passkeys do marginally improve security against MITM and phishing attacks, but they are primarily for protecting the lowest common denominator from themselves: people who re-use passwords and/or don't use a password manager.
If you use multiple devices throughout the day, registering passkeys in all of these systems becomes a big headache with O(m*n) complexity, so putting the passkeys in a password manager is the only realistic solution. But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.
The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for. I've accidentally set up passkeys just by clicking an okay button a few times in the past and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
> The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for.
My irritation is that I know what it is, and I've said no thanks many times, but I'm still asked regularly by the likes of Amazon, and they usually pick a time when I'm trying to order something quick¹. It is one of the growing number of things in life that simply have no “no” option, it is always “yes or later” - I wouldn't mind so much if “later” meant “I know the option exists, I'll ask for it if I change my mind, don't bother me again otherwise”. Call me cynical, but if companies are trying to nag me into something I very much doubt the main benefit is mine. I'm sure there are many people out there who go along with it simply because they are sick of being asked repeatedly.
I also don't see the real benefit with the way things are often implemented anyway. When the credential recovery process is sending a magic email or text, making SMTP or SMS the weak link of the chain just as it often is for passwords so I'd be giving up my preferred workflows for no better security.
----
[1] A short while ago I actually ordered from somewhere else because of this, bitter twit that I am. “I wonder if I can get this almost certainly drop-shipped item on next day delivery via Prime?”, [goes to Amazon to check], [get passkey prompt], “sod it, I'll go back to the original place”.
I dropped Amazon entirely a couple years ago because they didn't provide any way at all to separate my credit card from my kid's Fire tablet and I didn't want to be on the hook for thousands in charges because he pushed the wrong button. It's remarkably easy! It has made basically no change to my life except that I'm a little smug about not using Amazon.
Target/Walmart/BestBuy. They both have fast shipping options as well as store pickup. Sometimes (if you live somewhere more rural) they have _faster_ shipping times than Amazon.
Walmart / Home Depot / Lowes / Kroger are generally going to beat Amazon on quickest delivery for most people for most items, if they want to, by virtue of their local brick and mortar footprint.
One reason I imagine Amazon pushed so hard for short delivery times was knowing eventually their legacy peers would leverage this against them.
Not to mention a long delivery time gives people more opportunity to simply go to the store and get something, while they’re out running other errands.
I live in a well populated suburban area. If I’m willing to actually leave my house, I can get most things much faster than Amazon can deliver them. This also helps keep those local businesses running, so shipping doesn’t become the only option in the future.
Shop.App doesn't have everything, but they do have a lot and many merchants have fast shipping options. I always try to search them and Newegg before trying Amazon.
Newegg marketplace is a funny place. Not only many items are more expensive than elsewhere, I had my orders delivered literally in Amazon or Walmart packaging. There are genuine merchants that made a choice to work with Newegg but there are many resellers from other stores as well.
I live in the country. Amazon takes days to ship out here, though sometimes it has 1-2 day. Walmart has same day shipping (not delivery, regular shipping) and is cheaper or comparable to Amazon.
but then how do you pay for things if/when you want to buy the little one something?
you either add the card then remove it, get a separate card, or find a way to use credits somehow -- but in the case of the latter two, Junior could still slam a few buttons and eat up all available funds on that card -- just without the impact of your regular card.
This is something that Apple really got right. My kids can initiate any kind of purchase they want (At least, those that are allowed based on Screen Time controls) but every purchase stops and waits for approval from me or my wife. Even if the item is free. No faffing about with credits, or extra cards, or setting limits.
Just use a bank with a decent service (like Revolut), create a separate card number for your kid (10s within the bank app), where you put more money when needed and can easily put the number on hold or activate it whenever you please.
> After the publication went live, Revolut reassured that the review is still ongoing. "We have so far still found no indications of any breach."
> "We have checked the user and card identifiers contained in the alleged records against our systems, and none of them correspond to valid or genuine Revolut identifiers," the spokesperson said.
The parent had a practical problem. I told him what kind of simple banking feature would easily solve it. I also mentioned a bank, which has it for sure.
For sure, this feature is not a Revolut-exclusive. Plata from Mexico should also have this and much more, from what I have read.
If American/European banks don't have such a simple feature, this speaks volumes about them.
Your comment has a vibe of "a bank that doesn't have a local office has no decent service". To each their own, I guess.
I mean, you can gift things when you purchase them, not sure why that can't be a way. But I still agree it's silly to have the customers find work arounds.
I think this is the biggest reason why these category of discussion happens in the first place, there is a gap between what technology is good for, whats its ideal for and then the products motivation to push it on to the user assuming it would give a good name to the company.
Passkeys are one of the few protocols that supports against phishing (Accidentally giving away your credential to some rough site) so it has its benefits and more so for enterprise users.
It becomes challenging and is ill suited when its pushed to general public. A middle ground could have been to give it as an option to user instead of forcing it on the user. For some reason its not cool enough.
From a company's perspective
- Authentication is a friction and the discoverable credential (where you just click on username button and log in) reduces the friction for user, making it easier for user to make that purchase decision
- Account take over attempts (ATOs) do take a dip, saves quite a lot of resources on customer support side for the company
Account recovery works the same with passkeys as with passwords. You click “I forgot/lost my passkey” and get a link sent you via email that lets you create a new one.
Passkeys can also be shared with other people like spouses or friends, just like passwords.
> Passkeys can also be shared with other people like spouses or friends, just like passwords.
How? They're literally designed to not be, because they're trying to prevent phishing, and you cannot in general case distinguish phishing from legitimate delegation of authority.
> Account recovery works the same with passkeys as with passwords … get a link sent you via email
Making the email account, an often attacked resource that is always online, a single point of failure. I don't mind relatively unimportant accounts being that weak, for instance where the only reason to have an account at all is to separate your preferences from someone else's, and you don't actually care about security, but for accounts where there is significant PII or payment details or other sensitive information it is a terrible idea.
A second problem with this is that for many their email account is the same as their account where their passkeys are backed up. What if you have lost your passkey due to Google locking you out for no readily apparent reason and you don't have the online influence needed to get them to take you seriously (instead being trapped in the support bot loop)?
I still run my own mail server, and if I didn't my important mail accounts wouldn't be with someone like Google (I do have a gmail address, but that account is only really used for testing other accounts when needed), so that isn't a problem for me, but most people can't be bothered with that faf¹ so usually end up with one of the big providers.
--------
[1] It isn't actually that much faf², until those occasions when it is³, but more faf than most people care for, especially those that don't enjoy tinkering with technical matters.
[2] Just quietly ticking over as long as I remember to regularly verify it is patched up-to-date, and keep an eye out for zero-day issues concerning the parts involved
[3] When there is a deliverability problem, where I host it has problems so I need to make sure the backup is synced and then switch over to it, when there is a relevant zero-day and I have to rush a patch in (or take other remedial action until a fix is available) then investigate to make sure I wasn't quietly affected, etc.
Oh right, I started to notice it too - couple non-tech people around me seem to treat "password reset" as default login flow, and definitely don't complain as much about auth flows as the rest.
I guess that's one effective way to cope with security industry bullshit.
And now you have to log into your email with a Passkey that probably you lost at the same time you lost your Passkey to the original site (e.g. lost or stolen device).
If you are not using Passkeys for your email (and the site supports that type of account recovery), then you still have only the security of passwords, just with additional steps.
Well, it puts people in a bind. The current status quo of TOTP 2FA with recovery codes is bad, but it's probably the best we have - because applying passkeys to your primary e-mail is beyond stupid at this point, it's putting your digital life in mortal peril.
I guess it really depends on how one choses to define general public, probably an assumption has been made that everyone has their own personal device.
> Built-in password managers are great for this. But they’re not universal (e.g. I believe using Apple Passwords on Mac doesn’t carry over to Android.
1.Only security keys (single device credentials) are what you can use across the device not the regular platform based one
2.Browser based password managers do provide you with that interoperability across the platforms and in fact the password manager as an supported passkey authenticator allows you do the same
Silicon Valley has no concept of consent and boundaries. If computing was a night club, "Silicon Valley" is the guy who goes up to every woman saying "Want to dance? [Yes or Maybe Later]?"
A better analogy would be slipping something into her drink whilst handing her a 12-page stapled terms of service agreement in which she unknowingly gives full consent.
Amazon and PayPal are horrible for this. Clicking out of the dialogs and modals to actually get logged in? (Shout out to PayPal for a dark pattern that implies "continue to login" but is actually "continue to set up PassKeys", and you actually need to "cancel" to actually login).
I think it is simpler than that: they ask irritatingly often, and I'm often looking quickly to see if I can get something on next-day delivery, so the two factors coincide.
Amazon does benefit from increased account security; they don't have to refund non-fraudulent orders after all. For most people, a passkey is genuinely more secure.
My MIL setup a passkey accidentally on her Google account and now has no idea where it is. Removing it now requires her password which she’s also forgotten. But now for some reason on Google I can’t initiate any type of forgot your password flow because of how Google sets up things and I have zero clue where she stored the passkey.
Ran into the same issue with my dad the other day. Has a passkey set up on his Google account. Bear in mind that he doesn’t know what a passkey is, so Google obviously sent him through a pattern at one point to get him to create one.
He didn’t have access to it the other day and we needed access to his account. He didn’t remember his password, and we were unable to reset it because you need the passkey! No other options to authenticate for a reset were available.
Add in the fact that I was trying to help him with this by long distance call and you can imagine the frustration.
As someone with elderly parents, the Googles and the Microsofts of the world really don't seem to give a shit about the elderly anymore, if they ever did. Random UI updates and workflow changes with no announcements, thinking they're "intuitive."
One of these days the product managers who push these things thinking "oh, it's easy, you just . . ." are either going to be explaining it to confused Mom or Dad, or they're going to be elderly and irritated themselves. Until then I hope they stub their toe or step on random Legos regularly.
I'm not even elderly but I would really like an e-mail client with a stable UI. I used to like Apple Mail but it's been a buggy mess since Catalina. It doesn't even sort or search mail reliably any more. It's basically a trope at this point but a robot-rewrite-in-Rust seems inevitable at this point.
A while ago I helped an elderly relative migrate off off a copy of Eudora that they'd been using for many years. (To Thunderbird.)
Originally it was about difficulty migrating to a new laptop with a different version of Windows, but I was quite firm about it because when I realized it wasn't able to do secure connections for some reason, so the instant they took their laptop to public Wi-Fi...
P.S.: Migrating decades of local messages was a huge problem. It's been so long that many import/export tools are defunct. I was even loading up extremely old versions of Thunderbird to see if I could import to that and then upgrade.
However the GitHub edition (not Sourceforge) of Eudora2Unix [0] saved me and deserves a shout-out here.
It took some tweaks and a harness to repeatedly try the conversion, since I wanted something I could literally drop into the Thunderbird profile folder. The final result wasn't perfect, (some file attachment issues linger) but it's way better than having it all at risk of Eudora.exe just refusing to launch one day.
>He didn’t remember his password, and we were unable to reset it because you need the passkey! No other options to authenticate for a reset were available.
AFAIK there's nothing different about the recovery scenario for a Google account in that state regardless of whether it has a password in use as its primary cred, a passkey in use as primary credential, or both.
Thanks. Upon further investigation we could have hit “Try another way” on the account recovery process UI a few times to get to a workable account recovery method.
Would be nice if Google would lay your recovery options out for you (which I am used to it doing in regard to 2FA if you are doing a regular log in) instead of having to hammer the “Try another way” link repeatedly as it cycles through options.
It does when I log in. You click "Try another way" and then it brings up a menu of options you have for 2FA. For some reason they have designed the account recovery flow to be different.
So, if you are used to the "Try another way" flow on login, it can be confusing to see an entirely different "Try another way" flow on account recovery.
Yubikeys generally have much worse recovery scenarios than passkeys do, for consumers. In enterprise if you lose your yubikey, an IT admin can help you get back into your account. If you lose a security key as a consumer, you're generally in a much tougher account recovery situation.
Not all services let you enroll multiple keys. Amazon, with all the money in the world, was guilty of this for a long time.
Practically, it is a huge challenge. I would want my day to day fob, an onsite backup, and an offsite backup. That’s a lot of hassle and potential for mistakes. To even register the offsite backup means I need access to it. Remotely copying a password database is so much reliable
It should be but haven’t checked her apple vault. I checked Google password manager and her windows password manager and there nothing in either. She might have used her phone and it’s in her iOS vault which I’ll check next. But this is what makes this entire passkey thing a mess. She’s 75, she didn’t do this on purpose and the ecosystem is just a mess
Also in the process of helping my dad with his phone, 76 and my grandmother 99. Maybe this works better with Apple, but the biggest problem on Android is, that it feels like every update shuffles everything around. Allmost no point in explaining, that they can solve some things on their own.
And all the time new things on the screen, new features they don't understand, need nor asked for.
Im young and I dont even bother learning how to use my Android phone's new features since it feels like everything moves or changes all the time. there's no point trying to get familiar with most of the features.
We're at a point where the biggest possible contribution to humanity of many PMs in big corps would be to just... drop dead. Feature-freeze rather than furthering the enshittification, as that seems all they're capable of.
I'd wish the world would just become boring again.
I just made one for PayPal using my MacBook which seems to have ended up in Bitwarden rather than the mac thing. But there's nothing in Bitwarden to say list all passkeys. Not sure how I check elsewhere. Maybe they should email you "you have created a paypal passkey in Tim's Bitwarden" or something. Then at least you could search the email for "passkey"?
I wonder if I can use Bitwarden on another device with that? I honestly don't know.
You can't search for passkeys, but you can search for logins by URL and check the much shorter list for passkeys. The good news is that having the passkey in Bitwarden means you can use it on another device.
Even the concept of "where on the PC" has been totally annihilated by OS vendors and app developers. Is it on the filesystem? Is it on The Cloud? Is it vaguely "In An App"? Is it in some "Secure Enclave"? Who the fuck knows anymore? And the apps are no help--they insist on blurring the lines between local and cloud, hiding full paths, and generally just saying "Don't worry about where your data actually is. We pinky swear to be able to find it for you!"
Windows prompting her about Bluetooth for the pass key threw me too. I thought for sure she had clicked the wrong thing before I realized that somehow her widows pass key requires communicating to some device? Maybe her phone? No idea
I know on my Windows if I sign into icloud.com I have the option of using a passkey which I do by scanning a picture with my iPhone and it also using Bluetooth, presumably to prove physical presence of it.
No, it doesn't have to be associated with the phone, and IMO you are better off not letting the big tech companies own your identity, which is effectively getting Apple or Google to store it in your phone for you ends up being. There are physical passkeys that feel like a door key in everyday use. You can attach them to your house key ring, and like house keys are near indestructible. Lookup the Yubikey 5 NFC.
The only downside is unlike a house key, you can't get a backup "cut". Copying a physical passkey currently isn't possible. If you lose it, you've lost access to all your logins. As the article says, their recommended workaround is to keep backup physical passkeys, and log all your passkeys (including the backups) into every site. Which is insane - very few people have the patience to do that.
The article is really a long rant about that one issue - there is currently no way to securely backup a physical passkey. Solve that, and all the other issues melt away.
I for sure don't. Websites only know there is a passkey associated with my account, and the OS only knows there might be one on the device, or maybe on another device, and offers me options to check here or do a Bluetooth/QR Code dance, and when all of them fail, I'm no closer to knowing where the damn passkey is.
I got a new cell phone and installed Microsoft Swiftkey and tried to login to Microsoft. It said my device's password or security manager would popup, but it never did and it never showed an option to login via password, just a mostly blank screen. I tried logging in from my laptop browser and it immediately tried using a passkey, but I've never created a passkey for Microsoft, so it errored out, still never showing an option for password login. I tried again and it errored out again and FINALLY showed the option to login via password. It had to fail 2 times to finally show the option for password login.
I was finally able to login via password, then had to go to Microsoft's passkey management page to create a new passkey, store it in 1password, and use that on my phone.
I'm a software engineer and it was annoying and time consuming and took a minute to figure out. How are non engineers supposed to even use this crap?
This is solved by passkey-implementing software and devices (with Bluetooth) allowing you to log in with a QR code (Webauthn via CTAP hybrid transport). iOS and Android support this, and it’s generally not a locked-down thing if other devices wanted to do it too.
The only use case left is in “how do I login if all my devices are stolen/fall into a body of water” in which there really isn’t an answer beyond “get (a|your) device back, sign back into your password manager, use that to get back into critical accounts”.
The website should display a qr code you can scan with your phone that allows you to then login, unfortunately a lot of sites don't implement this, and some don't implement backup codes. This isn't the fault of passkeys per se, but of poor implementations.
> The website should display a qr code you can scan with your phone that allows you to then login...
A malicious website can display a QR code too. I think this "feature" could cause some of the security issues that passkesys were intended to solve.
I use Keepass and the free tier of Dropbox, to keep my passwords strong and available across multiple devices. (Dropbox not required, you can store the database on a thumb drive.) Backups are no problem.
Keepass (or KeepassXC) stores other data as well, including the correct URLs for sites. So my workflow is simply to click the URL from within Keepass, copy the username and password, and paste them into the login screen. So easy even an adult can do it! (Humor attempt)
For convenience, Keepass database can be unlocked with either a password or biometrics (your fingerprint).
(Not affiliated with Keepass, just a happy longtime user.)
That QR code from a malicious website will not actually communicate with the malicious website with authentication from the correct origin, most QR code phishing scams do not actually use passkeys but rather fall back to trying to get the user's fallback login information (if any). By spec, if the domain does not perfectly match the domain where the passkey was originally created, the phone (or passkey provider) will fail to find a matching passkey. And the domain is derived, not provided by the QR code data (it's all in the spec).
Basically, it's very hard if not basically impossible to spoof a QR code to access the real passkey via a malicious site. (caveat, without already having compromised something like the user's DNS, maybe? Even then the site would likely fail the cryptographic checks.)
Yes, the passkey flow QR code contains a public key, and a local key exchange is done over bluetooth to prove proximity. That is used to set up a confidential channel.
That means attackers need more than to display a QR code, they also need a local presence (radio).
The phishing protections of passkeys also works against "malicious QR codes". Which is a great example of why passkeys are kind of good, you stop needing to worry about a lot of attacks.
Steam does this. If I want to login, it shows a barcode I can scan with the app and it logs me in without needing to enter my login information. Phone needs internet access, doesn't need to be on the same network as the device I'm logging in on.
I assume the QR code contains a token for the device, which is used by the app to authorize the login and the server automatically logs in the client on the device with the matching token.
Seems a lot safer to me than using my login credentials on a potentially unsafe device.
There's a whole set of fallbacks built in to the standard, including Bluetooth, local network connections, and going via a relay server. All of them eventually end up with your device signing something and handing that back to the browser on the other device to complete the authentication flow.
Is this why I keep getting notifications that such-and-such a website wants access to devices on my local network? I've been denying those left and right lately and didn't understand what on earth they needed access to that for.
Android 17? If yes, then that's because they added a new permission specifically to block apps from LAN access, then bundled it together with "nearby devices" (one introduced earlier specifically to block Bluetooth and WiFi scanning and point-to-point connections) because apparently they believe the concept of "local network" is too difficult for normies to understand or something - and due to how it's implemented, even apps trying to talk via loopback with themselves get captured in scope, too. The UI won't tell you which is which, though.
I cannot speak to how accurate your description is, but this description sounds like there are multiple weak points and multiple attack vectors that open this up to increased risk of compromise, undermining the very security stance it's supposed to provide.
The spec is quite thorough and well thought out in this regard. Despite what it "sounds like" when described, it is very secure, even with a variety of implementations. What is far weaker is that most sites that offer passkeys also offer a multitude of fallback recovery options.
AFAIK, the "scan this QR code" method of signing in with a passkey on a phone on a device w/o the passkey requires Bluetooth. There's some type of handshaking that goes on in order for you to prove you're in physical proximity of the device you are logging in on, to prevent phishing attacks.
Since I might have made someone mad... to clarify, as I understand it, Bluetooth is absolutely required for this "Scan the QR code" flow to work. However, it's also possible the actual authentication traffic to travel over a different pathway (wifi, cellular), but the bluetooth part is always required though to prove proximity. So on e.g. a library computer without Bluetooth enabled, you would not be able to log in with a passkey on your phone.
3. Communication (over websockets or a direct L2CAP channel)
The challenge is that a devices without bluetooth (at least today) don't have another common way to wirelessly judge proximity. A desktop/laptop without bluetooth likely either doesn't have NFC, or has bluetooth disabled by policy and would likely have cross-device passkeys disabled by policy as well.
If you're not happy connecting your phone to the network, then how likely is it that you would you be willing to enter your login details on a machine you don't control?
What if you just can't have internet on your phone? Like if the computer is connected via Ethernet and there's no wifi network you can connect to? What if you're abroad and have no roaming? And the ultimate question about a person that the modern world can barely conceptualize - what if you have a dumbphone? Or what if your smartphone is lost or stolen or dead and you need to access some account? That last one has happened to me, and I sure am glad I know the key passwords that I need for survival.
These may seem like nitpicks, but there's probably a thousand rare scenarios like these that exist. You inevitably have to consider them when you're moving from punching in letters and numbers that you remember in the normal, low-tech way to a complex networked two-device workflow.
I think there exists a vein of contempt for anyone not fully embracing our bold new world, so many implementers etc. get the double bonus of alienating and frustrating all of the non conformers
If my phone is lost or damaged, I would buy a new, cheap Android phone and sync my passkeys to it. But I am curious why one would need to login to a website in order to survive? If one did have say a severe medical condition that somehow required a website in order to manage, I guess I would concede that maybe passkeys aren't the best way to secure such a life-sustaining website.
> But I am curious why one would need to login to a website in order to survive?
They use bank like Ally or Discover with no physical branches.
They use a mortgage provider like Rocket mortgage with no physical branches.
They use a medication delivery service with no physical customer facing pharmacies.
They have an employer that only facilitates reimbursement for expenses via online tools.
etc...
I guess "survive" has a sliding scale, but if I lost access to critical accounts... my life is going to FUCKING SUCK in a non-trivial and very impactful way almost immediately, on many fronts.
And if your answer to that problem is "well, just call them"... then we're right back to the point the article is making: "An account’s security is still dictated by the weakest recovery method"
Passkeys aren't a meaningful improvement in security - assuming you do actually have decent password hygiene like a password manager.
If your phone is lost, how are you going to sync your passkeys to your new cheap android? In a passkey-only future, you cannot login to your Gmail account without your passkey, which is only on your phone, which you've now just lost.
What am I missing? Either we retain passwords as backup for a lost or stolen device - in which case, all the security concerns are still there - or we only use passkeys, in which case we've added a clear nonrecoverable point of failure in the system.
What confuses me is that for a long while we told people to not write their passwords on a sticky note, to not write them in plain text somewhere.
Then we introduce all these "security" mechanisms that make it literally impossible to recover an account without backup codes.
Where do you store the backup codes? The average person, if they store it at all, will store it on a plain text file or in a sticky note.
Except that this creates a much more brittle system. Systems are safe when they are routinely tested/used. If you routinely have to enter your password, you are aware you need it. If you don't need your password, and you never have to enter your backup codes, you won't feel the importance of them until you actually need them.
It's the whole "I have backups" vs. "the backups actually work" problem except it's pushed onto the users who have zero technical knowledge.
FWIW my break-the-glass actual use of backup codes is for access to my password manager.
Everything else which has ever given me a backup code... gets stored in a secure note in my password manager.
It is just another knowledge-based factor. It is one that they are reasonably sure you aren't spreading around the internet. It is one that the site gets to pick rather than the user. But in reality, they are a often just a way to try to reduce some support and identity verification costs.
The path to get to the password manager is the case where the backup codes truly matter, because without them there may not be a way for support to restore access. Those codes may be your only way of regaining the master encryption key.
But that also winds up being part of the trade-off of security vs user friendliness. Some password managers are way easier to get back into.
Doesn't being able to sync your passkeys by entering your conventional password somewhere eliminate the whole point of passkeys? It just shifts the point where you can enter the password to recover your data to a less convenient place. And if your entire stack is passkey-protected (which I'm pretty sure is the case most of the time) then the secondary phone won't do anything for you.
When I said "survival", I meant it in the "being able to make do with few resources in a time of crisis" way, not that you will literally die if you can't access an account. Losing a crucial device without a fallback of being able to log in somewhere else quickly can mean immediately losing access to payments (the most crippling, especially if you're not home), being stranded in an airport or even not having an identity document (in countries with digital ID systems). Any of these happening can lead to enormous losses in time, money or worse, depending on when and where this event hits you.
What? Did you read the thread? I never said passkeys can only exist on phones. The whole conversation is about "how do I log on with passkeys if something happens to my trusted device?". The parent comments talked about just using your phone, I'm saying there's lots of situations where someone might not have access to either a phone or an internet connection for it. And when this happens, you really don't want to be left without a way to access all vital digital services.
> I'm saying there's lots of situations where someone might not have access to either a phone or an internet connection for it. And when this happens, you really don't want to be left without a way to access all vital digital services.
And when that happens I'm usually glad my credential is a passkey on my keyring, as chances are if I don't have my phone and I haven't auth'd on to some computer I almost certainly don't have access to my password vault. But hey, my passkey works just fine without my phone. And I can trust that once I unplug my authenticator and log out of that session, there's no long lasting credentials left behind. I don't get that with passwords.
Wouldn't I have the same problem with passwords? I would lose my phone and be unable to two factor log in to my Gmail account or bank from someone else's device?
With 2FA? Yes. 2FA is almost just as stupid and almost just as bad for regular users as passkeys are, but it got adopted due to historical loophole - by far the most popular form was TOTP delivered via SMS, then "authenticator" apps, both of which keep the code transferable - you can receive it on one device, transfer to yourself or someone else (which is a feature, not a bug) via any channel, and get it to work. Passkeys were created specifically to close that loophole.
Plus, SMS didn't allow for vendor lock-in, which is arguably why they're so hated in security circles (SIM-jacking is real, but doesn't scale anywhere near enough to warrant deprecating it as mechanism for regular users).
I have over 2,000 accounts. The majority of them have unique passwords. I can count the services that have passwords that I know on one hand, with quite a few spare fingers.
Passwords just don't provide a broad recoverability benefit once you commit to doing strong, unique passwords.
> Passkeys were created specifically to close that loophole.
Credential sharing? I have a family share with passwords and passkeys in it. Passkeys most certainly didn't stop this.
They did add friction to having a user being duped to share their password to someone claiming to be tech support, since you can no longer request plaintext secrets be sent over arbitrary channels.
> Plus, SMS didn't allow for vendor lock-in, which is arguably why they're so hated in security circles (SIM-jacking is real, but doesn't scale anywhere near enough to warrant deprecating it as mechanism for regular users).
SMS is an ugly user experience and more importantly is expensive. Now a lot of services do emailed codes when they don't have a regulatory reason to require SMS - an even worse user experience, but less expensive.
We have authenticator apps which use a standard OATH setup, and quite a few platforms which have integrated support to try to sand over the worst part of the UX. Unfortunately they just didn't become popular, and OATH fails the same regulatory requirements that emailed codes fail.
Passkeys are not meant to have a vendor lock-in story. Credential exchange allows for credentials stored in consumer credential managers to be imported into another credential managers. The platforms have added infrastructure specifically to make this easier for users.
The exceptions are when enterprises run their own passkey stores, or when the user explicitly picks a solution that doesn't allow export (like a physical Yubikey).
No, it's fine. Most common example, I log in to my bank, they send an SMS, I copy the code and paste it into the web site. Works fine and I don't have to pick up my stupid phone, like I would if I used an authenticator app instead.
"and more importantly is expensive."
Not for me. The bank made several billion dollars last quarter, don't think it's a big problem for them, either.
Most common example, I log in to my bank, they say they sent an SMS, I sit there waiting to access my account, then 20 minutes later the SMS finally actually gets delivered after I've given up and left to do something else. Rinse/repeat.
Or another example, someone hijacks my SMS'es, and then they log in as me.
SMS sucks. SMS is insecure.
The amount of times I've experienced customers complaining about SMS 2FA not working well despite it being on their carrier failing to deliver the messages in a timely fashion really showed me how terrible it is.
Dunno what to tell you. Several possible points of failure there. Maybe your bank's system for sending SMS just sucks. Maybe you're in a place with poor mobile network coverage (which is a real problem for SMS 2FA, I agree, having lived in a place with nearly none for several years).
But for me, where I live now, with my bank, and my phone carrier, it works great. Never had a problem that I can think of. Typically, the SMS arrives within seconds. It's the least annoying and most reliable 2FA method I use.
I'm not that worried about potential security issues. Sure, it's a possible problem, but pretty low on the list of things to worry about.
But the problem is that you can't really backup passkeys and because people are frankly frequent tricked into using them, they have no good recovery options.
I know plenty of people who only have a phone, no other devices. They don't backup that phone, they should but they don't. They don't use a password manager either, maybe they should, but they don't.
My issue with passkeys are that they are designed for a reality that don't exist, or at least only exists for people who are already doing a lot to secure their devices.
> But the problem is that you can't really backup passkeys
The individual passkey? Maybe not. But I don't really need to backup the passkey, I can just have backup passkeys or other backup authenticators, including complicated stored one-time passwords.
To answer your earlier hypothetical, I'm out traveling and I'm mugged. Well, hopefully, I'm not mugged in the part of the travels where I'm carrying truly everything at the moment, and I can just go back to the hotel room and re-auth with a device I saved there Problem solved, no big deal. If I lost truly everything while I'm out, I'd do as suggested elsewhere here and call home to get a trusted friend/family member to read me off the one time password saved at home or whatever, or figure out some way to get me money to get home. Chances are I'll end up having to work with the embassy anyway.
> My issue with passkeys are that they are designed for a reality that don't exist
The reality of passwords being hijacked is absolutely a reality of today and is a constant issue for tons of people.
> I know plenty of people who only have a phone, no other devices.
And I really don't get why we can't also teach these people to also have a little token they use that can also be a part of their online identity. And sure, for certain kinds of accounts have appropriate levels of recoverability, but for the normal authentication workflows its so much better in so many ways.
>They are designed for a wealthy technologically inclined user with a very stable lifestyle and trusted resources and connections to other people. You know, the exact people who developed them.
And here you go posting
> I'd do as suggested elsewhere here and call home to get a trusted friend/family member to read me off the one time password saved at home or whateve
If you read what I posted you see why you live at a particular place of privileged and are seemingly incapable of putting yourself in another persons position where these things do not hold true.
"If you are a white male earning over 100,000 a year in a stable relationship with living family members, excess savings in the bank, in a stable first world country everything is going to be fine and the rest of you can get fucked" --what you keep repeating in different ways.
I mean I was pointing out that you were being racist and sexist from a position of privilege without realizing you were doing so. A kind of systematic failure caused by not realizing our choices as developers has real world impacts on the less privileged.
You're being racist and sexist by assuming wealthy westerners or those in stable relationships or those being able to call home to family are white males. If that's not racist I don't know what is. I don't think it takes being a white male to be able to call home to family when traveling internationally. You're assuming a point of view is invalid due to someone's race and gender.
Quit being racist and projecting identities on people.
This is about people who would have a hard time recovering digital identities. I imagine there were lots of white males fleeing war in Europe who probably struggled to get access to accounts backed with things like passkeys and other forms of 2FA. But I guess to you their struggles don't matter.
Its almost like you including gender and race was just your own projections of your own hatred for a particular group. You should probably think about things when painting people with such a wide brush of "white males" when trying to paint people in a derogatory fashion.
I spent a chunk of my life homeless. Don't project some identity on me that's not valid, or that I just totally lack some perspective due to your assumption of my race or gender. Its not a fair thing to do, its literally racist and sexist.
You could have tried to make your point without throwing in racist and sexist comments by just saying "wealthy western software developers" or whatever.
They are designed for a wealthy technologically inclined user with a very stable lifestyle and trusted resources and connections to other people. You know, the exact people who developed them.
Do you have a plan for getting home without access to any of your accounts? And one of the problems with passkeys is that it's unreasonably difficult to keep a backup key.
You're asking way too much foresight in this thread I guess. There are some people who have lived lives without any series of unfortunate events, they can't even imagine what the world can serve up.
If nearby (some country) any credit card or even my ID card will get me home. I can walk into a branch of my bank and - with some waiting and paper work - I should be able to get enough cash to get myself home.
Abroad I’d head to the nearest consulate of my home country. Might be difficult to get to if it’s in a far away city. Hard to prepare for abstractly.
Great, now I just need to get back home to use my uncompromised accounts (which would have still been protected by my device as long as the thieves aren't NSO Group, but whatever). Gee, it seems my tickets back home were taken with my stolen phone! Not to worry, they sent me an email confirmation, so all I need to do is log into my passkey-protected email on my friend's phone and have them download my ticket in addition to theirs, or print them at a public computer. Oh wait
As long as you still have your passport, which you’d need for international travel anyway, you can get your boarding pass at the airport without any hassle.
They still exist, though. And in my experience people in vulnerable positions have somewhere between zero and one phones at any given time, without necessarily any good continuity between them.
Only if they’re a bit old. Nowadays WiFi chips double as Bluetooth chips on newer platforms.
That's a technocratic reply, not one that is useful in the real world.
As noted by the person you're replying to, it's not his computer. It's a public library.
Most computers in non-residential settings will have various features locked down, including Bluetooth.
Hotels, clubs, airport lounges, various government facilities… there are thousands of places where you might really need to use a computer but don't control the technology.
> > What if the computer you want to log in on doesn't have Bluetooth?
> Only if they’re a bit old. Nowadays WiFi chips double as Bluetooth chips on newer platforms.
What if the computer you want to log in on doesn't have a WiFi chip?
It doesn't have to be an old computer; for instance, the desktop computer I built last year uses a wired gigabit Ethernet connection to the router right next to it, and doesn't have (or need) any WiFi or Bluetooth chip.
>This is solved by passkey-implementing software and devices (with Bluetooth) allowing you to log in with a QR code (Webauthn via CTAP hybrid transport).
Ok but how do I share my Netflix or Spotify accounts for example with those?
The same way you share them now: sharing the account name and password and doing whatever you currently do to deal with any 2FA they occasionally toss in.
If they also allow passkeys as an alternative form of login that doesn't need 2FA you can use those to make the account sharing more secure.
When setting up sharing with someone first change the password to something else, and then share the account name and password. After they log in the can add a passkey to the account on their device or devices.
Then you can change the password back to your real password. When they want to use the account they login with their passkey.
If the service doesn't accept login passkeys but does allows passkeys for 2FA, you have to use real password sharing, but at least they can have a passkey for 2FA which may be easier than how you know handle 2FA.
How do people handle 2FA with account sharing? If the site uses TOTP you can give them the QR code that you received back when you made the account (you do save a screenshot of such QR codes for backup, right?).
But how do you handle SMS 2FA, which seems to be far more commonly offered than TOTP?
For email 2FA I suppose you could set up a filter on your incoming mail that forwards any incoming code emails to the people you shared with, and hope that the time limit on the code is long enough for this to work.
In general you shouldn’t - Netflix[0] really should get proper invite-based family sharing, and Spotify’s subscriber agreement has a section that defines Premium as a “Single-user Paid Subscription” and thus can’t be used by multiple people, legally (and you might be at risk of getting banned if they detect it)
However, passkeys can and are available to be shared via password managers. They’re not locked to the secure chip on the device where they live usually. iOS’ Passwords app has a share button and 1Password lets you share passkey-containing items.
In fact, the QR code login feature makes it even easier to do a one-time sign in to your account for a friend, if you don’t want them to be able to login to your account indefinitely.
0: Netflix doesn’t support passkeys because their main audience is people signing in via smart TVs and whatnot, which largely don’t support CTAP or Webauthn in general)
Me: Invents more new ways of being problematic for the company spreading the ideas to millions of others decreasing their profitability to almost nothing.
Me to company: Damn, guess you shouldn't have been an asshole about it, kind of backfired on you.
The responsible product owners will already have bounced 18 months prior after tweaking the stats to falsify the customer satisfaction rate and grabbing their bonus on the way out.
2FA is lowkey designed to reduce paid account sharing. It's always those services that are so eager to get people 2FA'd. Microsoft Minecraft account is the hardest thing to log into, and they even perma locked tons of people out.
TOTP is unfamiliar or hard to use for most people, so they use SMS. Most sites don't support TOTP either.
Even if you use TOTP, it's not designed to be shared, for example look up what hoops you need to jump through to export a single TOTP code in Google Authenticator. And they used to not even have that option; they told you to set up multiple TOTP codes on each website instead. Even on 1password I had to look up a tutorial on how to import a TOTP code cause the menu is in a very non-obvious and deep spot.
In the same vein as 2fa, going up to a fresh computer and trying to log into anything is now a nightmare. Every service has a 2fa that somehow loops into another provider that also has 2fa.
And some 2fa, if not many, make accounts weaker. Apple's solution to get around 2fa is to put in SOMEBODY ELSES phone number that I trust, as a backdoor. It's an insane solution. And its normalized, and nobody questions it.
Yeah, many do not even allow you to enter in a custom question, which would be marginally better--at least for users who care about security.
Then you'd have the option to craft a question which is (A) personally memorable (B) specifically phrased to avoid ambiguity, (C) not public or guessable, and (D) unique to a service.
* "Where is your first pet buried?"
* "While on vacation, The Noodle Incident happened in which city?"
* In what year did you first see Example Band live in concert along with Alice and Bob?"
Sign in with a QR code is dangerous though because at that point theres very little stopping QR phishing and forwarding the bluetooth request to your browser. See the most common Discord scam.
> forwarding the bluetooth request to your browser.
This isn't a thing. Discord's QR Code scanning is entirely a feature they made unrelated to passkeys or bluetooth. Passkey auth using a QR code has a step that verifies the proximity of both devices using BLE.
They're cheap enough if you lose one it's not the end of the world. Goes on your keyring. Doesn't require esim management. Use NFC swipe/usb-plug-in + pin to use.
The problem with hardware tokens is that they 1) Only store a limited number of logins, 2) It is very difficult to keep them in sync- every time you need to add a passkey, you have to get them both out, which makes it difficult to keep one a in a secure safe to keep it safe from damage/loss
This two fatal flaws are what limits their usefulness to enterprise SSO and perhaps some other limited uses where the organization has the ability to replace tokens. (Even in a distributed enterprise, enterprise SSO may not be a good fit for hardware tokens, if they can't get replacements out to employees fast enough).
> the problem with hardware tokens is that they 1) Only store a limited number of logins,
1) It's one passkey used over and over, so it only takes 1 slot.
> 2) It is very difficult to keep them in sync- every time you need to add a passkey, you have to get them both out, which makes it difficult to keep one a in a secure safe to keep it safe from damage/loss
2) With SSO used across enterprise exactly like you're talking about, works fine without having to reregister over and over. Been using this and have implemented it myself for years.
3) much cheaper than a phone with a much cheaper recovery path
4) no path is a free lunch, you're always going to be making compromises somewhere, it's the nature of security - it is adversarial
Yes, this is the issue. People don't like how adversarial security people act, and how they force things onto people. It's fine if a corporation wants to have some internal policy since they're the ones eating the cost if an employee can't work or whatever. Less so if individuals are forced into these wonky setups for no benefit. e.g. now I have to run and maintain and backup a Vaultwarden server just to log into my HSA, which is absurd (I also have to keep an old version of the bitwarden extension around and use that because the latest requires TLS, which is another piece of infrastructure that I don't want). My password manager already generated random site-specific passwords. And for some unknown reason, browsers didn't start with the obvious step of software passkey support in password managers, and then allow hardware keys for the nerds that want that.
Oh, right, because it's actually a lock-in play, and it's designed to be unusable unless you tie your entire life to Google or Apple's cloud platform.
Copy pasting my other comment from an earlier thread
FIDO2 USB Security key -> Bitwarden (With master password) -> Every other method (topt/password)
I have 3 FIDO2 USB Security keys, One I carry with my persons at all times, one that stays with my main machine at all times and an offsite backup that is sitting in a friend's server, if my house burns down, I can either physically collect the key or use USB-IP to authenticate back into bitwarden and enroll a new key. (Actually all 3 are at home right now but that's ok)
How is that different from accidentally deleting your keepass database? Or forgetting your password? I think it’d be easier for me to forget than find myself trying to flush all my hw tokens…
I can back up my FIDO2 (non-)resident keys too. In the end it's just a piece of HW with some secret material inside. non-resident FIDO2 keys are easier to back up, because the master secret seed is fixed and shared for all origins and there's nothing stored on the key.
Same way. A majority generally have a old phone that was already signed in to google. Or if they remember only Apple ID and password (one very difficult password) + sms. They can login on to a new phone.
Everything is SYNCED immediately.
What if you have a ransomeware that destroy everything on the same day your house and all backups burn down. And you cant get it from immutable backups as you wrote that decryption key in paper. And the bank will not allow you to access it as the govt deported you elsewhere.
I can get another hw key (if one of mine breaks, which I, surprisingly enough, have not yet managed to achieve)
And since I have at least two at all times, the possibility of one of them breaking changes… not much really.
Paper can burn or get tossed, backups files can go corrupt, and I really don't understand what is that extra risk hw keys introduce…
There is at least one valid (in my opinion) reason to not like hw keys though: they cost real money to acquire, so you probably want an extra margin in your budget for the unlikely case they indeed decide to break.
> Also... Is flushing your whole keys down the toilet a problem you run into often?
It's a potential catastrophe I'd like to avoid if possible, but the catastrophe is not inherent to any other key I have.
House key: Make new copy for 10 USD. Alternatively, get a locksmith to unlock the door and change the lock. Even more alternatively, break a window or door. I still get into my house.
Car key: Make a new copy for >10 USD. Alternatively, call roadside assistance and get them to tow me somewhere I can get a new key. More inconvenient, still very possible.
TOTP 2FA and passwords: Password databases can be backed up, and so can TOTP seeds. It's inconvenient to do so, but I can at least still just leave copies around everywhere I can, so that it's extremely unlikely that I'll be completely locked out.
Yubikey: Making copies is literally impossible, so I'll need to buy two or three keys from the get go, and get them all out every time I need to add a new key. This is a huge inconvenience that no casual user will ever do (they might do 3-2-1 if it was set-and-forget, but Yubikeys aren't). If I don't do this, I lose permanent access to my accounts. There is no safety valve built in to the system. If I lose my key, I'm fucked.
My point is if you just flushed your keychain, maybe some terrible accident while drunk at a pub, you should still have at least 1 more hardware key somewhere else. And by the way, your phone is also a viable key. Having a passkey on your phone and a physical one on your person solves most issues, with the rest being covered by having 1 or more in a safe or other secured storage location.
I recommend a reciprocating saw with a metal cutting blade to get them into small enough pieces. Do not try to flush them all of the pieces at the same time. It's not just about whether they fit or not, they also need to be light enough for the water current of the flush to carry them all the way through. Otherwise, they may end up in the water trap and hinder your future use of the appliance. For small partial blockages, it may be possible to consume some extra fiber in order to be able to "sweep" some of the metallic remnants along, but this will void both your warranty and your bowels.
I am a doctor -- and a lawyer and an orbital mechanics specialist, as well as a highly respected behavioral therapist -- so you can trust my advice. Also, feel free to consult an AI on this topic; it would make for an amusing benchmark.
But a majority don't do that. For them let them use passkeys. If the possibility is once in 10 years then I am happy to do that. A majority is happy to do that.
And yes, Google or Apple - dont say you should not keep passwords in your database and sync it with dropbox. DIY.
This is a legitimate problem, and one of the few cases where a third party login provider makes sense, at least for non-critical “apps”. If both tokens can be authorized to that provider, then you don’t need to enroll any more tokens for apps using that provider. The difficulty is creating a trustworthy provider system without weakening security (the provider shouldn’t be able to login without you) that doesn’t collect information about you and which can’t lock you out from all your accounts.
I’m not sure what work has been done on this since Mozilla Persona. I certainly wouldn’t want Google and Apple, or governments, to be the sole gatekeepers.
Why would you choose that over a synchronizing passkey manager?
A third party OAuth provider puts you at the mercy of the service provider, the other can work fully on your client side even if the app provider were to disappear tomorrow.
The only advantage I can think of is that you have a centralized place to revoke credentials in case your password manager does get compromised.
> Why would you choose that over a synchronizing passkey manager?
No second factor, compromised passkey manager leads to compromise of all accounts. This is a huge problem.
> A third party OAuth provider puts you at the mercy of the service provider, the other can work fully on your client side even if the app provider were to disappear tomorrow.
Yes that’s what I was saying, it needs some thought and careful work. It would need to be decentralized, and I’m not sure that current standards are up to the task.
"A third party OAuth provider puts you at the mercy of the service provider" This is they key issue with trusting a third party to manage my passkeys, they can also BLOCK them and lock me out. An exception is if the passkeys are synced to all your devices and cannot be remotely wiped. I think this is how Apple works.
I didn’t think of this in the moment, but you’re right, this is an even bigger risk than compromise. There’s regularly a thread here about someone getting locked out of their cloud accounts, and now we’re going to gate everything behind those same accounts? Horrible idea.
Sad reality is that such usecase is less and less common, thus, no one cares about it. I think majority of my friends would not be able to access their email, or facebook or alike, if they were forced to use my computer in emergency.
And that sounds fine, until you're traveling and your devices get stolen or lost. How, exactly, are you going to get into your email then, once passkeys become the only means of login? Because that moment is when you really do need to access your email, stat.
What services implement it like this? Don't services usually implement passkeys as a more secure alternative to a password, but password login is still available?
Some sites allow passkeys as an option for MFA, so that could be an issue if the passkey is your only MFA option and MFA is required. But I imagine email would pretty much always be a fallback.
Didn't Outlook.com famously rolled out passkeys with no recovery option and no option to sign in using username and password once enrolled. So if you lost your trusted device, you couldn't sign in, nor could Microsoft send you an email, because... Outlook.com is your email provider.
And not even that, now that I think about it. I have my very long Bitwarden password memorized but if my devices are all stolen I won't be able to get passed the 2-factor, so I'd still be screwed.
Isn't there a workflow where you scan a QR code to confirm the pass key on your phone?
I've definitely done this, but not sure if the workflow was at the OS or browser level.
I'm honestly confused by all the negativity in the comments. Passkeys are great for convenience. Just leave your password login enabled as a backup. That defeats any security benefit, but oh well.
There are a lot of reasons why I might want to login on a computer I don't own to do something, rather than to use my phone. Having a keyboard is a major usability benefit for many types of work. Larger screen, printer. Software that is on the machine that can't run on my phone.
I agree with you; those are all reasons I only use my phone for on-the-go messaging or navigation. I'm against the idea that you should have to have a secure (against the owner) connected phone on your person at all times in order to sign in to a web service.
This is what I use to log into our remote desktop software at work. The passkey is on my phone and I scan a QR code presented by the remote desktop software (in this case it's the Windows App on my macbook and Microsoft Authenticator on my android).
Which is a trade-off that makes sense for a lot of people. If you have multiple devices, many of which are portable and one you have on you all the time, the need for that is just way lower, so being more secure against commonplace automated widespread attacks is worth it to them.
Many people are moving to only a single portable device that’s easily lost, broken, or stolen, without any understanding of backups or fallbacks for their accounts.
And many are moving to virtual wallets like Cashapp rather than banks with a physical presence where you can take out money without a phone.
A variant of that is alternative accounts that properly live on a different device/context.
For instance YouTubers usually have a different account for their channel than the one they use privately, and don't want their channel account logged in everywhere.
That means having to log in as a guest when push comes to shove. And similar setups are common for most self-employed keeping a "work" account IMHO.
That's actually a good use case for HW keys. Since untrusted computers are much more likely to have keyloggers/malware, etc. So you don't need to reset password and invalidate all sessions after each such login on an untrusted computer.
The offer a strong protection against phishing attacks that would still get plenty of password manager users: fake websites. A passkey is strongly linked to a domain, so a fake site can't get that credential.
Some password managers will only fill if a domain matches, but IRL the response I've seen from most users when it doesn't match is to assume the integration broke and manually copy/paste it in. I've also seen lots of them do stuff like happily autofill on any prefix of the domain, so your credential for `something.example.com` will autofill into `fake-something.example.com`.
"Oh, usually my bank just logs me in, that's strange. Let me just go grab my username and password and type it into this site that looks like my bank."
Same thing is going to happen with passkeys for non-technical users for exactly the same reason you stated. People will think the integration is busted and manually copy/paste the non-passkey credentials in. In that way, I would argue that passkey is not stronger protection against phishing attacks unless its the only way to login. It is, at best, a convenience for users.
If the user just has a username/password fallback and that's it, then yes, but the aim of passkeys is that won't be the norm, rather users will only have passkeys and the fallback would be to, e.g: magic link email log in where the phishing attack is still broken. I've seen some sites explicitly disallow plain username/password login after you enable passkeys for this reason (you can still put them in, but then it just does a magic link flow afterwards as a second factor).
I've been told by multiple people that the recovery method of passkeys is to enter your username/password. If passwords are eliminated, your final recourse is fucked.
Why would it be that is the only recovery method? The most convenient one is just more passkeys on other devices of course, but you can have any other recovery methods you want. Magic link emails are the most common, but there is nothing about passkeys stopping you from implementing anything you want.
Which is a laudible goal, but something that makes "oh just fall back to the standard insecure recovery process" not a very good response to the concerns about users being able to actually hold on to their passkeys easily and reliably.
> but IRL the response I've seen from most users when it doesn't match is to assume the integration broke and manually copy/paste it in.
I've seen people do this AFK as well, and I'm always helpfully suggesting them the correct way of solving this: verifying the URL again, and if correct, add it to the password manager so it remembers in the future, and never copy-paste passwords on the web. Basically 50/50 if they take the advice or come back after a week asking if it's safe to copy-paste the password into the website, and I try to inform again.
Shockingly, I saw one developer peer copy-pasting a password into a website, but I guess for these people there is no hope.
It should be a big red flag for sure, but the reality is most users aren't going to understand that. They got told to use a password manager by someone or find it convenient, but they don't understand the security flow enough to catch that it's a potential attack, or how to resolve it safely.
Historically I've seen lots of sites do a subdomain shuffle for login pages every now and then which routinely breaks domain matching, introducing false positives that users have to deal with, making them numb to the threat too. Passkeys baking in the domain check with no workaround means that sites can't do that, which is a benefit.
My password manager's browser integration breaks on every update of Firefox, which seems like it is a weekly affair. I got rid of the extension, and copy/paste everything.
Password managers were never meant to solve the problem of phishing, and aren't really capable of that. They solved the problem of password reuse. They do that just fine.
There are too many websites where this is broken for me (even with Firefox's built-in password fill) to go as far as to never copy-paste passwords. If web devs actually implemented it consistently, I might be that draconian about it, but asking them to do that when we already have the '200 MB of JS is needed to view this page' problem, I have my doubts we're going to see this problem going away any time soon.
Probably the whole authentication thing shouldn't be implemented by the website at all. There should be some standardized way to ask for authentication that's implemented by the browser or the operating system.
Your last sentence got me good, as I'm a developer who copy-pastes passwords into websites (from a 12? year old KeePass database, for whatever that's worth).
I've tried using the Firefox integration in the past - more than once - and I don't know... it had so many warts that I got fed up with it and turned it off. And now I have 1Password (from work) also doing its best to feed me credentials all the time. So trying the KeePass integration again is going to have them both drawing suggestion dropdowns all the time..
But ok, I'll give it another honest shot. Because of your comment.
> Some password managers will only fill if a domain matches, but IRL the response I've seen from most users when it doesn't match is to assume the integration broke and manually copy/paste it in. I've also seen lots of them do stuff like happily autofill on any prefix of the domain, so your credential for `something.example.com` will autofill into `fake-something.example.com`.
Why would you trust the very same password managers that don't handle passwords properly to handle passkeys properly?
You don't. The browser handles the passkey matching to the domain which is obviously a better place to do it. There could obviously still be bugs as with all things, but it's much more intentionally integrated into the flow which makes it much harder to bypass.
Right, I haven't seen that particular flaw in baked-into-the-browser ones (probably because they already having secure domain matching code ready to use), but the distinction is that doing the domain check is a part of the spec and standard, so e.g: sites aren't going to break it by changing the log-in subdomain routinely, as has been common historically.
Password managers have had to be permissive enough to work with most websites, and there is no standard for it. There have been sites that blocked the autofilling of passwords and so on as well.
My point wasn't this one particular flaw in some password managers is the reason to use passkeys (the copy/paste point is the much bigger issue anyway), just that it's an example of how relatively brittle the password manager process is. Having it a core part of the spec gives stronger guarantees.
“There have been sites that blocked the autofilling of passwords and so on as well.”
Sites that do this irritate me so much. Ones that try to block pasting and stuff… like somebody intentionally baked that into the site. Who? And what was their rationale? Are they really so arrogant to think people are going to carefully type in some elaborate password not once but twice?
That and blocking paste in fields like bank account numbers and stuff.
Surely somebody here has been asked to implement these mis-features. Please explain what went through the heads of the people responsible for it?
Blocking bank account numbers from being pasted is considered an error prevention measure. By forcing people to enter it manually at least once, you stop them from blindly pasting the wrong number twice.
There's no real regulation requiring blocking paste but it has become an annoying informal standard of sorts.
The users are the ones manually copy/pasting the password. There's no way the password manager could prevent this short of disallowing copying/viewing passwords.
> But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.
This is meant to be solved by the cross-device flow - a QR code pops up that you scan, and a secure channel is established from that with your other device.
[Disclosure: an editor of said standard]
> The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for.
On macOS/iOS, the system gives this prompt regardless of where your passkeys are being created/stored:
Save a passkey?
"<site>" supports passkeys, a stronger alternative to passwords that cannot be leaked or stolen. A passkey for "<username>" will be saved in "<provider>".
There is a transparent upgrade option though that sites can request - basically when a site supports passwords and passkeys, they can request a password manager supporting both create and return a new passkey on password sign-in.
> [...] and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
That's unfortunate. A site/service should absolutely not replace other passkeys, nor should it remove other sign-in options like passwords, without explicit user consent.
The above credential upgrade flow makes that doubly so; even if someone relies on a password manager to manage and provide their credentials for a site, it very well may not be the singular piece of software that does so.
> This is meant to be solved by the cross-device flow - a QR code pops up that you scan, and a secure channel is established from that with your other device.
That only works if the device has working camera and bluetooth. What if I want to log in from my new desktop PC to an account whose Passkey is stored on my old desktop PC?
If passkeys were implemented properly, the would be most useful to relatively technical users that already use password managers. Ideally, the only real change is that a single text password is replaced with multiple non-text "passwords" that cannot be entered on the wrong website by accident.
The problem is exactly that they're being forced on nontechnical users when the UX isn't even good enough yet to sell them to technical users.
I'm just storing my passkeys in 1password, which means they're synced across my two computers and phone and also means I gave up any kind of hardware security.
> I've accidentally set up passkeys just by clicking an okay button a few times in the past and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
No doubt there exist services that do not offer recovery method for passkey or mfa enabled account. But this is entirely on them (the service), to blame for, not the passkeys or the users. It’s bad implementation.
Sony Playstation will only let you setup a passkey if you disable password auth.
But I have not found any way to use my browser's passkey to login on my PS5. I can scan a QR code, but that requires logging into the mobile app with a passkey. And I can't add one to my mobile phone because I can't login on mobile... the passkey is on my laptop, and it won't autofill from 1Password (Android).
> Passkeys do marginally improve security against MITM and phishing attacks ...
The tragedy of passkeys is that they're a step back from the security offered by the likes of Yubikeys.
But because passkeys are pushed by both Google, Microsoft and Apple: there is is simply no fighting these three. It is impossible.
Passkeys won not because they're better (they're not and the entire concept of "secret behind a hardware security module" that can be transferred to another system defeats the whole point of a HSM in the first place) but because the powers-that-be decided that passkeys are to be used.
It's still a win: the commoners are better served with passkeys.
But a secret in control of Google/Apple/Microsoft that can be backed up is not a secret I control: it's a complete step back from yubikeys.
Passkeys won and we better get used to them (and, yup, there are usability issues as you mentioned).
As an IT manager weak and/or re-used passwords are an absolute scourge. Ideally every time you set a passkey you'd also add an OTP Authenticator factor as fallback. Passkeys are incredibly useful and relatively secure when pair with biometric authorization (touch/face ID). I agree with a lot of the points about consumer level use, but still think they're net positive compared with bad password (re)use. I'd advocate for email recover as a decent fallback, but there's only so much you can do when the average user won't establish a base line of security for their primary account and access point.
Security is frustrating and it's hard to get people to do the bare minimum to establish secure access to their services.
> how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.
I agree with you 100%, although I will say that it seems like newer OSes (perhaps it depends on the desktop + mobile combination, or maybe Chrome + Android is enough, not sure) have a way for you to use a passkey from your phone by scanning a QR code. I still think it's not super user-friendly but it is a clever workaround at least. Most people are accustomed to scanning QR codes, so scanning a QR code from your phone to sign in seems like not too big of a leap. (Although I wonder if it conditions users to scan random QR codes to sign in which could be a bigger phishing problem lol...).
This. My simple brain is always like...."This passkey is going to be lost and only usable on this machine and I don't even trust that to work consistently because I do weird stuff sometimes"
> But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own?
at least in Apple land, if you try to sign on on a device that you don’t own (let’s say a work laptop where you’re not signed in to your apple id) it’ll give you a QR code to scan with your iPhone and it’ll do faceID on your iphone then do some bluetooth handshake to use your passkey on the other device. I’m not sure if this is Apple exclusive or if android/windows/linux would be able to do the same
I’m a big dummy who commented before reading the article, this is actually called out there
> The last option is to use “Hybrid Transport”, where you scan a QR code and connect via Bluetooth simultaneously to the computer. Whilst this option is secure and works in theory, reality is plagued with edge-cases where connections fail or Bluetooth is straight-up unsupported.
I haven't articulated my thoughts about passkeys nearly as eloquently, but you did an amazing job here. This really sums up a latent problem I've had with passkeys.
I have a passkey on CVS, but that YubiKey was eaten by the sewer.
Thankfully I can still log-in with a password & text. But how to reset the passkey? No-one knows.
Edit: I take that back, for some reason they stopped taking the password I used when setting up the account. It's only email or SMS with code verification + birth-date.
In the Apple ecosystem this is trivial - you select to sign in using a QR code which you scan with a device you do own. It works perfectly in my experience (of using them wherever possible for several years)
The point about poor support for 3rd party managers is so frustrating. Because this is correct, that is the obvious solution for the normal user, but passkey implementations somehow do not know how to deal with it.
Amazon prompts me to create a passkey everytime I log in, even when I logged in with a passkey, because my passkeys live in Bitwarden rather than my OS or browser.
And the confusing mechanism hurts there too: I'm always a little bit afraid that i'm somehow more in danger because I keep them in a vault that's shared on all my devices rather than a TPM, because whenever the protocol is explained the "it can't leave your device" part is highlighted as the main source of the security, except.... mine obviously do leave my device, with the vault, so.....
Yet, the Apple + Google implementations will sync passkeys between your devices. "Securely", of course. (I've seen first hand how Apple implements this, and it seems.... sound)
Sites can request hardware-bound tokens, which would block any software based password managers. It's an option in the protocol but one not yet widely utilized.
FIDO authenticator attestation is dead for consumer-facing RPs. Apple made the right call and simply refuses to support it outside of MDM environments.
The entire value proposition, and the reason big sites are pushing them, is they take the user out of the loop of authentication. You are no longer authenticating the user, you're authenticating the users device.
For websites you don't have to worry about cookie theft and dealing with the support load of users needing their accounts reset or dealing with fraud. You can also do some level of attestation to hardware which makes automated account creation more difficult.
For the user it offers no additional benefits. You still have something secret that gets presented to a website to login. Password managers solved this problem. But now for some reason you can't log in when you buy a new laptop.
It is playing nice to criticize things. It's not just "different priorities", passkeys have intentional trade offs which cause them to be "more secure" but in ways that users do not want because it negatively affects them. The intentional trade off made in the name of "more security" makes them wildly inconvenient and risks causing massive lockout. Like removing all the staircases from people's homes and replacing them with climbing walls all in the name of "security". You can't just diffuse that by say "well we want banks to be more secure, we have different priorities."
I am already seeing my "normie" friends getting locked out of accounts due to not understanding passkeys. If they don't have their phone, or it's dead, or it breaks, or is stolen, they just can't access their account anymore. They have no idea how they work or what they're trading off, nor do they understand that they should have prepared for this scenario ahead of time somehow. Upon telling them "yeah you have to use your phone now that you have a passkey" they all universally say "wtf, that's stupid, I never want to have that happen again, I will never use a passkey again."
Passkeys should never have been built for general audiences, they are a huge mistake, I hope they cease to be relevant and die due to everyday folks realizing they're inconvenient and the "more secure" gains ain't worth it for the usability nightmares.
"I am already seeing my "normie" friends getting locked out of accounts due to not understanding passkeys."
In a weird way this is good news for us. If people are losing passkeys, getting locked out, and incurring non-trivial support costs as a result to the relevant companies, then there's no way those companies will crank down even harder by requiring hardware keys.
As an option, I don't mind it existing for situations like a work environment. Work environments are so much easier because there is a clear line to get my credentials reset, from scratch if necessary, even if I lose everything. The problem is that the consumer authentication case is even harder because it lacks that clear line without also creating a backdoor.
So I insist on centralizing my passkeys into a password manager. I have no passkeys outside of my password manager and will continue to reject them. If it's important enough to slap authentication on, it's important enough for me to not lose it because I couldn't choose where to stick it, which is in a basket that I protect very, very carefully.
Honestly I just don't see how something like Amazon could ever turn on the "require hardware key" feature without blowing their own foot off, or really any consumer-facing service. Everyone loses keys. To a first approximation nobody is going to buy three keys and correctly manage setting up all of them to work with every service. Even if we magically stipulate that all sites support it and they all have some integrated unified approach so that there's no software-side friction at all to register all three at once everywhere, you just get too many people who stuck all three keys on one keychain, people whose houses burned down, people who so successfully stored both backups "securely" that they have no memory of where they are anymore or how to get them back, an endless parade of lost keys. The consumer as a whole is not capable of managing hardware keys.
Given how often my household loses its second car keys for extended periods of time I am not exempting myself from this. My work key lives a much simpler life... it just sits in one place, doing work things. My family would hardly last a month if everyone had to carry around physical keys to log in to things.
Why should I recognize that as valid interest, when it's straight out hostile to me? I know why they are doing that. It doesn't oblige me to accommodate their selfish interests.
I'd absolutely never trust Google to manage passwords/passkeys for me, with their habit of irrevocably auto-banning accounts. Apple seems... better? But that's today. That could change, and then you'd be screwed.
You're not limited to a single passkey by the spec or 99% of sites that support them. The limit is arbitrary and typically when a limit exists it's no fewer than 3 (very rarely 1, but I've only seen that once that I can recall).
I generally add three, one for Bitwarden (my actual password manager), and then the OS passkey store (Android/Chrome password manager or iOS/Apple Passwords depending on the device).
I'm not qualified to say yes or no; but I will say that Apple's tends to make design decisions that try to empower the user as much as they can while still being easy to use, and have more or less maintained that position.where as Google, on the other hand, started as "open" and "you can do it all on our platform" to "we're taking away your control and choice little by little, in order to 'protect' you". Oh, and you hear more about Google perma-banning your account for no clear reasons, than Apple...
> Amazon prompts me to create a passkey everytime I log in, even when I logged in with a passkey, because my passkeys live in Bitwarden rather than my OS or browser.
What setup are you using? Because I don't have that problem on Linux + Firefox at all
Linux, Mac, and Windows (i happen to use all three regularly for work, hobbies, gaming), Firefox + Bitwarden.
It's totally possible there's something specific about my situation, or the way it was set up in the first place that enables this, idk, but somebody else replied saying they have the same experience so it's not just me.
And even if it was just me, it's still clearly something wrong on the provider's implementation, because it should not be possible for software to sidetrack the user into a passkey enrollment flow, when that user logged in with a passkey to open the current session.
I will take a wild guess (based on that you are using firefox) is that you probably have enabled the various don't save cookies, clear sessions on close or other hardened privacy settings that are the source of 99% of problems firefox users encounter, like increased cloudflare captchas .
Could be! I don't recall turning things like those on, I use firefox for features not privacy, and mostly leave stuff like that at their defaults, which I trust Mozilla + uBlock to filter the invasive trackers while leaving actually useful functionality, but it's possible I fiddled with it years ago and forgot.
Some probably kinda strong counterevidence to that though is that this doesn't happen on all sites, only Amazon. I've never been prompted to make a new passkey after passkey login on the 12 other sites that I have passkeys in bitwarden for.
Very strange! Whatever the bug is, I hope Amazon fixes it.
It's quite crazy to just surprise a user with a passkey in any event, even if they get saved and don't reprompt you. Suddenly spawning an OS popup without any explanation, which may or may not try to ask for biometrics, is crazy.
> Amazon prompts me to create a passkey everytime I log in, even when I logged in with a passkey, because my passkeys live in Bitwarden rather than my OS or browser.
I haaaaaate this. And every time I'm like, "do I not already have one??" Passkey implementation has been half-assed by everyone.
I don't have any issues using Bitwarden as the default password manager on any of my devices, except the occasional Android/Google issue with apps where it opens the Chrome passkey store and doesn't prompt for Bitwarden.
But websites pretty much universally trigger the Bitwarden passkey prompt, or I can bypass via the popup and go to the OS passkey manager.
> Amazon prompts me to create a passkey everytime I log in, even when I logged in with a passkey, because my passkeys live in Bitwarden rather than my OS or browser.
I use 1Password and Amazon does not prompt me like that. However I do have two passkeys for Amazon, one in 1Password and one in Apple Passwords. There's not enough data yet to say if it happens to you because of something not working right between Bitwarden and Amazon, or something about Amazon doesn't work right if you don't have a passkey in your OS passkey store.
Might be worth adding a passkey for Amazon to your OS passkey store and see if the problem goes away. If it does, blame Amazon. If it does not, report it as a possible bug in Bitwarden (altough it still could be an Amazon bug that just happens to mess with Bitwarden but not 1Password).
While the technology itself may be great (I don't really know since I don't use them) it has been co-opted by the tech conglomerates as another form of isolating and walling off users into their ecosystems.
And honestly, nowadays, if tech companies are pushing really hard for something then that is an immediate red flag for me and it bears more scrutiny. One of those "if you see them running that way you run the opposite way".
but what do passkeys offer in terms of security, when stored in password managers, compared to having a (password manager) generated password and a totp?
I believe that by allowing password managers to store passkeys, the whole purpose of "device based security" got lost..
They are 100% immune to credentials phishing. You literally cannot authenticate to an impersonator site based on cryptographic guarantees.
And yes, I know the happy path of password managers uses host-based autofill which does add some friction to phishing attempts, but given the prevalence of unexpected but legitimate urls with weird alternate subdomains/SSO/redirects in modern login flows, you have to manually autofill/add an exception often enough that it's possible to let your guard down once at the wrong time.
Yes. I use hardware based passkeys and absolutely love them. I think it was a giant mistake having them 'software' based. It some ways it kind of defeats the entire purpose...
Physical keys can easily be copied, and physical locks can easily be picked. That might be fine for your house or storage unit, but for your bank account or your car (newer cars no longer have simple physical keys/locks), we've moved beyond that tech.
That any and all physical security measures can be defeated is a feature, not a bug. Almost no human beings actually need that level of security, and the tradeoffs are absolutely not worth it for those of us without Mossad as a threat.
How often do people lock themselves out of their own house? Don't you know anyone with ADHD? Imagine any time that happens it is mathematically verifiably permanent as a fact of reality itself. It doesn't matter that the state still views you as the legal owner, you are never allowed in ever again.
Now we aren't talking about a security problem, we're talking about who really owns what. Google can lock you out of your account no matter what kind of authentication they use for that account
I'm not even sure what your point is anymore. If Google decides they don't want you to log in anymore, you can't log in anymore. It doesn't matter if you try to log in with a passkey, a password, your fingerprint, or sending a secret code in with carrier pidgeon. This has nothing to do with passkeys vs passwords vs anything else.
If Google does want you to be able to log in then they will work with you to make that happen, whether you forgot your password, lost your passkey, or your carrier pidgeon died.
Passkeys are not special in this regard at all. What does make them special is that nobody can use a phishing attack to steal your passkey and log in to your account. Nobody can guess your passkey and log into your account. Nobody can intercept your passkey in flight and log in as you. That's the important distinction.
That's not the problem for me - I carry a bunch of tokens with me anyway (all my banking stuff is on hardware tokens, for example). My problem is more: My browsers run in containers or VMs, intentionally without hardware access. Getting passkeys to work there would be quite a bit of effort.
My yubikeys have survived dips in the ocean, spilled beers, run over by cars, dropped in pans of used motor oil, left out in thunderstorms, and multiple trips through the washer and dryer. They're still fine even after a decade.
Passwords can move between walled gardens generally very easily (export) or manually in all cases (enter by hand).
Passkeys only very recently got relatively broad support for migrating data (after years of promise and no support at all), and they report (optionally with hardware attestation) what password manager you're using so sites can force specific ones.
I did a deep dive on this since progressively more places are taking a hard line about Passkeys.
The most flexible, independence preserving thing to do is to use a third party password manager like Bitwarden, and make that the default passkey flow for your devices. If desired, you can self-host something like Vaultwarden so that you can both keep the keys independent of third parties and walled gardens and also propagate them to other client devices.
To be clear I'd much rather not have learned / implemented any of this, and I don't use passkeys unless forced, but this seems like a valid coping strategy.
Not as far as I’m aware? They of course require the target app to be compatible with the way they export them, but I don’t think they vet them manually. At the very least, on my phone, the apps it agrees to export to include Chrome and Bitwarden (the latter of which lets me export them further).
> And honestly, nowadays, if tech companies are pushing really hard for something then that is an immediate red flag for me and it bears more scrutiny.
The reason is the ever increasing number of hijacks of social media presences and code hosting portals, with the latter being a serious financial threat. Done right, passkeys stay in the Secure Enclave, at least for anything Apple and most of the Android sphere. There is no reasonable way to obtain login credentials for accounts protected by passkeys without physical access to the user's device(s).
The doubt is more "how will tech companies use passkeys as an excuse to do something stupid" than "passkeys themselves must have inherent problems because tech companies are pushing them".
Passkeys could be the savior of all security problems worldwide from a capability point of view and tech companies would still ruin it by trying to force ways it pushes you into their ecosystem instead of just being whats both secure and convenient.
As an example, I have 3 different passkey _APPS_ on my phone and cannot go down to one because of various reasons with each (such as MS authenticator, forced for integrating to Microsoft at work).
Fun fact: Google can decide to reject these. Lose access to the original device, try to rely on recovery codes to login with known current password on family member’s device… nope!
I guarantee you this is within the realm of possibility based on one single experience.
When you upgrade your phone perhaps keep your old one in a safe and charge it and login to Gmail monthly or something?
I’m also quite certain the codes could work instantly with no trouble in some circumstances. Now know it’s risky though. And I’m sure it’s a security measure based on real, deeply painful and costly instances of unauthorized access. Just don’t know what we’re exactly supposed to do…
Google gives you no guarantee of service for your account. They could arbitrarily decide to lock you out for any reason and you have literally no recourse.
Very solid points, and I love the focus on the fact that passkeys are addressing threats irrelevant to regular people, while ignoring those that matter. But I think it's still incomplete, because it's missing the biggest blind spot in design:
Password sharing is a feature, not a bug.
Security industry failed to implement the most basic feature one does with access control at individual level, which is delegation of authority. Physical security in form of "bearer" devices, such as keys, credit/debit cards, transit tickets (except those newfangled ones bound to photo ID), etc. all support this by default.
Ad-hoc delegation of authority is a normal thing to do, something we do all the time without thinking. Asking your kid or friend to do groceries for you? You hand them your debit card and give the PIN. Need a nanny to walk your kid from school and stay with them until you're back? You make them a copy of your house keys.
This carried over naturally to technology realm. A colleague needs to get some data that happens to exist only on your machine, while you're away? In normal non-corporate places, you just write the password on a post-it and give it to them, or put it in a drawer and tell them to go look there.
Security industry failed to provide a reasonable alternative path for over four decades now, and instead continues to deny the very existence of the need for ad-hoc delegation of authority. Passkeys are a bad choice for regular users largely because they're designed to prevent delegation - on top of the other issue, that the author correctly recognized, which is that by far the biggest threat to regular user is that of loss of access to account.
On a system I'm designing, you can provide a 2nd (or 3rd, 4th) password, which affords an user of said username/password combination a subset of the permissions _you_ have, which stops working after a date.
This has made multiple product owners cry. I am wondering if it would make sense to add a 2ndary action prompting the user at the eol for this secondary credential asking them if it went fine, to try and collect some information on how popular the feature is.
That's nice and I applaud you for attempting to solve it in a user-friendly way.
Sadly, because that'll come off as unusual to 99%+ of your userbase, you'll probably face challenges explaining this to the users, and it'll skew statistics you gather here. Chicken and egg problem, really :(.
Not really that much in comparison to losing access when needed. It's relevant to corporate employees, where phishing is worthwhile to attackers, while losing access means creating a ticket on internal helpdesk and having rest of the day off.
corporate employees are typically regular people, and where phishing resistance is most valuable.
if by regular people, you meant "in someone's personal life", i would say phishing resistance is still relevant but agree that loss of access becomes a bigger risk to balance
Don’t you remember the giant phishing campaigns like back when lots of celebrities got their nudes in iCloud stolen and published? These things happen all the time, and are incredibly painful. Much, much more so than being unable to share your account with a coworker.
I don't get the sense that regular people get data "stolen".
Ransom is the only thing I see happening to end user data.
Credential thefts facilitate theft of money. It might might help the attacker to rifle thru somebody's data to find information that helps answer "secret" questions, to trick friend and family into getting phished, and maybe blackmail, but I don't see a market for end user data that would drive data theft. Nobody is buying end user photos, videos, email, etc. (Anybody who would possibly buy it just tricks/entices users into giving it to them for free to train their AI models anyway.)
LLMs ironically are changing this[0], but at least until now, rifling through random people's data did not scale, so aside for a subset of cases where it was possible to automate access to some services or otherwise leverage them into a scam on the cheap, it wasn't of interest because there was literally nothing useful to do with it.
--
[0] - LLMs, whether multimodal or combined with modern AI-driven STT / TTS pipeline, enable running highly personalized scams cheaply and in an automated fashion, which does scale up and suddenly makes this data important. But that's a very new consideration, one which passkeys were not designed for, because it literally was not possible or conceivable even few years ago.
At the scale you'd expect that to happen, looking at credential dumps, you'd also expect to hear a lot about it.
And yet, you don't. Which leads me to the conclusion that the data dump are overblown.
I think companies around the world come to the same obvious conclusion, which is why these data breaches keep happening, and the companies whose systems were breached are never any worse for the wear.
All true, but there's a wrinkle with delegating auth in computer systems--the same wrinkle that comes up when thinking about digital data as property/copyrightable etc.: when you delegate auth, you copy the access; you don't loan it. So every digital delegated-auth scenario is like your "make a copy of your house keys" example, not your "loan out your debit card" example.
If we extend the metaphor, this would be like making a copy of your keys and handing those out every time someone other than you needed access to your house. Dinner guest? Key copy. Neighbor dropping off a borrowed tool? Key copy. Relative from out of town visiting? Key copy.
In the same way that I think most homeowners would look askance at passing out so many copies of their keys, delegated digital auth is troublesome. Nontechnical users are unlikely to pay attention to "what clients are using delegated credentials for which actions" dashboards. Revocation, while technically easy, isn't something that I think most casual users will be mindful of, resulting in endless growth in the list of principals with access to a resource (just like the "sharing passwords" scenario we have now). Time-based auto-revocation will be an annoyance for delegates who only need to access a resource rarely, resulting in exasperated administrators rubber-stamping new-delegate-credentials requests.
I don't know if there's a good solve here. Shared passwords might be the local maximum of convenience and security, but that feels pretty bad.
You can add multiple passkeys in the vast majority of websites that support them. There's nothing in the spec that prevents or discourages allowing multiple credentials. I do it on every site I care about so I can fallback to the OS passkey store if I lost access to my Bitwarden account for whatever reason.
Passkeys have been a massive quality-of-life improvement. Yes, there's the minimal risk of lockout if you lose access to the passkey (though almost every site I've used that implements pk's lays it on top of their traditional user/pass auth flow), but generally speaking most people use iCloud or their Google account to store their passkeys, and because those sync everywhere, this isn't a real risk.
I love not needing to deal with 1Password's autofill being flakey and having to CMD-C/CMD-V passwords/passphrases/OTPs on these sites.
I like Yubikeys as well but they are super inconvenient by comparison when dealing with multiple devices. Setting them up is also very user-unfriendly in general; doubly so compared to passkeys.
Now, what I'd REALLY F'IN LOVE to see go away is the passwordless/magic link auth flow wherein you authenticate by clicking a magic link that gets sent to your email or text message inbox.
"Emails are super easy to hack and we're still not sure whether text messages are safe to send on US carriers, so let's have everyone click on a link sent by email or text so that they don't have to deal with those pesky passwords that iOS or Android will automatically suggest for them." Like, what?
A family member installed an app into their Android phone from the Play Store.
It was innocent enough until it asked for a truckload of permissions, like being able to change the launcher, which they ofc tapped "Allow" to since permission request fatigue is real and still a bit of an unsolved problem.
So the app delivered on its promise and changed their phone's launcher. It had a fake Gmail widget that showed them their mail but, of course, wasn't actually tied to the actual Gmail app and was an easy way of getting a refresh token for their account.
Bingo bango bongo: their email was now at risk.
They changed their password after I told them to right away upon them asking me to look at their phone because "it was slow."
> Magic link auth isn't any less secure than any site that has a password-reset flow.
Which is exactly the problem. Cloning someone's SIM/eSIM and immediately performing password resets is a well-known security issue.
Yeah I don't trust SMS either, that's why I said email. You can do a lot more to protect your email account than your phone number.
It's very disconcerting to think about how many malicious apps like that must exist in the Play Store, but again, gaining access to someone's Google account is still game over if that's how you're syncing passkeys.
> what I'd REALLY F'IN LOVE to see go away is the passwordless/magic link auth flow
This seems really naive? That's the only flow that's at the basis if you get locked out. What else, do you put people on the phone to verify people by asking their name and date of birth? That's even worse!
I think they're referring to sites where that is the only way to sign in, which I have seen a few of. Basically you can never register a password or passkey, every sign in requires going to your email and waiting for the link to arrive.
I get the idea. If email links are secure enough to use for password resets, just do that every time. Then you eliminate a whole category of password attacks.
But it’s definitely annoying for a frequently used service.
Maybe this gets us closer to some idea of email being a more protected digital service, that has some legal guarantees?
Putting the potential negatives under the rug for a second…
I would be nice to have email that (1) you can’t get locked out of arbitrarily, (2) acts similarly to US mailbox (in its protections and universal service), (3) acts as an identity
Only if it's run by the state and free for every citizen. Forcing more bureaucracy on email providers will just make everything more centralized under Google and Microsoft.
It should be a mailbox with E2E encryption where the keys are stored on your ID card. Backups stay on secure servers that are legally protected from anyone including the police and only given out when you're getting a new ID at a government service center, encrypted with the cards public key so a hacker in the card issuing system can't steal it.
Every user gets a persistent address used as their identity, and any number of anonymous ones. Locking someone out would be both illegal and inconvenient for the government if all their official business is going through the mailbox.
Horrible idea. This will require every email vendor to certify with every country they provide service to that wants to do something like this, which will pretty much kill any small/indie email hosting providers.
I'd much rather have stricter legislation around password resets built into existing reg frameworks like PCI or HIPAA. If you store a form of payment or PII with a provider, then some form of human verification should be needed to perform a password reset.
I get more annoyed by the timeout it adds. Logging in 10 years ago? A thing of seconds.
Logging in today? Either magic links through mail (delivered to you within the next 30min thanks to graylisting or spam filters) or a login flow with requires 5 dialogs and 5 confirmation of "no, just log me in".
I think all Shopify sites also do it now? I'm migrating password managers and have been going over all of the old accounts I've had. Several sites that use Shopify for their stores now just don't accept any kind of a password.
I despise that too. One website (was it walmart?) gives me option to use that or a password, I select password and after entering it it tells me that it needs to verify my e-mail "for security" where I get link or code to log in.
At that point what's the point of password? Just an optional extra step?
For services that have your PII or payments details, yeah, that should be the only way to do a reset. Super inconvenient but much less so than dealing with stolen identity or credit cards.
Yes, at this point I have probably saved literal hours in time added up by being able to skip MFA prompts on sites/apps I use regularly via a passkey login flow. It was becoming ridiculous how often I'd hit a "verify who you are with your phone/email" gate even on services I use constantly, a gigantic waste of time.
> Yes, there's the minimal risk of lockout if you lose access to the passkey (though almost every site I've used that implements pk's lays it on top of their traditional user/pass auth flow)
Exactly, if you lose your passkey you just sign in with your password like you did previously. I'm yet to find an app/website that has passkeys only and no passwords.
Just spitballing here, but it seems like a good mix of phishing resistance & lockout recovery would be to have passkey-only auth, but with email recovery.
So no password login, but then you can recover your account by adding an additional passkey by receiving an email.
Kind of, but I have some of my most important passwords and account recovery codes duplicated on paper in a secure place. If there was ever a service that only allowed passkey login (do those exist?), you can't print those out.
I wouldn't be okay with that. Say you're setting up a new iPhone with a new iCloud account because you forgot the password to your old one. (Unlikely scenario amongst us nerds, but very very likely outside of our bubble.)
If you want to log into, say, Google, but the passkey flow is the only way in, then you're almost-completely SOL unless you have some way of getting the passkey out of your iCloud keychain and into the keychain of the phone you're setting up.
If you still have your old phone, you can scan the QR code and get in that way. If you don't, then you're completely SOL.
Ignoring any supposed security benefits, personally I use it because it's much more convenient/ faster than logging in with a password since.
You're still slightly less likely to get phished if you only ever login with passkey and only use the password in case of lost passkey. Of course you could get phished that one time but entering your password once (maybe never) has got to be better than entering it daily.
I don't have any passkey accounts where I didn't start off with a password and after adding a passkey the password login method was always retained. What services are people using where you don't need to set a password?
> I love not needing to deal with 1Password's autofill being flakey and having to CMD-C/CMD-V passwords/passphrases/OTPs on these sites.
But that requires that website implement support for passkeys, and is that easier than just implementing a login form that doesn’t break password managers’ autofill?
Low risk of lockout, but about as high-severity as one can imagine. Yes in theory sites should offer a password fallback, but how many actually do? And of those that attempt it, how many get it right?
Not even Google reliably lets you fall back to a password, according to the comments in this article. Losing access to your google is anywhere from major inconvenience to professional disaster.
Expecting every user (site using passkeys) to implement complicated flows is a time-tested recipe for disaster, and it's a bummer to see that unfolding yet again with passkeys.
>Not even Google reliably lets you fall back to a password, according to the comments in this article.
I logged in with my google password (on my TV, the other method using my phone wasn't working for some reason) the other day even though I normally use a passkey from my phone or computer. It worked just fine.
Sometimes it works, sometimes it doesn't. I've had Google block my login because it was sus (it was a new computer or something...) and they wanted to verify a whole bunch of information. If you haven't given them that info, you just get locked out.
To the day where your device breaks, you had set a passkey to access your Google account (because the phone did prompted it up and you did not understand and clicked yes), you did not setup a recovery method (such as another email/SMS) or you did setup a recovery method that still depends on the Google passkey access (e.g. a second email account where you sign in with Google or has Google as a two factor verification!) and you are locked out of your Google account. Good luck at that point contacting Google assistance, you may as well consider that account as lost forever since there is no way to talk with an human being.
And unfortunately is something I start to see to family members/friends that are not tech experts when they ask me to setup them up a new phone... at least the passwords they would have written them in some notebook that they had at home, or always used the same for everything, but with passkey... and when you tell them that they lost access to their email, possibly the files backed up to Google Drive/Google Photos, etc they are surely not happy.
Also passkeys makes it difficult to get access to your account in an emergency scenario, what if I loose my phone and I'm not signed in to other devices? Maybe I've setup an SMS as a recovery method, but first I have to get to my phone company to request another SIM card, maybe I'm on vacation on the other side of the earth in vacation for 2 weeks, I'm locked out of my Google account, and from all accounts that uses the passkey as a sign-in method (including, for example, the account that I need to use to check in on my return flight, or my banking app that I need to pay stuff!)
Partner's mom lost phone. Partner called me with mom's password. I went to Find Hub. Entered email and password. "Hold on, we're sending the lost phone a verification text."
> those sync everywhere, this isn't a real risk
I hope your main account at one of these two providers gets banned for whatever reason so you'll never utter such frivolous claims ever after :)
I'm in the same spot. It seems like every month a post pops up here that's "I hate passkeys" and most of HN seems to agree.
I use 1Password, but passkeys have made things even easier. I'd rather have them than any 2FA method. So many websites make me use a login/password AND then send me an email or text with a code. Every. Single. Time. You're really telling me you would rather do that than have a passkey?!
And, like you said, passwordless email auth is really terrible.
I try to boycott passkeys due to built-in attestation feature in the standard. Not active now, but given how Google+Apple already use the passkey feature to lock you into their ecosystems, it is just a matter of time until their service will require that the passkey is attested from a non-rooted Google or Apple device. I think this will especially be true for Google to prevent AI scraping bots. Turning this on does not require anything, once passkeys are widely used, Apple, Google and Co. simply can flip a switch.
> Not active now, but given how Google+Apple already use the passkey feature to lock you into their ecosystems, it is just a matter of time until their service will require that the passkey is attested from a non-rooted Google or Apple device.
I'm with you 100%.
There will be evil and stupid uses.
The brain-damaged people who think disabling paste on password fields is a security feature will be all over forcing device-attested passkeys as soon as they learn about it.
Evil people will see it as a proxy attestation of humanity.
Either way it will be rammed down our throats if passkeys are widely adopted.
I imagine that's why they're pushing them so hard, especially given Google's recent anti-user lockdowns. I have a hard time imagining they'd expend so many resources to protect a tiny percentage of users from having their accounts hacked...there's no way they actually give a shit about that. Their bread and butter is instead protecting the value of their product, which is their captive userbase.
Apple and Google don't need the passkey spec to mandate that you only use their services from non rooted Google/ Apple devices. They could do it before passkeys existed, and they can do that right now if they wanted to.
What's any of that got to do with passkeys and attestation?
I continue to avoid passkeys but it's becoming an incredibly dense minefield. Certain sites try to trick me into adding one each time I log in and I have to be careful to dismiss the 1Password prompt, then dismiss the chrome prompt, then dismiss the OS-level prompt (all back-to-back). It's so incredibly user-hostile.
The worst offender for me is the Costco mobile app. It's handy because it allows you to enter the store by scanning the QR code it displays on start up. However it also nags you to create a passkey. You can dismiss this by saying that you want to keep using a password. But then it nags you again next time. This behavior is problematic because the delay between opening the app and the "create a passkey" splash dialog (which hides the QR code) is exactly the time it takes to pull the phone out, open the app and present the screen under the reader at the door. Every single time I need to look back at the phone screen to see why it didn't scan, dismiss the passkey nag, bring up the QR code again, scan.
Wow, we live in completely different worlds. I don't remember seeing a single passkey prompt. I basically only login from my Linux desktop using Firefox, do I assume my software stack just doesn't support them?
They try to make it feel that way, but you can. Just keep pressing escape/cancel, then it shows an errorish screen but from there it lets you continue without one
Three of those four prompts are opt-in and configurable and aren’t the site’s fault, no? I disable the browser and OS password managers because I use 1Password… why do you have the Chrome and OS password managers enabled if you’re using 1Password? Or if there’s some reason you need them all available, at least rather than dismissing the prompts, why not add an entry to disabling prompting for a specific site in the 2 managers you don’t want to see again? All three support that.
On my phone I don’t see any way to disable the system passkey option. I have only 1Password toggled on in my settings but I still see the system prompt to save a passkey. It’s maddening. I’ll have to double check on desktop but I thought I had toggled off everything but 1Password.
Perhaps I missed something or perhaps it really is that user hostile. It wouldn’t surprise me in the slightest.
If any of them are configurable, I'm not smart enough to figure out how. I looked again, and I'm still not seeing anything. Even if it's my fault I'm seeing these, I still resent them.
Where do you have so many sites asking for passkeys? I’m desperately trying to have more but I have ~1.1k passwords in my password manager and only 63 passkeys!
It's the banks/Amazon/etc-type places that keep prompting me, coupled with random one-off websites here and there. When I upgrade my phone in a month or so I'm dreading the deluge of passkey requests I'll run into and having to deny it multiple times per initial login.
My annoyance with the prompts is not evenly spread over the sites I use, it just so happens the same sites that think short login periods = security (it does not) are also the same sites that think passkeys are the best thing since sliced bread.
I have such a low opinion of any company that logs me out every time I turn around and those are the same disrespectful companies that think it's appropriate to spam me with passkey requests when I login. My dislike also extends to those companies they have a "Remember me" or "Remember this choice" checkbox that is decorative, as in it doesn't do anything. Often paired with clicking external links in things like a banking website "Warning: You are leaving this site!", yeah, I know how the internet works, I don't need to be babied by a completely ineffectual dialog (if you think normies are reading that and not just clicking through, you are living in a fantasy world).
Interesting. For the GAFAM yeah, I got those. But for banks, in my country at least, I’m not sure they are even allowed to use passkeys. Instead we have a glorious numerical keypad where we have to manually click on the keys and the keys are never at the same place. I’d love to have passkeys instead…
YES. This exactly. I work across multiple devices, some of which are nonstandard/uncommon (Linux, Xiaomi China ROM, ...) and I've NEVER had passkeys work properly - yet everything constantly prompts me to add one. Even if they did work, I'd have to carry around hardware keys or register each computer separately. And the lack of backups if a device is lost/broken is definitely a larger concern for me than being phished of my TOTP keys.
My wife clicked through a Google dialog and suddenly was using a passkey. It absolutely happens, though IMO more to the non technical users. I know what those login dialogs and pop ups mean, and decline them.
(At least til I get around to setting up my new usb c yubikeys!)
Same as traditional physical keys, you don't have a single key, you have multiple ones precisely so that if you lose/break one, you are not stuck and can go to the local locksmith and get another one in minutes.
In fact it's even nicer since you can just re-use the backup key with no security loss by revoking the other one, and buying another key.
> Same as traditional physical keys, you don't have a single key, you have multiple ones [...]
I have multiple identical ones.
> [...] and can go to the local locksmith and get another one in minutes.
Can I go to the digital equivalent of a locksmith (like a backup software) and duplicate my passkey? Can I do that with only my passkey in hand (without having to do anything to the corresponding lock, or having to contact its issuer), like I recently did with a physical key?
Heh, in the security world, this shows how your traditional metal key is "something you know" (like a password) because it can be copied and many people can know it at once!
So if we are enforcing MFA requirements and allow this kind of clonable key, then we should really require some other factor that is not clonable.
That's the core silliness of this whole passkey mess, IMHO. So many turns of rhetoric and weird compromises, we have cargo cult security and no real understanding of what security level is in place.
Instead of the best of worlds, we can accidentally have the worst of worlds without realizing until it is too late and we're painted into one of those ugly corners.
> Heh, in the security world, this shows how your traditional metal key is "something you know" (like a password) because it can be copied and many people can know it at once!
If you have a photo of a traditional metal key, you can duplicate it. AFAIK, there's also a numeric representation of the height of each position on the key; if you know that number, you can duplicate the key. A traditional metal key is more like a password than most people think.
You don't need to ask permission to buy another key then register it to your self-hosted service.
In fact if you have the technical skills to make your own physical key and respect standards, e.g U2F, you don't even need to buy one and it will work with existing devices and services. I can recommend the Precursor for an interesting exploration of that from a verifiable software/hardware perspective.
You don't copy the keys themselves, instead you make multiple relationships with different keys. You can get as many or as little keys as you want. The point is the keys themselves are not important.
The keys are vital, and if you lose them you're SoL. A major hurtle is that you cannot create multiple relationships with different keys. Each key can only be used once.
That's not accurate. Bitwarden syncs passkeys across all my devices including both mobile/desktop (iOS/Android/MacOS/Windows/Fedora) using Chrome/Edge/Safari (I haven't tried Firefox).
KeepassXC is an open source alternative for cross-device synced passkeys. Marginally less secure than device bound passkeys but it's seamless and I save so much time now being able to login with one-click everywhere instead of wasting it on arbitrary "let's make sure you're you" MFA nonsense.
Passkeys have a marketing problem where no one is able to describe simply what it is without having to use technical jargon. There's also the problem where each OS tries too hard in pushing this to the face of end-user
This burden is on the site using passkeys. There should be some equivalent of “My Account > Security > Passkeys > Add Passkey.” There often isn’t, which is an incomplete implementation. And yes it’s frustrating.
As implemented they also lack conceptual integrity: you get them somehow (where are they?), and somehow you can use them (how, exactly?) but you can't enumerate them anywhere, see them, see where they came from and what they can do for you.
Imagine a password, but it a) types itself for you and b) detects when it's being sent to an impostor site and blocks them from seeing itself, so it can't be phished.
Cool, where are they stored? (I know the answer: 'it depends', and that's the big problem with their usability: most users haven't a clue what the answer is and most tech support can't answer that question straightforwardly because it depends on some decisions the user probably didn't even realise they made).
If you're using a USB hardware token your knowledge of it is at least an order of magnitude better than the median user's. I know where my passkeys are stored, I don't know where my family member's passkeys are stored and neither do they. The same is true for most of my otherwise fairly technical co-workers.
There needs to be industry and government leadership on this to gradually require hardware token usage, for at least critical financial and government applications. Right now everyone is putting their energy behind passkeys, but those are much harder to understand than a physical token. I don’t know any non-technical people who understand how passkeys are normally tied to the device (or the manufacturer-provided cloud account in some cases), how to set them up on a second device, why you might want to do that, etc. And many technical people still don’t get it either!
Absolutely not. If that is required, I will do my damndest to only use implementations that deliberately lie about the hardware status. Your line of reasoning is dangerous.
Then that family member does not worry like you do worry. The main point is assuming one can have a proper security for Google account - everything else becomes easy.
The fearmongering of losing google account should stop. Yes, some people lose it. There are a larger proportion losing/getting pwned by repeat use. For the majority - just pressing the fingerprint to access an account (like amazon/eBay) via passkey is great.
Fairly technical co-workers - I used to suggest them to buy USB security key few years ago. Now that same fairly technical some how has at least 2 devices with them - so they just skipped the USB security key need - and just use Google (in Android) or iPhone in Apple ecosystem. Everything just works.
Yes, there will be a poor soul that may lost everything with only one device.
People keep their entire lives in cloud accounts these days. Their passwords, financial history, copies of important documents, baby photos, etc. Losing access to it is incredibly disruptive and may result in unrecoverable losses.
Working for millions doesn't imply a good hit rate. Google could release a feature that worked 1% of the time and manage that, as well as barely noticing if it wipes out 10% of their users. My actual experience is that almost all the people I know who are using passkeys are using them by mistake and it's only not a big problem because they aren't currently being used up to their promise of preventing the vulnerable authentication methods.
The biggest issue with passkeys is that since most USB tokens that support them don't allow syncing the private key to a backup device you have to enroll ALL of them to every site that supports passkeys. This is annoying but it makes storing backups in secure offsite locations impractical.
The entire problem with passkeys is that zero of the issues should have been a surprise, because it should have been part of the design discussion from the start, so the fact that it's not properly implemented before being forced on users says that either it's been done horrifically incompetently and nobody should trust it, or they internally found these concerns and ignored them which means this system is not at all meant to help us, so why is it being forced on us?
It's beyond annoying. It's creating needless toil that no "normies" will ever actually do.
I'd love a hardware sold in multi-packs and "born" at the factory with identical internal device key encryption keys (DKEK). I'd love, even more, if a token just allowed you to "commission" new ones w/ a user-specified DKEK on first use.
I'd use one token as a daily driver and store the other(s) in safe location(s), empty of my personal key material. (Or, if I can just commission a new token w/ my DKEK, store a printed copy of my DKEK in a safe location.)
Give the token a mechanism to "type" a backup of its internal state, encrypted with the DKEK, as a USB HID keyboard. That gives me an easy way to backup the token each time I enroll a new website.
If I lose my daily-driver token I just pull a spare from storage, import my last backup, and I'm up and running.
That would kick ass. No "You just need to buy two tokens and enroll them in every website" bullshit.
Maybe each token also needs a second key, with the DKEK used for authentication and the second used only for revocation. The main reason not to reuse the DKEK is so a lost key can be easily decommissioned.
You would need some out of band way to collect and save your key IDs and publish revocations.
I’m not sure if this would work from a security theoretic perspective, need to think about how the request is signed and transmitted so someone can’t fake a key being “alive” when it’s really “dead”.
I do agree this would be incredibly useful if it can be made to work.
I haven't used a FIDO2 token other than playing around with it on a Yubikey. There, at least, I have to have the PIN to unlock the Yubikey before I can use the FIDO2 credentials (if I'm remembering correctly).
Are there hardware token implementations where mere possession of the token is all that's necessary to use the passkeys stored on it? That's incredibly stupid, and should have been disallowed by the standard, if that's the case.
Yes, the PIN is optional even on Yubikeys, although I think individual providers can require it. Ideally a strong PIN should be used but people may just reuse their ATM PIN, birthday, etc.
That is how almost all standard FIDO2 tokens work. You just have to press the capacitive sensor when prompted. You can get fancier biometric tokens that require a fingerprint.
How do I use it on my desktop or laptop then? What if I switch browsers on my phone? What if I get a new phone? What if I change from android to iOS or visa versa? What if I need to log into the site on my Wii U's browser?
You can let Apple sync your passkeys between devices using iCloud Keychain. Then you can create a passkey on one device and have it available on all of your devices. Google also syncs passkeys to the cloud and lets you use them on Windows (with Chrome)
>What if I change from android to iOS or visa versa
I resolve this by storing most of my passkeys in my password manager. I still store the "important" ones (like online banking) in my phone so a password manager breach doesn't make me lose my money.
>What if I need to log into the site on my Wii U's browser?
Passkeys were designed to let you have more than one, so if you have a device that doesn't let you use your password manager, then just set up another passkey.
Nothing wrong with your answer itself, but having to be Apple or Google is a PITA. These account are ultra critical already and you will want maximum security to access them.
This means if you go on a trip somewhere you absolutely need two devices. If you kill your phone and want to buy another one ASAP, you wont be able to do anything with the new device until you can convince the platform it's you. With passkeys you're just SOL. Imagining if you needed a phone to get back from your trip - e.g. etickets, auth needed etc. - it becomes a nightmare scenario.
A third party manager makes it easier, but it's a lot less usable that the first party ones.
Reasonable people make different life choice, having to constantly think about backup strategies whenever I'm away from home would be so stress inducing to me.
No more so than if you lose access to the device that's required for Google/Apple MFA prompts, neither of which use SMS and depend on a proprietary approval flow.
If you lose your phone in 2026 while on a trip to Italy and try to enter your Gmail user/pass from your wallet, there's about a 100.00% chance you'll hit a "let's verify you're you" gate, that's been the case for 5+ years.
With passkeys I'm not stuck clicking Yes in the Gmail app or typing in the numbers on Apple hardware, I can skip the Apple/Google specific MFA nonsense and keep the passkeys in Bitwarden where they sync seamlessly between devices.
It feels truly liberating being able to skip MFA everywhere and login with 1 click, like a throwback to the golden age of using a password manager in 2010. Before passkeys it started to feel like I was spending 5% of my waking hours every day copying 6 digit codes from phone/email/TOTP after twiddling my thumbs for 15-30 seconds.
>This means if you go on a trip somewhere you absolutely need two devices
If you want multi-device redundancy, you have to carry a second device of some type, it's hard to get around that. I almost always travel with an iPad in addition to my phone, so I have a second device.
In addition, my wife (who travels with me so if my iPhone is stolen, hers might be too) is one of my Apple account recovery contacts, plus I've set my sister as an addtional recovery contact, so even if I'm out of the country and I have to activate a new iPhone, I can call her to help with the recovery. So all I have to do is find an Apple store and buy a new phone.
I also carry a USB key tucked into my luggage with the recovery kit (encrypted) for 1Password so I can activate 1Password on any new device and have access to my passwords and whatever passkeys I don't have in iCloud.
I just don't use Google or Apple accounts for everything. I don't want my whole life in the hands of some big tech deciding how I should prove to them that I'm me.
I did use Microsoft 365 (business version) for my email but they also decided I should use their MFA app so I left. I did have my yubikey as second factor but they keep pushing their stupid authenticator app.
as long as you have one working device all will be OK. Either you scan the QR code shown by the website. or if you did login to Chrome with google account then desktop or laptop will just sign you -friction less. Same with iCloud account.
If you browser vendor has implemented passkey then all good.
Most things are built for the majority users. Most don't change. Most don't debate browser wars in hn. Life is like that.
For Wii etc. You just scan the QR code shown in the TV interface. all just works.
Yes, if you want 100% privacy and will do only your own dovecot server then it is not for you.
A majority have more than one phone. Or at least they can get a new SIM card and sign into the iCloud account. Then all passkeys are synced from cloud.
Yes, if you are edward snowden then not for you. For rest of us - it is useful
You are exaggerating. If the loss or lockdown is so bad then many would have stopped using any of icloud or google equivalent. People are able to depend on it. People are able to repair and use phones even when it falls into abyss.
Not always. And which vault? There can be multiple on a given device. This isn't some hypothetical 'mollify the user's worries' question, this is an important practical question of what do they need to worry about losing access to. Trust me when I say that most users I have talked to have absolutely no idea about this, and usually only find out when they've already lost them.
As others have pointed out, this is a terrible oversimplification which misses all the nuances which cause people headaches when using passkeys.
To your point, I for example would add point c) - Is linked to the device you are using currently. If you want to use another device to log in you are in a world of complexity and pain.
Are you part of the 99.99999% users of one of iOS+Apple or Androidlike+Google/Tencent or HarmonyOS+Huawei? If that's the case, you don't need to as the key is automagically saved by your OS' platform and synced with your new device.
Otherwise, you're such an extreme outlier that you probably either know what you're doing or can find out by yourself, right?
> … users of one of … Google …? If that's the case, you don't need to as the key is automagically saved by your OS' platform and synced with your new device.
This absolutely does not encourage confidence in me. We all know how easy it can be to get locked out of a Google account and have no way of getting back in unless you have enough clout to make a huge noise online so a human there pays attention instead of you being stuck in the 'ol support-bot-run-around loop. It doesn't happen often when you consider how many users there actually are out there, but the potential inconvenience is high enough that “fairly rare in the grand scheme of things” is still enough to be reason enough to be wary.
How can it be saved and synced without credentials? I'm in that overwhelming majority, but I don't grok how I can recover the account when my phone is lost/stolen/damaged. The answer appears to be, use another device that was already logged in?
I tell people a website is like a payment terminal. Your device is like your debit card. A password is like a PIN on the card. A Passkey is like a chip on the card.
Logging into a site with your device is like putting your card into the terminal. The site can ask for a password the way the terminal asks for a PIN, but if your device supports Passkeys, that’s like your card having a chip, and it’ll use that instead.
So think of Passkeys like using a chip card.
I dunno how well this analogy works down to the last detail but it has gotten it across to all the parents I’ve used it with
Probably not. The magnetic strip was easy to explain (it contains some info the terminal checks, it's functionally just a long password), but it's also pretty easy to explain why skimming was a problem. Explaining how chips fixed that (signing keys and cryptography) is probably beyond a 30 second explanation with Joe Schmo.
Then again, I doubt most people care to know, which is why that explanation works. They're not going to ask 'where is the passkey in my computer?'.
Unlike physical objects they may reside in a TPM, a software vault, an export/backup, or any combination thereof. You may or may not be able to recover or migrate them, depending on where/how they were made.
Therefore you may need multiple per service, or maybe not. Services which only allow one may end up locking you out with no recourse. You get to find out.
None of this is obvious or self explanatory to normies.
That's false. It's a digital key and it doesn't matter where it's stored. My key is on iCloud and it can be unlocked with my many recovery methods and contacts https://support.apple.com/en-us/102641
As for normies, passkeys or passwords it doesn't make a difference. Either you have people who use love1969 everywhere or those who constantly lose their passwords.
All passkeys accounts for normies require an email or phone number, which is what you can use to recover a password or passkey exactly the same way.
Probably because these caveats and weird behaviours are platform-dependent, not really the passkey’s fault.
Passkeys really are not any more difficult to explain than 2-factor authentication. Anyone who’s currently been able to actually create an Apple or Google account and successfully navigate their devices up to a passkey screen will be able to grok how it works.
People around here really ought to stop thinking users are complete idiots. Hell, you don’t even to scroll that far to read people calling users “normies” for crying out loud. What is this? High school?
I don't care about the theoretical sufficiently advanced keypass implementation that works perfectly. I want to know about the half baked ones in the real world that I'll have to deal with.
Arguably Yubikey and similar are better. Even vanilla passwords are at least understood by my parents, despite their confusion over account proliferation. Passkeys are a step backward for them, even more so in light of account confusion.
They're separate stores. I was under the same assumption until I tried to use `security` to get a saved password. It doesn't work, and as far as I know there is no CLI for the Passwords app's store.
ok cool so when somebody logs into a site on their phone and sets up a passkey, then goes to their laptop and tried to log into the same account, how do you easily explain how to deal with this situation?
What I have seen is that the site gives you a QR code to scan with your phone. People are already used to needing their phone to sign in via an Authenticator app or SMS code.
That's the main thing I wish was done better. There was barely any actual lead up from the perspective of an average person. Just a new unfamiliar flow on half of the login screens that they use.
Sure, its explained. But not in a satisfactory way that would reach all users at their level.
This is a bit of an exaggeration and out of proportion, but I think my ideal would be one of the big tech companies should have bought out something like a super bowl ad. Something that actually conveys the idea "hey, we know you've used passwords since you were able to type on a keyboard, but here's new technology that's better and here's why" in plain language that the average person can understand.
Unfortunately, XKCD 2501 continues to be relevant. [1]
The average person? I have a Master's and PhD in CS, code regularly, and have followed and used all the cool technologies from the days of gopher, telnet and Mosaic to crypto, and lately LLMs. And I still don't have a clear enough picture of passkeys to know really basic things like "what if we have a family computer but each wants to access their private accounts and keep the others from accessing?", "what do I need do to login from an airport computer?" or "what should I do if my phone is stolen?"
If it's that unclear to me, I can't imagine how it can be to the average user.
The way they explain them is atrociously unclear, borderline negligent for services that nag people to activate it for accounts where they may hold valuable data for their personal lives. And while I don't want to spend much time finding out the details as long as I have the option to decline them, I suppose if they can't explain it and convince people of its advantages, it's because it's just bad tech.
> "what if we have a family Computer but each wants to access their private accounts and keep the others from accessing?"
That's what OS level user accounts are for. Tbf
> "what do Ineed do to login from an airport computer?" or "what should do if my phone is stolen?"
Indeed I don't know the answers to these either if I wasn't syncing passkeys in 1password. Honestly we should educate people to use password managers more than any thing. It's also a smaller jump than to passkeys. Passkeys can be more of an advanced convenience feature after they get used to using password managers already.
Passkeys remind me of ipv6 in that they are a "solution" coming from the supply-side, without (apparently) having done any research in what motivates actual users (and what would motivate them to switch).
They make sense as a technology for businesses & their users. In that scenario, the owner of the account is not the user, but the business. It makes sense for the business to be able to place strong restrictions on how & where the user may log in, it fixes a lot of real problems businesses may have thanks to sloppy user behavior, and the business is also motivated to provide a way to fix broken logins. It's a good solution for that scenario.
But for regular end users where services are primarily motivated to take money from those users and lock them into their ecosystems, they are a usability disaster and yet another exploitation vector.
It's one solution for two very different usecases, and it just does not work. There is an approach that could work for end users who own their own accounts, but they need to go back to the drawing board and rewrite the protocol with the assumption that the keystore is hostile to the user's interests. That means strong guarantees on key portability so users can migrate away from hostile keystores, and absolutely no ability for services to restrict the user's choice in passkey provider software.
> and the business is also motivated to provide a way to fix broken logins. It's a good solution for that scenario.
This is a big part of it. An employee at a business will be able to talk to someone in person and say 'I can't login. Can you reset my password?' or whatever equivalent, and be made whole. Even if the business is is made up of 10000 people and the identity of the employee is for some reason in question, the situation can still be resolved with a passport or a driver's licence.
Google is never going to make you whole again if you're locked out of your account, unless you're a celebrity and make a stink. There is no help desk where you can prove who you are (and even if you could, would you want to? That's a whole second domain of problems that I'm not sure will ever be solved completely).
I think passkeys were made to work in mind with complete idiots (here's a pop-up, tap it, now you have access to website without password, don't think about where it was saved or that it exists at all). I can understand parts of IPv6 like Router Advertisement being like that but there is so much customizability for the user that I can't really see them being similar that way.
It'll work if you have a laptop on the same account, iCloud or 1password or whatever else. If you only had a phone, you set the account up again on your new phone.
> To an individual, the greatest risks are instead permanent account lockout, automated account bans, and device loss. By using passkeys, you gain better security against man-in-the-middle attacks but face the higher probability scenario of losing access to your accounts.
I'm glad to see this view becoming more mainstream. Passkeys are grotesquely insecure.
The only possible way to consider them more secure is if phishing attacks were more common and more damaging than lockout, which is so implausible that I reject the idea that someone could take that position in good faith.
Lockout is a real risk, but there is nothing insecure about passkeys. Private keys stored on the secure enclave + biometrics or passcode before any signature is produced + origin binding mogs a static string and a 6-digit TOTP (often generated with a secret key outside the secure enclave) that can be phished and entered from anywhere. Also, in many (possibly the majority) of scenarios where someone is locked out of their passkeys, they’d also be locked out of TOTPs and passwords.
> The only possible way to consider them more secure is if phishing attacks were more common and more damaging than lockout
Security as a field would be a lot less obnoxious if it did not neglect availability as an important facet of security. A 'security' system that obstructs legitimate access is also failing at its job.
> Lockout is a real risk, but there is nothing insecure about passkeys.
secure - adjective
se· cure si-ˈkyu̇r -ˈkyər
securer; securest
1
a: free from danger
b: affording safety (a secure hideaway)
c: TRUSTWORTHY, DEPENDABLE (a secure foundation)
d: free from risk of loss
Passkeys as a sole/required method of authentication increase the risk of permanent loss. In any other configuration they do not mitigate phishing risk.
It is not possible to say there is nothing insecure about them.
Information security has the concept of the CIA triad: Confidentially, Integrity, and Availability.
Being able to access the secured data is an essential element of security, otherwise a safe encased in concrete dropped to the bottom of the ocean would be the most secure storage available.
I’m not disputing the fact that “secure” has different meanings in different contexts. My point is that when we talk about the “security” of authentication methods, we almost always are referring to its resistance to attacks, exploits, social engineering, etc.
If you tell the average non-technical person that “passkeys are insecure,” they’ll think that it’s easier for (WLOG) Russian hackers to phish or bypass their way through some website’s passkey requirement.
And to be clear, I don’t think it’s ridiculous to say that right now, the risk of lockouts outweighs the security benefits of passkeys. But this is a fixable problem. If it gets easier to securely recover or back up passkeys, I think we can reach what is more clearly a “best of both worlds” of security and reliability.
The context is literally the line quoted from the article, which made it reasonably clear what the word was supposed to mean, and you decided that (1) you understood what they meant, and (2) deliberately tried to bring up an alternative meaning and object to it, and (3) continue arguing why (2) was justified by taking the sentence out of its context (and into your hypothetical context).
> security against man-in-the-middle attacks but face the higher probability scenario of losing access to your accounts
The author says "security" against man-in-the-middle attacks. Are they not using the typical cybersecurity-context meaning of "secure" that I just mentioned? (Resistance against exploits, attacks, social engineering, etc.) And note that they say "higher probability scenario of losing access to your accounts" rather than something like "lower security against account loss" which would have been admittedly understandable, but a bit less clear since the more common cybersecurity meaning of "security" was just used.
> deliberately tried to bring up an alternative meaning
I am using the typical understanding of what "secure" means both 1) in the context of the quote from the article you used and 2) generally in the context of authentication methods. Let's not act like I dug up some obscure and irrelevant alternative definition.
> and into your hypothetical context
Is it really so unrealistic and hypothetical to think about how non-technical people (i.e., the vast majority of people) will interpret the at best questionable statement that "passkeys are insecure"? I stand by my claim that most people will get the wrong idea when they hear that.
> if phishing attacks were more common and more damaging than lockout
The calculus changes if the service is a bank or your stock broker, which, if you are in any reasonable jurisdiction, if you can prove your identity (in court) they are legally obliged to ensure they give you back your money.
But, for the vast majority of other internet services... I honestly don't think anyone would want to MITM my instagram account for example.
How do you solve these problems other than memorizing every password? I guess you could keep a piece of paper with backup codes, but that works for passkeys too if you use the right manager.
You should always plan for your currently active device to be bricked suddenly and act accordingly.
You either should treat your passkeys with a backup like any data, this can mean multiple hardware keys or a cloud backup of your passkey, like bitwarden or the provider's native backups.
The key word in the post you're replying to is "normal". Non-technical people don't (in my experience) plan for this kind of thing, like at all.
The idea of multiple hardware keys, which have to be enrolled individually to every site, is just not an ordinary end-user friendly activity.
So passkeys may be great for technical users (who are happy doing that) or corporate users (where centralized IT systems can be put in place) but not for standard non-corp users (which realistically, is most people)
Not talking about you. After all passkeys are not there to protect people who have home labs and don't recycle passwords anyway? They're for normal people who only have one device.
> who are happy doing that
You think they're happy? I'd say they grudgingly comply at best.
Suppose you do want a secure solution for the main sites your stuff is on. But every piece of shit content mill also wants to set up a passkey.
Depends. They make it pretty easy for people who don't think about the consequences of things.
I worry I am going to get locked out of my Google account, muggles don't. Doesn't stop them from getting locked out.
Apple has a vision where you have an iPhone and a mac at home and a mac at work and a vision pro and an Apple TV and all of that and your passcodes "just work". Doesn't work for the "rest of us", like we're already used to AirPods punishing us for using Windows.
>Apple has a vision where you have an iPhone and a mac at home and a mac at work and a vision pro and an Apple TV and all of that and your passcodes "just work".
I have many of those and I fucking don't want them to "just work". My iPad is not my iPhone. My Mac Mini is not my iPhone. Yet my iPad at home pops up the speech-to-text voicemail notifications from phone calls that I chose not to answer while I am miles away at work. It's so fucking annoying that you can't specifically turn that off.
My usual "go kit" has my iPhone in my leg bag and then my iPad is either my main bag or one of those pouches that waitresses wear which has plenty of room to pack a tablet. I like using the hotspot (being parsimonious with data) and being able to respond to texts with tbe big screen. It's also nice that I can share passwords and passkeys easily between them.
Other aspects of the "Apple Lifestyle" make no sense to me, like I an a mirrorless photographer and use my iPhone like my Sony, I will go out with my selfie stick and shoot 200 selfies, transfer them to my computer, pick the best 3, them clear them all out.
I plugged my iPhone into my Mac when my wife was logged in and it tries to back up the whole 'freakin phone and renames it "Olivia's Phone" which is just nuts. Of course their answer is that you never clean out your phone, you just upload it all to iCloud, where I think the value proposition is you can pay $1 a month and stop all the dialogs nagging you to get it... Now only if I could have made the badge for Apple Arcade to go away by trying the free trial and canceling it!
No, microsoft uploading disk encryption keys to your account is the exact opposite situation. It's microsoft purposely reducing security to ensure there is a recovery path, because average people don't need or want the security tradeoffs where "You permanently lose access and it mathematically cannot ever be recovered" is a failure mode.
If it was possible for a key to your house to have that failure mode, nobody would ever lock their doors
It's the classic "make your problems worse to fix my problems" that you see across tech. Since they don't care if you get locked out or leave their platform, it's designed to make them maximally profitable. It's the same thing you see when sites "offer" to let you do pre-registration work before an event or transaction, even though doing that work at registration is often trivial.
Want to get a RealID? You can spend 30 minutes scanning and uploading your supporting documents through the website, or you can hand your documents to the person at the desk and they'll evaluate it in 30 seconds. Over thousands of people, it's rational for the organization to optimize away that 30 second review (it also gives people a recovery option if they don't bring the right documents.) For the customer who is competent enough to bring the right documents, the latter approach is way more efficient. I regularly have to put myself in the "I'm old and hate technology, so lets do this the manual way at the desk" flow even though I'm totally capable of doing the electronic flow.
My situation at work is absolutely untenable. Constant redirects, logins that used to have passwords but now have passkeys, but you don't find out until you enter the password. Chrome hijacks the passkey dialog and wants me to use my yubikey, but I have to fumble around and bypass that to then get it to prompt me for a passkey in Apple Passwords. (as long as 1Password isn't trying to intercept my passkey requests today!)
Then on top of that there's a whole 2nd factor layer which _also_ typically involves a touchid press but for a totally different reason (as the 2nd factor, not to unlock the password safe storing my passkey.
It's just an ugly inconsistent dance, dozens of times a day.
I know these gripes are mostly about implementation, and partially about user-facing software, and partially about user choices, but it doesn't make it any less ugly for the user.
I love passkeys. Really. They completely eliminate the need for a password and OTP in most cases (when actually used as they were intended and not as a second factor only), although I always set up both in case. Although I will never, ever like how Google does it. I set up my first Google account with them and now Google absolutely refuses to allow me to authenticate to it because it wants a passkey I don't have (and of course there's no way of not using said passkey) or it wants me to use an Android phone I (also) don't have (I traded it in a couple years ago). And, of course, it provides absolutely no way around that problem. So eventually I just gave up and created a new one for the (rare) times I do need a Google account for anything.
Passkeys are somehow 100% seamless for me, except for two services that have somehow screwed up the implementation: Google, and Okta. In Google's case, they have made it so that if you _ever_ add a passkey to their password manager, it somehow refuses to work with a third-party password manager going forward. In Okta's case, the admin policy UI makes it next to impossible to have passkey-only login without their Fastpass app or an oldschool password login.
> How much will you love them when you're locked out of something you can't do without?
I certainly wouldn't be happy if this did happen, but it would be my stupidity (or the stupidity of those who implemented it on the service/platform where the problem occurred) which I would blame more than the fault of the tool. I do keep all passkeys in Bitwarden now so that's something at least.
Security benefit appears strongly overstated. Compared to using a password manager (including generated secure passwords for each account), there isn't a significant security benefit. passkeys require using a manager as well, so there isn't much point.
> ...but it would be my stupidity...
All people are stupid sometimes. A security flow that doesn't account for this very well isn't a very good security flow.
(Related: everyone tends to be unlucky eventually, and, unfortunately, everyone becomes incapacitated/dies eventually. Security flows need to account for these as well. Not to mention that in my experience, no software company continues to offer a quality service at a reasonable price forever. You're lucky to get 10 years. Having access to my accounts tied to a single piece of software is likely to become a big pain at some point.)
I think this is probably one of the reasons people have very different passkey experiences. Hardware passkeys are great and software ones appear to be less great.
Do passkeys improve security posture for the average person, reducing the likelihood of them losing their accounts to fraudulent actors? Absolutely.
But they also introduce single points of failure, as the article points out. I can't even remember how many times I've had to help a family member recover their account or get confused when they can't sign in on a new device. It's incredibly frustrating that this flow is promoted as the default for so many services.
1password is the best solution I've found for the average person. It's not perfect (it's definitely more complex than writing down your passwords on a piece of paper or using the same password everywhere) but it's much easier than juggling yubikeys. I know so many non-technical staff members who prefer the OS or browser keys even if it means another account recovery is lurking around the corner.
I actually prefer non-resident U2F in some ways. You don't have to store anything on your key, you are just signing requests. This is relevant where U2F/FIDO keys have limited slots for 'resident' keys.
In principle, it's great. You have one good password to remember for the average user, and that's enforced by their device's probably good enough security posture.
They are resistant to being phished and they won't reuse the same one everywhere. They then don't end up going from hunter2 to hunter2! everywhere.
But my experience for users is that they worry they are giving their biometrics to Amazon or whoever and so the UX just confuses them.
The certification aspect was new to me too last time passkeys came up. Sites can require that a given passkey has been certified.
The patchy support for them is also frustrating. MacOS does not support NFC FIDO/U2F. iOS does.
Absolutely! U2F keys are unlimited, but I only have so many slots on my hardware key. And now sites are moving away from supporting U2F towards a passkey-only model. No! I have limited slots!
I don't want to have the security sensitivity of my devices be escalated by the fact that I access a very important service with that device. Currently I have separate passwords and a 2FA on my investing and bank accounts. I don't want to have to treat my cheap travel laptop as a SCIF because it is synced with my cloud services and has passwordless access to my entire financial life.
Two crucial things you can do with a password that you can't do with a passkey:
1. Write it down on a piece of paper and put it in a safe deposit box.
2. Read it on one device (or from a piece of paper!) and enter it manually on another device.
Plain text is the ultimate form of cross-platform portability. Passkeys are the ultimate form of vendor lockdown. The passkey vendors won't even allow you to view the private key, unlike with ssh keys, which you can also write down on a piece of paper. It's vendor cabal to destroy computing freedom in the name of "security", always the excuse. Tech company paternalism at its worst.
If passkeys were meant to be user friendly then there'd be a secure optical transfer mode to QR code them from device to device with the screen and camera.
Easy to implement (receiver flashes a public key, sender encrypts to that key and flashes the QR code back).
That it doesn't exist for a protocol meant to work with phones tells you exactly where the thinking was headed.
That they have purposely put effort into preventing you from doing that shows you everything you should need to know.
The entire point of passkeys is yanking the control over authentication out of the hands of people. These companies don't want you to be able to let someone else log in as you.
That's the entire point.
The problem they are solving has absolutely nothing to do with security.
Completely agree. I think the root of many of its issues is the inability to add a key that you don't currently hold. This prevents me from storing a backup key in a safe, for example.
I proposed an alternative scheme many years ago: https://www.researchgate.net/publication/343318317_Privacy-a... . By allowing "offline" keys you can also treat them as higher priority, and use them to revoke any lesser keys from attackers if your account is compromised.
It would also be nicer to get rid of usernames, but that's a fight against the data-gathering powers that we're unlikely to win.
From TFA: "Both Apple and Google want your identity anchored to their operating systems. The “happy path” on their devices is to use their synced passkey management tied to your Apple or Google account. If their automated systems decide one day to ban your account, you irreversibly lose access to all your passkeys used across all third-party accounts too."
This is, in my opinion, the most serious problem with passkeys. I'd like to adopt them, but this is a blocker.
So where do I keep my pass keys is the problem. They are in my password manager just like another password. So what's the point of having them because effectively, the passwords in the password manager and the passkey in the password manager offer the same UX to me? Except that at least I can memorize a password by heart just in case.
>They are in my password manager just like another password. So what's the point of having them because effectively, the passwords in the password manager and the passkey in the password manager offer the same UX to me?
same ux, different security properties.
>Except that at least I can memorize a password by heart just in case.
"just in case" should be a thought out recovery flow, rather than hoping that you remember the password of the account you need to access.
That is the point. They stop you from memorizing it “just in case” and reusing it, and they force you to use a password manager.
For the average user, which doesn’t use a password manager, this is great. It means they can’t get phished. And it’s also great for the average password manager user, who keeps dozens of insecure and reused passwords in their vault because they manually thought of a password when signing up instead of randomly generating one.
If you’re already using a password manager and random passwords, the UX is designed to be the same. It’s just a way to get regular people to do this.
> Since they are bound to the site they are created for, they cannot be phished by a hacker’s fake login screen.
With the app you use to store those keys (a password/key manager) it's the same - you simply wouldn't have an autofill working. Sure, people can and will circumvent this for the benefits of the scammers, just like they can circumvent passkeys using non-passkey login option, indeed:
> weakest recovery method: SMS
> If a site suffers a data breach, passkeys are asymmetric and cannot be recovered from the server-side details.
Similarly, don't other modern password storage methods have the same property?
> lacks the decades of UX polish towards password autofill.
A lot of years in those "decades" have been wasted polish-wise: you still can't log in with a single button, e.g., many popular sites only fill a username first, then require an extra dealy and action before accepting a password
Fake websites pretending to be legitimate websites in order to steal your passwords was considered a HUGE problem. That's why TLS includes website certificates. The implementation is kind of a mess with commercial Certificate Authorities (CAs) being too expensive for small businesses to use, CAs getting hacked, or downright shady CAs that couldn't be trusted. A lot of websites didn't use TLS because of these problems. It took decades to get to the point we are at today where we have Let's Encrypt and all websites using TLS. Yet phishing still works because fake websites can use a URL that looks legit and they can get a certificate for that URL.
We need to get away from shared secrets for authentication. Passkeys are fundamentally a way to do that, but they aren't perfect. Personally I wish TLS and Passkeys both were way less complicated. I think we could use asymmetric encryption for authentication without certificate authorities and secure enclaves and all that and still be more secure in general than we are today. Think ssh keys. But no browser or webserver does that.
I think our best bet is probably to aggressively use passkeys and work (as was done with with TLS) to make them better until it mostly fades into the background like TLS has.
The best solution I've found is yubikeys. I keep them on my keychain with my car's key fob. If I lose that key fob I don't know how I get my car started. It's not like the old days where you could pick the lock or get a few copies of the key made for cheap. Same with yubikeys. I worry about losing my yubikeys about as much as I worry about losing my car keys. A little, but not too much. I use both so often that it's not too hard to keep track of them.
The author talks about the problem with using hardware keys, but they neglect to mention that many websites and apps simply do not allow the use of hardware keys! They will insist you use Apple or Google syncable keys. So after you have spent the money to buy 2 or 3 hardware keys, you find that they are not accepted.
I don’t like how tokens have gradually evolved from a secure 2F device that you carry with you (Yubikey etc) to a single factor “passkey” that’s built in to your computer/phone, or worse, a password manager with export capability.
It should always have remained a second factor device. It’s not impossible to teach people to use these, European banking did it for years. There’s just no will to do it.
If a user doesn’t have a second factor, what should their first and only factor be? The passkey people are trying to posit that a passkey is better than a password as the only factor.
Second factor should be gradually ushered in everywhere over a period of years, starting with banking, until it becomes second nature for users. This would effectively end concerns over strong or reused passwords, and would make phishing incredibly difficult.
Under this scenario, the first factor can be a short password or even a PIN.
It’s because we have effective biometrics now, so the need to carry around an inconvenient limiting physical 2nd factor is obsolete (for the vast majority of regular use cases)
I have physical passkeys, one attached to my keys and another on my desk at home and I absolutely hate software based passkeys. Every single time I'm asked for a passkey it always ask me if I want to use my Apple Keychain first and I wish I could default to physical.
physical 2fa should be an option, but i can never agree that we should force billions of regular people to use a harder to use and more inconvenient system that they have already indicated they dont want to use, for some mild security benefits
Why not? We “forced” everyone to use SMS/email second factor, now we’re moving towards “forcing” passkeys, and European banks used to “force” the use of an electronic HOTP/TOTP token.
Decoupling logins from the big cloud providers is a clear win for freedom and protection against abuse. People are frequently cut off from their cloud accounts for whatever reason, and I expect this problem to increase as global disorder increases.
(To be clear, I don’t think people should be legally forced to use tokens, but I do think that industry should be heavily encouraged in that direction.)
The experience is also junk if you're using a password manager, I have passkeys that I'm not sure if I saved to the OS manager or my password manager... mostly my fault but I enter passwords so many times a day it can be hard to stay on top of which UI I'm clicking yes in to store them.
Password managers are great IMO, I can use some absurdly long password, backup is reliable, I can use them across devices. For extra secure stuff 2FA works the same, I've got an app with codes I can easily back up and use from multiple devices.
Passkeys tend to obscure everything and take away a lot of control.
> Passkeys are a fantastic technology. Since they are bound to the site they are created for, they cannot be phished by a hacker’s fake login screen.
The same is true for passwords with a password manager.
> If a site suffers a data breach, passkeys are asymmetric and cannot be recovered from the server-side details.
Also not really a problem with randomly generated site-specific passwords in a password manager.
Really all the browser vendors had to do was add an API to make automatically generate a password that is then stored in the user's password manager the low friction option.
If you're doing that you might as well use public/private keys. The issues with passkeys are around user experience and education about how they are stored, and a lack of good backup options like enrolling a not-present device as opposed to relying on syncing them through an external service.
The huge UX drawback of password managers vs. passkeys is sites that have arbitrary requirements. "Your password must be between 9 and 12 characters long, and include at least two capital letters and a special symbol". Well, my password is randomly generated, and enforcing that there are two capital letters would just reduce entropy.
If sites fixed this issue instead of pestering me for a passkey I'd be happy.
My biggest gripe with passkeys is that the spec seems to force non-interoperability. I use a password manager and I would have no issue storing a private key in a profile there, but I am literally not allowed to be able to copy the private key. If a spec thinks it knows better than me, I won't use it.
And don't you just love the fact that now Apple and Google and Microsoft have MORE control of my identities across the web?
some password managers can pretend to be a passkey. but I don't use them because it requires finicky brittle configuration (and docs lookup whenever you want to redo it).
if passkeys had a simple text challenge response text option it would be fine, you would basically be using something like PGP logins. and would be easy to implement in a password manager interface.
as a result, I have zero interest in passkeys. a pity as it could have been useful (cold storage password manger + physical passkey). you can never trust any service to honor "backup" login options, got burned once for "suspicious activity". that is, if you lose a login option (passkey is lost) they can demand it in the future to "verify".
Multiple sites (e.g. Microsoft) currently ask me to use the passkey to log in after I enter my username, but the passkey doesn't seem to be stored anywhere. I usually will end up scanning the QR code to check if it's on my phone and get a negative answer. Then I have to go through the regular password + 2FA ritual I was already ready to use. After that, I am not given the option to store a passkey on the device I am currently using or on my phone. Process repeats next time. So much fun using passkeys.
I think there are two sites where I can actually log in using them.
I also don't like the way the pop-up is always so automatic and interrupting. Why not a button like other ways to log in?
It's the stupidity of Service Providers to adopt passkeys in the first place.
As a service provider myself, I've evaluated and said "Nah" to passkeys - because it's simply increased Customer Service contacts I have to invest in, whenever a user changes or loses devices, or any of the hundreds of ways Passkeys are not portable.
And guess what, the Tech companies pushing this have zero liability for user login support or security breaches. It's always me. There is no need for me to work hard and spend CS contacts, to wall off my users to the OS or Browser vendor.
I'll simply do passwordless Email or SMS 2FA / Magic Links and own my users without the overhead of Customer contacts, thank you.
I understand many passkey complaints but not this one. Why, for you as a service provider, are passkeys not just better (or at least equivalent to) passwords? You collect and verify an email address at signup and the account can be recovered in the same way as with passwords, or passwordless-email. No CS-verified recovery needed.
All right, my framing was a little too tight. Sure I can see why an email/SMS passwordless loop is easier for you, but it’s a more annoying user experience than your OS/browser/password manager just filling in your credential directly.
Passkeys are great in that its turning login support on websites into simple "autheticate your device to seamlessly login". My biggest gripe is that it seems Apple/Google are using this to consolidate control into their own password ecosystems and don't support password managers as a store for passkeys.
What I dislike about passkeys far more than any of those qualms is that they can implement remote attestation.
A website should not be able to dictate what application I use for passkeys, what hardware the passkey is stored on, or whether I'm allowed to duplicate my own key.
Just yesterday I was showing to a friend how I logged in my self-hosted forge with my own hardware key.
0 intermediary yet proper and convenient authentication. If that friend ate the key (which he didn't) I'd just use my backup key, a cheaper non biometric one.
I think it's not more popular because people don't care enough about security to buy actual keys, rely instead of 3rd parties that they don't actually trust, e.g. Microsoft, Google, etc then... complain it's not good enough.
> By using passkeys, you gain better security against man-in-the-middle attacks but face the higher probability scenario of losing access to your accounts.
> Phishing through the standard login flow is eliminated by passkeys, but it creates a false sense of security. An account’s security is still dictated by the weakest recovery method: SMS, email links, security questions, and so on.
Passkeys are too strong and may cause account loss.
Passkeys are too weak and can be bypassed by account recovery.
>This leads to passkeys being the perfect fit for a corporate environment, but a poor fit for personal security.
I 100% agree - almost everything about them screams "this is The Ideal Corporate Solution".
This isn't a bad thing, it's nice to have a standard for corporate uses. And the attestation-DRM stuff makes perfect sense there, you already have MDM and it fits with that perfectly....... though not all that differently than using MDM to set up client-side certificates. But app/OS support is better, for some reason. Why didn't they just improve that flow?
For personal use though, they seem outright hostile to people living in the real world with common failure modes. It's outrageously clear that normal people were a distant afterthought - just look at how hostile it was to syncing at the beginning, and how long it took to get key exporting (and how directly hostile they were to anyone building a stopgap in the meantime).
I agree with all the points this articulates. I understand why for many users they are great. But I would prefer better acceptance and continuance of the simpler, unfishable, u2f simple hardware keys.
The point about Google or apple or your passkey manager banning your account is a reason I'm still using random passwords in Keepassxc. I don't know if there is an open source passkey manager that syncs across devices that is self hostable.
Anyway, companies should be educating users more on passkeys, how they work and where they get stored.
I love passkeys as a tech enthusiast with a password manager that can hang on to them but I don’t love them as a confusing user experience for the average joe.
I also don’t love how many websites and apps use them in stupid ways like using them alongside other 2FA or login methods when the passkey alone should be sufficient.
You’re the first person in these comments to mention 2FA with passkeys.
My gripe with passkeys is they are almost always implemented without a second factor.
You’ve mentioned the rare case of 2FA with a passkey as being a bad thing, but in my opinion those few cases are actually doing it RIGHT.
With passwords and 2FA, if someone manages to copy your primary authenticator (password) they will still be locked out because they don’t have your secondary authenticator. This protects you against malware that steals your password database.
But the way most companies implement passkeys (single auth), if someone steals your passkey database they can use it immediately. For all of the true measurable benefits that passkeys bring (not memorizable, higher entropy, automatic storage and use in a database) they are almost always used in a way that has this huge drawback: no 2FA.
This is not an issue with passkeys directly, it’s an issue with how services implement passkeys.
I think passkeys with single auth are fine because of how they end up being stored and managed.
If you use them via Windows, iOS, Android, or macOS, they are tied to the biometrics on your device. Someone has to steal your device and unlock it to get in. They have to have something you know (phone unlock password) and something you have (biometrics).
In a password manager case, trust is moved from the client device to the password manager itself. It is assumed that the password manager implements these things. For example, my 1Password needs to have both my password (something I know) and secret key or existing logged in device (effectively, something I have, as I don’t regularly type in my secret key as a password and don’t have it stored digitally except for within the password manager itself) to be logged in.
Your client device OS will not allow you to create a passkey without a local unlock PIN/password or biometric, and those local unlock methods do not traverse the Internet (they are handled with TPM/Secure Enclave).
I LOVE passkeys. That said, I store them in my password manager, which means anywhere I have access to my password manager, I can easily login via passkey. I can understand they would be a pain if I was often using new devices and did not have a password manager. I also admit it can increase the risk of lockout, but the sites I have passkeys for generally have recovery methods.
The only issue I've had is sometimes a website has poor support for my password manager, and I can't find a way to put in my passkey. That is very annoying. The benefits are worth that IMO - can't forget my passkey, can't phish my passkey, can't be hacked serverside. It's a clear upgrade to passwords
If you have to use passkeys, try KeePassXC and KeePassXC-Browser. I used them to set one up for Amazon a few days ago, as Amazon now forces passkeys as of this month, at least for my account. It was relatively painless.
> Maybe I am getting old but password+yubikey/webauthn was really top UX.
It most definitely isn't. Any 2nd factor that is not the device I am currently using (either a yubikey or my phone) has a non-zero chance of not being near me when I need it, leading to the constant question of "where the fuck did I put that darn thing", only to find out that the cat has decided to believe the yubikey is a mouse and tried to devour it, the phone's battery went dead...
Not sure this is what I meant. Password is still stored, along will all the keypass stuff. If you have the option to login with the keypass... or the password - possibly sending you a link (or code) to the email, in case the device/browser has not been seen, yet.
The creds they store hold no value. These creds only give access to their system anyway. They store the email address either way so the situation is no better but less convenient.
They hold no value precisely because they don't store them and send you a magic link! If they stored a recycled password or its hash, then it would be valuable.
I really wish I could block the repeated "Set up a passkey" nag by preventing my browser from advertising passkey capabilities. I don't understand why we can't have a Off switch on the client side.
I’m convinced that a lot of the passkey hate ultimately stems from the inconsistent and confusing flows that websites have implemented in the name of backwards compatibility with passwords. I have made some apps where passkeys are the only way to log in and it is such a lovely experience. It can be as simple as a single log in button by itself, with no intermediate pages or other UX. There doesn’t even have to be a form to fill out at all.
The problem of losing physical access to your passkeys is only really a problem if the site chooses to be strict. There can easily be a “Send a magic link” button where you type in your email. It’s the equivalent of “forgot password”. For most systems, it’s already accepted that your security is only as good as your email provider’s is. Passkeys make it straightforward to have an email-less model, but you always could have done the same thing with passwords. No one forced you to implement “forgot password”, it was simply a practical approach that was worth the security tradeoff.
People seem to assume that we should leave that functionality behind in the transition to passkeys but I’m not so sure. It certainly seems more practical than trying to get users to maintain physical backup keys.
The concern about exporting passkeys is valid but you can share via AirDrop. Doesn’t that work on Android now?
Try to give passkeys a chance. I really think the growing pains are worth it.
Nah, it's the transmission of the keys to Apple or Microsoft. We flatly rejected key escrow during the Clinton Administration, and I continue to reject it. And no, I absolutely do not trust their implementation of E2EE to mean there are no backdoors.
Are you aware that none of that is required when signing up for a site that supports passkeys?
I think there is some confusion here caused by sloppy use of terminology among FAANG and the standards groups. You’re right that, strictly speaking, Apple defined “passkeys” as synced credentials. And you’re also right to point out that, as a result, in order to consider them secure, you must trust Apple’s key storage and E2EE iCloud syncing, or the equivalent from other vendors. I wouldn’t blame you for being skeptical about synced credentials. The convenience may not be worth it for you.
However, crucially, synced credentials are just one type of FIDO2 credential. The other is a hardware-bound key from a “roaming” authenticator (aka a “security key”). These are never transmitted, never synced, and you can buy the security key hardware that generates and stores them from many different vendors, all of which are designed to be interoperable.
In other words, all passkeys are FIDO2, but not all FIDO2 are passkeys. Yet, when a website says it supports passkeys, it probably means it supports all FIDO2. And that’s because WebAuthn, the browser standard used to implement passkey registration and authentication on the web, supports all FIDO2 credentials, not just passkeys.
With WebAuthn (and most other systems), by default both platform authenticators (which would typically be synced, like you’re talking about, but not necessarily) and roaming authenticates (which would be typically be a USB security key, not synced) are allowed. I’ve occasionally stumbled upon sites that don’t allow platform authenticators, but I’ve never come across one that doesn’t allow roaming authenticators. It sounds like you want is the latter.
Apple could have avoided this mess by simply deciding that “passkeys” are the new name for “FIDO2 credentials” and then we could have synced passkeys and non-synced passkeys. But they apparently thought that was too confusing.
Ok, thanks for the explanation covering everything except the topic of my comment. And yes, I was aware. The point is, nobody (except those with a condescending PhD tone of voice) is aware of the loophole inherent in synchronizing passkeys.
I agree 100% i learned that my old school with whom I had linked to my windows computer and finished my degree with one day required passkeys rather than passwords on all devices. This force locked my windows PC back to passkey mode luckily I remember recovery account and got a passkey to work. But it took months to figure out why I had to use it. All the help board were said just click this button which was grayed out. Or set this register key which auto repopulated. It was an awful experience. I like my password as default
Ah yeah, Microsoft has this awful habit of just hiding the buttons for actions you don't have permission to do, which makes me feel like I'm being gaslit sometimes when a guide says 'there's a button right here' and there's not, and I've no idea if the button was just moved or if not, why it's not available (sometimes it's because I don't have permission, but sometimes it's because it's a different product with the same name and branding as a completely different product).
Passkeys match a very unique situation where I don't want to store anyone's email address, don't want them to type anything, generally want to store as little information as possible. Also don't want it to be easy for people to share/steal passwords/accounts, and prefer storing on the local device.
Windows still required entering a local PIN, sometimes 2-3 times. I think the account recovery didn't scale, though haven't really tested/explored with any real users :)
I like passkeys.
I dislike how websites vary the implementation of passkeys.
One thing Ethan misses: you don’t necessarily need one passkey per site. A single passkey protecting Google, Apple, Microsoft, GitHub, etc. can indirectly authenticate you to hundreds of sites via OAuth/OIDC (Sign in with…), while consuming only one resident credential on the hardware key per identity provider.
That makes the “hardware keys can’t store enough passkeys” argument much weaker in practice.
Passkeys lock you into a third-party provider ecosystem that you really should be trying hard to avoid getting locked into. They also add a quantum safety risk. Stay away.
I've resisted passkeys for some of the reasons listed. I use third-party password managers, they're device/system independent, and I can export the data when I want to. I don't see passkeys as a big advantage, or perhaps I should say the bigger advantage isn't really for the _user_.
Of course, at the rate we see security failures everywhere, I'm not entirely convinced writing your passwords on post-it notes wasn't such a bad idea after all.
Keepass2Android without network permissions saving the file to a folder monitored by Syncthing is pretty good though - it keeps responsibilities nicely separated.
I use passkeys, hardware ones, and I am very happy with it.
I don't understand why people dislike passkeys, they are the most secure system we could possibly do and I am also very happy that the major companies are accepting them.
It seems to me that people would prefer to be insecure and use something that is familiar and easy to understand, than be secure and have to do something different.
I find Passkeys are amazing once you accept they are not your only path in, just a much more convenient one. Have your accounts and totp with an authenticator set up, but add on every device you like a passkey to create a fast path.
Removes the need for syncing any passkeys, the risk of getting locked out, and the terrible support of 3rd party password managers providing passkeys
This blog post and also comment section are a tire fire of misunderstanding. Passkeys solve a couple crucial problems 99.99% of users face, including smart, technical ones who use password managers. They have great ergonomics. They do not obviate having some kind of recovery flow and are not intended to.
I'm was tempted to come in here and say "you're holding it wrong." But then I quickly realized that I had to spend weeks changing my behaviors and messing around with devices in order to get it to work correctly.
As someone who's OpSec puts swiss cheese to shame Passkey has been a godsend. My passwords are actually much better because of it.
This article touches on something I've been ruminating about the past few months - the lack of control users have over their own security posture.
Like many people, I use dozens of online applications a day, from banking through to childcare booking platforms to online shopping. With data breaches becoming ubiquitous and a common occurrence, providers are under pressure to secure their platforms.
This means they're all attempting to implement "best practice", with various degrees of maturity and efficacy.
The consequence of this is a huge degree of friction on a daily basis. Myriad authentication apps and schemes. Some using TOTP. Some using SMS 2FA. Some using push notifications through their own app. Some using magic links via email. Some with passwords, some without. Maintaining all these has become a significant administrative burden.
But the enforcement, and inability to opt out, means I have limited say in choosing NY security posture for each service. Some accounts I have are throwaways that I couldn't care less if they were compromised. Even with strong and secure passwords, I still need 2FA. Worse, those that I do want a strong security posture with often have a backup recovery scheme, such as magic links via SMS, that I deem inherently insecure. Yet I am expected to trust that the platform provider knows what is best for me.
As mentioned in the article, losing access to platforms has been a bigger issue for me than account compromise. For example, I had an old Twitter account I wanted to access once X took over. Although I had the password, they had implemented 2FA since the last time I logged in. Since In didn't have a current email on file with them, I couldn't receive the verification link and have now permanently lost access to that account. Providing that I had the (strong) password, that I was using the same static IP address I originally signed up with, and providing government identification was insufficient to regain control.
I'm a fan of passkeys. I now also use a Yubikey. But simple passwords still have their place and can be useful and secure I'd handled well on both sides.
My thinking is that Passkey is an extremely good and, in theory, extremely easy solution to security, authorization, and login issues. The problem is that Google, Apple, and Microsoft have done a just horrendous job, and made it suck as much as possible.
They didn't want to cooperate, and they wanted to make passkeys transferable within you cloud account, while not cooperating with anyone or anything else. The result was that you have no predictable and stable pattern/protocol/interface, or even general description, for how, for instance, a website connects to the passkey or even a hardware key, if you wanted it.
We basically have all the browsers, the operating systems, and the password managers, all fighting over who gets to store and present the passkey. And everybody assumes that they are the only one that exists and actively tries to fight the others is they can.
The basic technology is really good and could work well, but the large asshole tech firms focused on self-interest and walled gardens and made it insufferable.
I’m still terrified how normal people are going to navigate being locked out of their email account because their device that was their passkey is no longer accessible and there’s no backup solution to restore access.
I’ve similar issues even in a lower level with LastPass where it won’t even let you enter your two factor if it doesn’t recognize where you’re coming from but then you have to be connected to your email, but your email password is stored in LastPass. There is a real possibility of being locked out at all devices at the same time and not being able to get in to the first one.
I just had a very annoying interaction with the tailscale Android app:
It wanted me to log in for some reason even though it had worked fine for months. Login uses my Google log in.
When I try that, Google asks me for a hardware key to complete the login, even though it's my phone and I'm already logged in.
Eventually I figured out that if you select "log in using another device" and then click cancel when it brings up the qr code, you can select a push notification on "another device", which actually pops up on the same device. Do that once and it fails. Do it a second time and it succeeds.
> When storing passkeys in a password manager like Bitwardenor KeePassXC, you end up fighting the platform
Very odd. I use passkeys extensively with BitWarden and I love it to the point where it's my preferred way of securing things at this point.
The fact that the website presents the question to BitWarden in a structured way (what website, what username) means that I never fight with selecting the right account to get the password for (because I commonly have multiple accounts for a single site) and it generally makes the login flow much smoother.
The option pops up in the middle of a normal log-in flow. I'm guessing most non-techies don't know how it's implemented.
Oddly, some login flows display a normal user/pwd form, but you get the in-browser "use a passkey?" option/popup which further confuses matters.
Thankfully, me, wife, and all our parents are tech-savvy enough to use password managers, so the fallout from lost passkeys hasn't be an issue. But I certainly see how it would be an issue for anybody entering passwords from memory or similar.
> By design, you cannot create a backup of passkeys on a hardware key
In fact, I think it's technically possible. But it's true, as of today I don't think anybody supports it.
I was experimenting on solokeys with ios, in principle we could backup Passwords (the ios/mac app) into a solo key, space permitting, including passkeys, regular passwords and totp (not wifi passwords). I believe the same is for Android, but haven't tested yet. This is all experiments I've been doing on my own, there's nothing ready to be released.
That quote is referring to the mechanism for backing up passkeys that only exist on a hardware security key, which deliberately does not exist. Moving keys onto a security key is possible for some devices, but that is a deliberate compromise, as these devices are designed to generate their own keypairs and never leak secret key material (thus preventing backups).
I like the idea of passkeys. And ive been seeing better support for them. I use Bitwarden as a passkey manager and it mostly works across devices. What's irritating is when the provider messes up passkey integration.
As an example, recently Sony asked me to setup passkey. I did. But it skipped bitwarden somehow and went on my phone.
I tried to login to my Playstation account on the computer and it directed me to continue logging in on my phone. I did so and then the web client just said an error occurred.
In a corp environment, it is the business's problem when a user's passkey devices fails. In a personal environment, it is the user's problem. Specialized knowledge and preventive processes in the corp environment aren't present in the personal context, and saying "pretty please" to Google or Apple when something goes wrong is usually a waste of time. I 100% agree with TFA -- "damage expectation" is probably higher with passkeys.
That's why I just implanted my NFC passkeys. I've got one in my left hand and one in my right forearm. If I lose access to them, I have other, much larger problems.
I have passkeys on literally everything that will support them and store them in 1Password. I can access them on my laptop, phone, desktop without issue.
It’s basically server side of passkeys as boring as possible: self-hosted Go binary, Postgres, REST API, and no requirement to move users into another IAM system.
Would be interested in criticism from the passkey skeptics here.
I've not yet encountered a site which has even suggested I use something like a passkey. Under the assumption that you're doing the Right Thing, and avoid using Apple, Alphabet and Microsoft's services - this is a non-issue. In fact, even if you use their non-login-requiring services (e.g. YouTube, Bing, Google search) - again no passkeys in your life.
I hated them at first, but since I am already dependent on iCloud Keychain to manage my passwords, I just figured there is not really any additional risk. I just make sure I will always have multiple, healthy devices, which are always patched, charged, and sync'ed. And don't put them all in the same physical location at one time.
I use passkeys, but the UI seems less user-friendly than SSH which is conceptually similar. When I SSH into a machine that has me in authorized_keys, it just logs me in. Passkeys are like 8 clicks telling the site and browser repeatedly that I want to use the damn passkey. Can't it be "remember me forever"?
The page forces a jump to top when in reader mode in Safari on my iPhone. Hostile. Wanted to read the article, but left out of annoyance.
Yeah, but I agree with the headline. I don’t want to be tricked into enabling this “feature” that I find burdensome, but some sites try hard to coerce enabling it. The modern web is a bummer.
heya! sorry about that, I don't usually have an iPhone on me to test updates to my site so I must've broken something in its reader mode. I'll be borrowing one tomorrow and try figure out what's causing this :)
Passkeys in bitwarden have been working pretty well for me overall. Website support is still spotty. Sometimes passkey logins won’t work, or other times the website will still ask for a “third” factor code.
For less tech savvy folks, passkeys are a godsend since they don’t have to remember passwords or fish around for codes
One point that Google wants to own all your data but have the power to ban you with a faulty ML algorithm with no recourse. False banning that affects someone's normal life must be punished if the service provider tries to lock you in. You and lock people in or have power to arbitrarily ban them, not both
> When storing passkeys in a password manager like Bitwardenor KeePassXC, you end up fighting the platform
I must say it's pretty amazing how well-integrated is Bitwarden with iOS now, passkeys, password generation, everything. I have disabled Apple passwords manager, and Bitwarden feels like the native solution.
Passkeys suck because only the wealthiest 5% of the world is all-in on one ecosystem (such as Apple) while the remaining 95% uses a Windows laptop, an Android phone and (for the top 5-35%ish) maybe an iPad. All of these OSes push hard to get you to store your passkeys with THEM so it ends up a shitshow with everything scattered everywhere.
And why do the OSes push for this so hard? Because the goal of the execs is lock-in and control. And their lackeys here on HN who implement this stuff and their families are the 1% who are all-in on one ecosystem so they arrogantly believe "this all works great and the masses are just too stupid to get it".
Just a small clarification, attackers can definitely steal a passkey from your key store and use it if your corporate settings are incorrect IE. device attestation is turned off.
My company has already responded to multiple breaches where this has been what quickly follows an initial intrusion.
We added passkey support to devices for convenience, but I feel like it is a big part of what has made them so confusing. The mental model of a hardware security key is _so much_ more familiar and intuitive.
(But you still can’t “copy” a key, which is unfortunate).
I feel like we're solving one security problem while creating another. Passkeys make phishing much harder, but putting so much trust in Apple, Google or a password manager for account recovery creates a pretty significant single point of failure.
What happens with the Fifth Amendment when a platform imposes passkeys and you don't have a device with a pin (if that even possible to combine them) ?. Given you don't see the password, then you can't memorize it.
every single website i use that supports passkeys prompts me to save a passkey in pw manager every single time i login. not specific to the password manager or browser really, and existing do not matter. every chrome based browser cant keep track. makes it look like a totally garbage, amateur implementation getting prompts for saving a new passkey constantly
I wouldn't mind it if all the services stop working properly when you use a Passkey but still want to use your other stuff like password and 2fa through app...
GitHub breaks with this, PayPal breaks with this...
I absolutely hate them and avoid them everywhere I can. I'm not bound to a single device or I don't want to get bound to some, and some pages quit your option with a normal password login after setting up a passkey. Absolutely frustrating.
Passkeys are really an abdication of cyber security responsibility by the vendor. Offload everything onto the consumer, and you have plausible deniability for anything that happens.
Surprised to see so much hate towards passkeys. I absolutely love them when I can use them with Bitwarden and my own SSO.
Sucks when I am limited to hardware tokens like yubikeys.
I am even more surprised about the multiple down-votes for this comment just because I like some feature. Must be a bunch of grumpy old keyboard warriors on this thread. 0__o
Personally I love passkeys and think it’s not deployed enough. It works great (for me anyways!) and it is SO MUCH better than “login with email” that is everywhere now.
Well I like them, as an option. I offer using passkeys and email interchangeably; if you lose one you can recover with the other. Passwords, SMS, TOTP are out for me.
Very much in agreement with this post. They are secure, they also cause me great fear of getting locked out of my own accounts if my hard drive crashes.
I didn't like the passkeys that were handled by Google and only worked on my phone. But now that most of them support bitwarden they are really convenient.
Devices that break or get lost, and then either the user had password authentication activated all the time anyway in addition to the passkey, or they have the classic "mother's maiden name" recovery path, or they get locked out of their account.
Brilliant security: a highly secure high-tech shiny front door that can randomly fail to open, so you still need the low-tech back door, which is the one potential thieves will use.
Mind you, it can work if the back door is old but sturdy (basically, for a bank that will ask for KYC authentication, or in the worst case you can set foot in the brick-and-mortar branch showing your face and ID and ask for access) but for pretty much every other service it introduces risks for very little or no gain.
> Although operating systems have recently introduced APIs [...] for third-party tools to hook into, the experience remains fragmented and lacks the decades of UX polish towards password autofill. Autofill outside the browser and inside native applications remains especially inconsistent.
I disagree. It is just a wrong statement. Passkeys actually eliminate the flaky autofill part where password managers have to parse input fields. Ever since I learnt about KeePassXC and KeePassDx, I've tried to migrate as much of my accounts to passkeys. The experience is wonderful and KeePass allows me to see the private key behind the passkey - yes, yes, yes!
Yes, that is what everyone keeps complaining about and the people who insist passkeys are the best continue to loudly and totally ignore.
The repeated response to "I lost the passkey, what now?" is apathy. It is your fault, you should have done better, eat it loser.
Because companies built passkeys for their own needs, not for users. In a managed device setting, there is a response: You go to IT and get provisioned new credentials. These companies don't care that you get fucked because they just don't care about your needs at all.
What benefit does that give you? Passkeys cannot be moved, by design. So for the website, recieving the same one means you're talking to the same device, always.
The purpose of rotating passwords is to cycle out potentially compromised ones, due to phishing attacks, keyloggers, shoulder snoops, etc. But those cannot exist with a passkey.
Doesn’t this mean that a compromised device with passkeys on it is worse than a compromised password since the passkeys can’t be rotated? I feel like the answer is obvious so there must be another angle I’m missing
Passkeys can be rotated, of course. The question was whether they should be rotated on a regular basis.
What kind of compromise are we talking about? Was the device stolen? Then yeah, you need to rotate passkeys (and all your passwords, and remotely cancel all your live sessions, none of which is new).
Was the device hacked from afar and the data read off of it? The passkey is probably fine. You can rotate it if you want to, it's not a bad idea, I probably would to be certain, but you're not pwnd even if a bad guy got a shell for a while, heck even if they got a root shell.
I understood the question to be "should passkeys be rotated regularly" to which the answer is probably no because there's not really a compromise mechanism that periodic rotation defends against as far as I know.
Rotation defends against secrets that leak through normal use and without your knowledge, like a password entered into a phishing page or snooped over your shoulder or cracked from a breached hash. Passkeys aren't vulnerable to those things because they never travel over a network, are never seen by the server, are never seen by their own users.
You change the locks on your house when a key goes missing, or is known to be in the hands of somebody you don't want getting in, it's not something you do every three months just in case. Same with passkeys.
using them with 1password has been pretty effortless. 'want to add the passkey' sure why not. 'want to use the passkey?' sure why not. for me it works across devices/os/platform so not sure what the big gripe is tbh.
To guard against lockout, you need to be able to log in from multiple devices. But you don’t need to copy passkeys around to do that! Instead, generate a new one for each device. This is similar to setting up ssh by copying public keys, not private keys.
(Or since syncing passkeys usually works within ecosystems, you might just need a passkey per OS.)
I don't like attestation. That is dangerous to user freedom. I don't mind other parts of this technology.
Attestation already destroyed user freedom in mobile app ecosystem. You can't just implement your version of some mobile banking app or whatever just by using original app's API, because dark overlords of gated app comunities allowed app authors to prevent this on OS level by giving them attestation tools.
I just don’t get how passkeys are supposed to be an improvement.
On any site where I create them the login experience gets worse. Sometimes I get a QR code to scan (terrible, almost never works too). Sometimes I am offered to login with passkey which I have and it doesn’t work. Almost always I need to fallback to password and it just sucks.
I hate passkeys. I wish there was a checkbox somewhere to tell all websites that I never want to use them.
I don’t get the hate for passkeys. It feels like a state sponsored attack at a reasonable (not perfect) tech.
Locked out of device? You should use a password manager which you can still log into again on a new device.
Want to log into a service on a device you don’t own? Log into by scanning a QR code with your passkey (windows offers this standard when you keep a passkey on a different device for example).
I don't like passkeys either (I use a password manager anyway, and long secure unique passwords), but I understand the need. But yeah it really annoys me when every website wants to give me a passkey, or wants me to use a passkey, instead of just taking me to a page where I can enter my novel-length password.
I hate them, mostly because I am forced to use them.
They provide crappy usability, they're expensive, they're easy to lose, you can't use the physical keys when doing remote desktop access.
My job requires me to use them. I use only for the job and nothing else. For sites requiring 2FA, I use TOTP (time-based one time passwords) from KeePassXC.
Microsoft is especially poorly prepared for this - Often if you have a passkey, it will CONTINUE To ask you to create a passkey (a new and different one), and it may save it in a different place, which is infuriating.
Strong password + MFA is the way, and I don't see that changing.
I also despise that in between OSes, browsers and certain sites I am having to close/cancel/skip sometimes three or even four dialogs to say "No, I'm not interested in changing my login method to passkey" (PayPal is one example).
I had to setup a Passkey recently and wanted to store it in 1Password and the experience was quite absurd.
I don't know who designed this or who thinks these are acceptable affordances, but it seem to be part of the same disingenuous push that's behind passkeys in general.
What is the point? As long as you (the service) hash passwords securely, and the users use random passwords with a password manager, you are fine. A password is far easier to type onto another computer or a diffrent web browser.
I take passkeys over the unbearable cargo cult that follows LLM companies, namely companies' newly found obsession to "sign in via email".
Ideally optionally followed by a 2FA (naturally, via text, delivered straight to my Mac, even further diluting the questionable security of the whole exercise) and naturally, to be repeated every 2 days or so, since "stay logged in" is the biggest lie after "I've read and accepted the ToS".
Your phone (which is probably what, 80% of relevant traffic these days?) likely has a perfectly fine password manager built in. This "sign in via email" trend must be every scammer and phishers biggest dream come true...
Almost everything has supported email-based password reset since 90's for all the problems it entails.
I am looking at a new project that uses magic links sent by texts. I have been there and done that with authentication systems and that's good enough for a low stakes ludic activity.
SSH keys are much easier to use and understand. Heck, passkeys could have just been a ZIP file holding a key-pair instead of whatever hostile design by committee we ended up with.
If they actually worked like SSH keys that would solve some of the problems with them. (like keeping a backup that you can still enroll into new accounts without it being present).
Related: the UX is currently terrible. Every time I go to a website that has passkey flow, I'm presented with:
- MacOS native UI; which I cancel; then I see
- Bitwarden UI; which I cancel; then I see
- Chrome UI; which I cancel;
I find it annoying that so many apps and websites push passkeys onto users without informing them the basics of passkeys, including how it's associated with those specific devices/password managers or how to prepare in case a device is lost. Meanwhile as a user who uses a password manager to generate a different password for every site and has autofill enabled everywhere, passkeys barely improve my life if not making things more confusing.
I hate that there's no accepted definition whether passkeys should be considered MFA or not. As a result, some sites treat it as MFA and you just provide passkey and you're in, which I like. Other sites still ask for a second factor after I provide a passkey which I think is stupid. At that point, it's simply another password I can't remember.
I should not be prompted for a second factor after I log in with a passkey.
Passkeys work nicely, and I'll use them, in cases where I want decent security, but I don't consider them the "Philosopher's Stone" of regular end-user security. I think they are still a bit too "fiddly" for your average Joe[line].
Username and password was a predictable flow. Passkeys are just a small component in the modern obstacle race of logging in. Every few months a new credential or ritual to access your own resources .
These are the four flaws with Passkeys I've found after implementing them on our website. I actually like them now. But, It made me discover why people dislike them. The vast majority of problems are _the way websites implement them_ and _the way password managers today_ work.
Website problems:
* First big problem: you try to kludge them as an "add-on" to a password or SMS "2fa". Just rip the band aide off and let people go 100% passkey by default. It's actually really easy for users. We do a push at the end of their onboarding flow and have a 95% conversion. Users love it and its seamless.
* Don't make people enter a username. Just have a "login with passkey" button first, and thats it. If the HIPPO in your organizations insists a username-password still be available, make the user navigate to a secondary page first to do so. Make the passkey the first-class citizen.
Password Manager problems:
* Google, Apple, Microsoft are trying to lock people in to proprietary password managers. Microsoft's password manager, plus their "microsoft account" experience is a steaming pile of shit. The key here would be portability. An export format exists for the public key (thats how enrollment works): It's a but of digits in ANSI X9.62 format. Not hard. The private key would be an unbelievably simple export.
Protocol problems, and I'm happy to be wrong here:
* The client does not sign the server issued nonce (aka the 'challenge') during the authentication flow. This is kinda weird IMHO. Technically, yes it is secure, but it relies solely on the TLS channel heuristics. It'd be much better to have the client prove the signature on enrollment as layered security.
To address the author fears on attestation: This is a real threat to users... imagine a website "only accepting passkeys from OUR password manager". Luckily, Apple has done us all a favor and outright killed that part of the protocol by refusing to send this required fields there, protecting all users.
Overall, you should use them. We need one tiny change to the protocol and better password managers.
I don't know much about passkeys, I have never implemented them. I once tried to find out more about them but all I could see is "you're going to regret using this one day".
I have said before, I'm personally not interested using "Something I have"/"device bound" as an authentication factor. I'm also not interested in the sync "workarounds" that store keys in the cloud.
People have replied it's possible to extract the private key, but it's not clear to me that that's usable (maybe it is I don't know). It's certainly not in line with what passkey devs want people to do and not do, so I'm not interested in "fighting" against the "flow" so to speak.
I'm happy with TOTP, as I can manage and use the codes where I want, under my control.
> Both Apple and Google want your identity anchored to their operating systems. The “happy path” on their devices is to use their synced passkey management tied to your Apple or Google account.
<sarcasm>On the plus side, this way passkeys can also be tied to age/identity verification.</sarcasm>
I went in expecting yet another screed about how passkeys were not issued by RMS in a FOSS encyclical, and therefore not only were they insecure, but they were also a morally bankrupt abomination. I was pleasantly surprised to read an actual thoughtful critique, albeit one I largely disagree with.
The author's assertion that the greatest risk to an individual is account lockout versus phishing or password harvesting is just not grounded in reality. I get phishing emails and SMSs daily. The criminal ecosystem running these campaigns is extremely active already and set to become even more so with LLMs. These campaigns are by far the biggest threat to normies.
Whereas account lockout happens most often with multiple failed password entries, which passkeys completely eliminate. I just don't know where this risk evaluation comes from.
The author also points out that even with passkeys, if you're able to also log in with e.g. security questions, you still have a much weaker security footprint for that account. This is true, but it's also true of a TOTP second factor. So I'm not sure what the criticism is here.
The exportability argument is a real weakness and something I'd like to see addressed. Passkeys don't have an equivalent for backup TOTP codes that you can just write down somewhere or trivially store yourself. But it probably wasn't in v1 because the people who designed passkeys figured that websites would not go all in on them immediately and would preserve other authentication methods, which is exactly what's happened.
Lots of people like them, but it's clear from the complaints there's another large group for whom they are problematic. Enthusiasts are going to have to actually address those issues if they want adoption.
I've seen it. Websites are pretty inconsistent about the flow but I've had a few just try to install a passkey when I log in (amazon does it. Paypal seems to do it but only try to use it on the same browser it was installed on, even if it's synced through a password manager, just to be different. The more reasonably ones have a 'log in with passkey' button but this isn't universal. Microsoft seems to just nag the user on login periodically in their classic 'Yes/Ask me again later' style of 'consent'). You can, if you're paying attention, avoid it actually happening, but the average user isn't going to notice until they suddenly can't log in because they're on a different device. You can see some advocates are pretty vocal about making them mandatory as well.
Every time I login to certain sites (like my health insurance, for one) I get a passkey prompt (system dialog) with no way to keyboard-dismiss, so I'm forced to move my hand over to the mouse and figure out which of three poorly-named buttons to press to get on with the login and ignore the passkey.
It's a minor inconvenience, but happens so regularly I hate it. It also stops the login flow until I dismiss the prompt, which is also annoying as I could've already gotten to the page I wanted to get to in the time it took to dismiss the dialog.
Passkeys work great with Bitwarden too. With it being set up on all of my devices I actually often prefer the passkey experience. Too many people depend on OS password managers or even the ones built into their browsers.
For me passkeys work wonderfully synced in Bitwarden on Windows, Linux, and Android.
I have no idea what this article trying to say, except some negative opinion that should IMO be ignored.
The article was clear and reflects my own opinions:
If you use an untrusted machine, you either revert to the least secure backup method (your master password in Bitwarden) or don't log in.
If your phone is your trusted device and becomes lost/stolen and then replaced, you revert to the least secure backup method e.g. password, security questions, or even waiting to be manually verified. This can be problematic if your online bank requires 2FA so you can purchase the replacement phone.
The QR + Bluetooth thing sounds dumb as hell.
Kiwi Browser doesn't support passkeys even with Bitwarden on my device. I have to choose between an inferior (for my needs) browser or passkeys.
-----
Rather than passkeys, which always rely on a trusted device, my preference is, "I use a password manager and site-specific generated passwords, and when I try to log in with only a password on your site, send me an email (whether pass or fail), plus never require 2FA except for banking and perhaps to change email/password"
It's unlikely I'll lose access to email notifications at the same time someone tries logging in with a phished password (except, obviously, my email password, which should only be changeable with 2FA) unless I am specifically physically targeted or astonishingly unlucky.
If someone uses a fake website or other MITM method to grab my credentials, I'll be fine because I'll get the "hey PennRobotics you logged in to crabcakes.com just now from a iPhone" message and then immediately triage that unexpected situation.
If I need to log in to a website in private mode or on a different device, it takes an extra 30 seconds to log in to my password manager plus no device dependency.
-----
The passkey problem for me? You need some hardware or else it's glorified 2FA or even (in the case of the Paypal app) 1FA applied twice, and as soon as you lose EITHER the hardware or the "what you are/what you have" part of 2FA you enter a world of trouble.
Also, ToS lockouts happen. When Google terminates your account (for any variety of imaginative or realistic reasons) there isn't really any method to use or export your passkeys anymore.
As someone who uses a single password manager on my computer and phone, I don't see the problem with passkeys. I use Safari on both and I never even had to "set up" anything.
I can see why they would be problematic for people who otherwise live life with a single love2025 password though.
Imagine you lose your computer and phone. How do you recover your digital accounts? This happens every day to someone. The most common scenario being a house fire or robbery.
Receiving an email at your backup email address? Getting a text message? It’s whatever you have decided to set up in your account, the same as with a password.
I think the point with a passkey is that those very loose backup methods are required, since just knowing the password is not a thing. Everyone gets a new phone and is at risk of the previous one being unavailable. So passkeys mean that there's no way to deal with that reality, and also be truly secure.
I don’t know any of my passwords and haven’t for a decade, so passkeys are no different in that respect.
If the worry is your phone getting lost then use a password manager that syncs to the cloud and log in with the same passkey using another device. I just got a new iPhone and logged into a bunch of things on-device using synced passkeys. It worked just fine.
Every conversation about this seems to involve someone asserting that improving upon passwords in any way at all is unacceptable unless the solution is perfect in every possible way, with the goalposts constantly moving.
The article asserts with little proof that lockout risk is a big problem. But consumer sites themselves basically 100% of the time have a recovery path that amounts to a SMS code or emailed code.
The only part that is very persuasive is the part about storing your passkeys with Google or Apple integrations, and what happens if they ban your account. But the same argument would apply if you’re only storing your passwords in a Google or Apple password manager.
I use passkeys and I always store them in a password manager I control - but usually I also store another one in the OS on Windows, Apple, and Google. Best of all worlds. Also, I appreciate that idiots aren’t forcing me to “change my passkeys” every 90 months like they STILL do with passwords!
I know I can't speak for everyone, but I at least don't see the passkey as even pretending to solve that.
There frankly is no solution for the problem you are talking about, because the 'average person' is extremely disorganized and barely understands anything about security or authentication, let alone how to manage their passwords/secrets effectively. And it appears consumers "don't want" that... arguably for good reason. We accept a tiny chance of being hacked in exchange for knowing that if our house burns down with all our devices in it, we won't be locked out of an Apple/Google account for life, even if we weren't wise enough to keep a DVD full of exported passkeys or lists of recovery codes in a safe remote location.
Passkeys are in practice for one thing and one thing only (and they're very good at it!): Replacing passwords with something that unlike passwords:
1. The secret doesn't need to travel anywhere so it can't be stolen at authentication time
2. Uniform and large entropy not bounded by memorability, creativity, or misguided dumbass website owners ("Please use THESE AND ONLY THESE 'special' characters: ! @ $ % _ ")
3. Impossible to be improperly reused
4. Each device's secret is independently revocable.
5. Extremely difficult to 'phish' on a fake website.
Even if we don't fix the "analog hole" so to speak where you can either SMS-reset or socially-engineer someone into resetting it, if we could kill passwords globally and replace with Passkeys, it would be probably the biggest win for security. I'd challenge anyone to name a better single thing we could do.
> A combination of randomly generated passwords stored inside a third-party password manager, paired with an independent TOTP app, gives control to the user without giving up the flexibility of plain text.
No grandma, don’t use the unphishable one-click passkey setup that syncs across all your devices. Instead, install a third-party password manager (no, no, not the one built in to your device or browser), then another TOTP app on your phone. It’s slower and more susceptible to phishing, but uhhh, what if you’re among the one in a million people that has their Google or Apple account wrongly banned?
Infosec for 15 years, and I do not want passkeys either. Anything that attaches itself to hardware is susceptible to loss. Anything that attaches itself to hardware makes it harder to use services from a new device.
At some layer you have be able to access your services with password/totp if only for recovery. Passkeys add a layer for minimum benefit, in my opinion.
Yes, push based totp and passkeys are more phish proof but for non techies, managing them is its own job.
Yes, there are several ways. You can use Google password manager on your MacBook. I believe 1Password and Bitwarden support this too. You can also use the Android phone itself as a passkey device with the QR code flow.
The UX is obviously a lot smoother if you have an iPhone and use iCloud keychain for everything, but that’s not an uncommon setup.
Passkeys do marginally improve security against MITM and phishing attacks, but they are primarily for protecting the lowest common denominator from themselves: people who re-use passwords and/or don't use a password manager.
If you use multiple devices throughout the day, registering passkeys in all of these systems becomes a big headache with O(m*n) complexity, so putting the passkeys in a password manager is the only realistic solution. But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.
The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for. I've accidentally set up passkeys just by clicking an okay button a few times in the past and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
> The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for.
My irritation is that I know what it is, and I've said no thanks many times, but I'm still asked regularly by the likes of Amazon, and they usually pick a time when I'm trying to order something quick¹. It is one of the growing number of things in life that simply have no “no” option, it is always “yes or later” - I wouldn't mind so much if “later” meant “I know the option exists, I'll ask for it if I change my mind, don't bother me again otherwise”. Call me cynical, but if companies are trying to nag me into something I very much doubt the main benefit is mine. I'm sure there are many people out there who go along with it simply because they are sick of being asked repeatedly.
I also don't see the real benefit with the way things are often implemented anyway. When the credential recovery process is sending a magic email or text, making SMTP or SMS the weak link of the chain just as it often is for passwords so I'd be giving up my preferred workflows for no better security.
----
[1] A short while ago I actually ordered from somewhere else because of this, bitter twit that I am. “I wonder if I can get this almost certainly drop-shipped item on next day delivery via Prime?”, [goes to Amazon to check], [get passkey prompt], “sod it, I'll go back to the original place”.
I dropped Amazon entirely a couple years ago because they didn't provide any way at all to separate my credit card from my kid's Fire tablet and I didn't want to be on the hook for thousands in charges because he pushed the wrong button. It's remarkably easy! It has made basically no change to my life except that I'm a little smug about not using Amazon.
What do you use instead? My main reason for using Amazon is the shipping which no one else can come close to
Same or next day shipping on most things I order is wild, when something goes beyond a 2-3 days on Amazon it even feels odd
And the “do you actually need the item/s that fast” isn’t the response I am looking for
Target/Walmart/BestBuy. They both have fast shipping options as well as store pickup. Sometimes (if you live somewhere more rural) they have _faster_ shipping times than Amazon.
I'm not in the US, but friends there tell me that Home Depot routinely delivers from the local store within a few hours.
(Here, unfortunately, their web site is useless crap.)
Walmart / Home Depot / Lowes / Kroger are generally going to beat Amazon on quickest delivery for most people for most items, if they want to, by virtue of their local brick and mortar footprint.
One reason I imagine Amazon pushed so hard for short delivery times was knowing eventually their legacy peers would leverage this against them.
Not to mention a long delivery time gives people more opportunity to simply go to the store and get something, while they’re out running other errands.
I live in a well populated suburban area. If I’m willing to actually leave my house, I can get most things much faster than Amazon can deliver them. This also helps keep those local businesses running, so shipping doesn’t become the only option in the future.
Shop.App doesn't have everything, but they do have a lot and many merchants have fast shipping options. I always try to search them and Newegg before trying Amazon.
Newegg marketplace is a funny place. Not only many items are more expensive than elsewhere, I had my orders delivered literally in Amazon or Walmart packaging. There are genuine merchants that made a choice to work with Newegg but there are many resellers from other stores as well.
Home Depot/Lowes often have faster delivery than Amazon (like literally delivered in a few hours or next day morning).
I live in the country. Amazon takes days to ship out here, though sometimes it has 1-2 day. Walmart has same day shipping (not delivery, regular shipping) and is cheaper or comparable to Amazon.
Could you create a separate account for the tablet without that credit card? Just curious.
but then how do you pay for things if/when you want to buy the little one something?
you either add the card then remove it, get a separate card, or find a way to use credits somehow -- but in the case of the latter two, Junior could still slam a few buttons and eat up all available funds on that card -- just without the impact of your regular card.
This is something that Apple really got right. My kids can initiate any kind of purchase they want (At least, those that are allowed based on Screen Time controls) but every purchase stops and waits for approval from me or my wife. Even if the item is free. No faffing about with credits, or extra cards, or setting limits.
privacy.com lets you generate credit card numbers on the fly
Just use a bank with a decent service (like Revolut), create a separate card number for your kid (10s within the bank app), where you put more money when needed and can easily put the number on hold or activate it whenever you please.
Like this Revolut?
https://cybernews.com/security/revolut-data-breach-75-millio...
> After the publication went live, Revolut reassured that the review is still ongoing. "We have so far still found no indications of any breach."
> "We have checked the user and card identifiers contained in the alleged records against our systems, and none of them correspond to valid or genuine Revolut identifiers," the spokesperson said.
A bank that cannot be used in the browser has no decent service.
The parent had a practical problem. I told him what kind of simple banking feature would easily solve it. I also mentioned a bank, which has it for sure.
For sure, this feature is not a Revolut-exclusive. Plata from Mexico should also have this and much more, from what I have read.
If American/European banks don't have such a simple feature, this speaks volumes about them.
Your comment has a vibe of "a bank that doesn't have a local office has no decent service". To each their own, I guess.
>I also mentioned a bank
if you're not in the US. revolut in the US is a fintech group with a bunch of bank partners.
I mean, you can gift things when you purchase them, not sure why that can't be a way. But I still agree it's silly to have the customers find work arounds.
I think this is the biggest reason why these category of discussion happens in the first place, there is a gap between what technology is good for, whats its ideal for and then the products motivation to push it on to the user assuming it would give a good name to the company.
Passkeys are one of the few protocols that supports against phishing (Accidentally giving away your credential to some rough site) so it has its benefits and more so for enterprise users.
It becomes challenging and is ill suited when its pushed to general public. A middle ground could have been to give it as an option to user instead of forcing it on the user. For some reason its not cool enough.
From a company's perspective
IMO it’s well-suited to the general public!
What is the average person’s threat model? Re-using passwords.
What is their most common annoyance? They forget their passwords.
Built-in password managers are great for this. But they’re not universal (e.g. I believe using Apple Passwords on Mac doesn’t carry over to Android.)
Passkeys are amazing. They’re basically magic to the average person. No typing passwords; no remembering; simply vibing, securely.
I don’t think people are regularly logging in to a huge number of accounts on other devices. Maybe they are! I doubt it.
> What is the average person’s threat model? Re-using passwords.
Wrong.
As article points out, it's not having access to their account.
Followed by not being able to easily delegate access to their account to a trusted third party (like a spouse, a friend).
Password reuse addresses the first problem, however imperfectly. Ability to share password over any channel, including analog, addresses the second.
Passkeys defeat both.
Account recovery works the same with passkeys as with passwords. You click “I forgot/lost my passkey” and get a link sent you via email that lets you create a new one.
Passkeys can also be shared with other people like spouses or friends, just like passwords.
> Passkeys can also be shared with other people like spouses or friends, just like passwords.
How? They're literally designed to not be, because they're trying to prevent phishing, and you cannot in general case distinguish phishing from legitimate delegation of authority.
> Account recovery works the same with passkeys as with passwords … get a link sent you via email
Making the email account, an often attacked resource that is always online, a single point of failure. I don't mind relatively unimportant accounts being that weak, for instance where the only reason to have an account at all is to separate your preferences from someone else's, and you don't actually care about security, but for accounts where there is significant PII or payment details or other sensitive information it is a terrible idea.
A second problem with this is that for many their email account is the same as their account where their passkeys are backed up. What if you have lost your passkey due to Google locking you out for no readily apparent reason and you don't have the online influence needed to get them to take you seriously (instead being trapped in the support bot loop)?
I still run my own mail server, and if I didn't my important mail accounts wouldn't be with someone like Google (I do have a gmail address, but that account is only really used for testing other accounts when needed), so that isn't a problem for me, but most people can't be bothered with that faf¹ so usually end up with one of the big providers.
--------
[1] It isn't actually that much faf², until those occasions when it is³, but more faf than most people care for, especially those that don't enjoy tinkering with technical matters.
[2] Just quietly ticking over as long as I remember to regularly verify it is patched up-to-date, and keep an eye out for zero-day issues concerning the parts involved
[3] When there is a deliverability problem, where I host it has problems so I need to make sure the backup is synced and then switch over to it, when there is a relevant zero-day and I have to rush a patch in (or take other remedial action until a fix is available) then investigate to make sure I wasn't quietly affected, etc.
> Account recovery works the same with ...
Huh, that is a really funny way to spell "the primary login method used by every not-tech-savvy person I have ever met before".
This would explain why so many places have been starting to force me to log in with an email instead of a password.
Oh right, I started to notice it too - couple non-tech people around me seem to treat "password reset" as default login flow, and definitely don't complain as much about auth flows as the rest.
I guess that's one effective way to cope with security industry bullshit.
>You click “I forgot/lost my passkey” and get a link sent you via email that lets you create a new one
I don't trust my email provider.
Woah. Why not get a better email provider?
And now you have to log into your email with a Passkey that probably you lost at the same time you lost your Passkey to the original site (e.g. lost or stolen device).
If you are not using Passkeys for your email (and the site supports that type of account recovery), then you still have only the security of passwords, just with additional steps.
Well, it puts people in a bind. The current status quo of TOTP 2FA with recovery codes is bad, but it's probably the best we have - because applying passkeys to your primary e-mail is beyond stupid at this point, it's putting your digital life in mortal peril.
I guess it really depends on how one choses to define general public, probably an assumption has been made that everyone has their own personal device.
> Built-in password managers are great for this. But they’re not universal (e.g. I believe using Apple Passwords on Mac doesn’t carry over to Android.
1.Only security keys (single device credentials) are what you can use across the device not the regular platform based one
2.Browser based password managers do provide you with that interoperability across the platforms and in fact the password manager as an supported passkey authenticator allows you do the same
> Passkeys are amazing. They’re basically magic to the average person.
Passkeys are crap. They are just random password prompts to give a false sense of security.
> My irritation is that I know what it is, and I've said no thanks many times, but I'm still asked regularly by the likes of Amazon
The people responsible show a distinct lack of understanding when it comes to consent.
Silicon Valley has no concept of consent and boundaries. If computing was a night club, "Silicon Valley" is the guy who goes up to every woman saying "Want to dance? [Yes or Maybe Later]?"
I don't think you carried on the analogy far enough.
>Want to dance? [Yes or Maybe Later]?, also drink this [Yes]"
A better analogy would be slipping something into her drink whilst handing her a 12-page stapled terms of service agreement in which she unknowingly gives full consent.
Meta: As you see the anal box as already been checked with unerasable ink.
> The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for.
Gf just logged in to hotmail without knowing her password because of a popup. I tried to explain but there was no understanding to be had.
This is how the world works. You either understand it or suffer it unknowingly.
Amazon and PayPal are horrible for this. Clicking out of the dialogs and modals to actually get logged in? (Shout out to PayPal for a dark pattern that implies "continue to login" but is actually "continue to set up PassKeys", and you actually need to "cancel" to actually login).
> by the likes of Amazon, and they usually pick a time when I'm trying to order something quick
they have an algorithm that can predict the likeliest moment you'll not see or panic-hit the "ok" button in haste
I think it is simpler than that: they ask irritatingly often, and I'm often looking quickly to see if I can get something on next-day delivery, so the two factors coincide.
"if companies are trying to nag me into something I very much doubt the main benefit is mine."
Bingo.
Amazon does benefit from increased account security; they don't have to refund non-fraudulent orders after all. For most people, a passkey is genuinely more secure.
What about availability? The article is precisely about that.
My MIL setup a passkey accidentally on her Google account and now has no idea where it is. Removing it now requires her password which she’s also forgotten. But now for some reason on Google I can’t initiate any type of forgot your password flow because of how Google sets up things and I have zero clue where she stored the passkey.
Ran into the same issue with my dad the other day. Has a passkey set up on his Google account. Bear in mind that he doesn’t know what a passkey is, so Google obviously sent him through a pattern at one point to get him to create one.
He didn’t have access to it the other day and we needed access to his account. He didn’t remember his password, and we were unable to reset it because you need the passkey! No other options to authenticate for a reset were available.
Add in the fact that I was trying to help him with this by long distance call and you can imagine the frustration.
As someone with elderly parents, the Googles and the Microsofts of the world really don't seem to give a shit about the elderly anymore, if they ever did. Random UI updates and workflow changes with no announcements, thinking they're "intuitive."
One of these days the product managers who push these things thinking "oh, it's easy, you just . . ." are either going to be explaining it to confused Mom or Dad, or they're going to be elderly and irritated themselves. Until then I hope they stub their toe or step on random Legos regularly.
I'm not even elderly but I would really like an e-mail client with a stable UI. I used to like Apple Mail but it's been a buggy mess since Catalina. It doesn't even sort or search mail reliably any more. It's basically a trope at this point but a robot-rewrite-in-Rust seems inevitable at this point.
A while ago I helped an elderly relative migrate off off a copy of Eudora that they'd been using for many years. (To Thunderbird.)
Originally it was about difficulty migrating to a new laptop with a different version of Windows, but I was quite firm about it because when I realized it wasn't able to do secure connections for some reason, so the instant they took their laptop to public Wi-Fi...
P.S.: Migrating decades of local messages was a huge problem. It's been so long that many import/export tools are defunct. I was even loading up extremely old versions of Thunderbird to see if I could import to that and then upgrade.
However the GitHub edition (not Sourceforge) of Eudora2Unix [0] saved me and deserves a shout-out here.
It took some tweaks and a harness to repeatedly try the conversion, since I wanted something I could literally drop into the Thunderbird profile folder. The final result wasn't perfect, (some file attachment issues linger) but it's way better than having it all at risk of Eudora.exe just refusing to launch one day.
[0] https://github.com/jonabbey/eudora2unix
>He didn’t remember his password, and we were unable to reset it because you need the passkey! No other options to authenticate for a reset were available.
Google treats both a password and a passkey as a primary factor, and if you forget either of them you have to go through their account recovery flow: https://support.google.com/accounts/answer/7682439?hl=en
AFAIK there's nothing different about the recovery scenario for a Google account in that state regardless of whether it has a password in use as its primary cred, a passkey in use as primary credential, or both.
Thanks. Upon further investigation we could have hit “Try another way” on the account recovery process UI a few times to get to a workable account recovery method.
Would be nice if Google would lay your recovery options out for you (which I am used to it doing in regard to 2FA if you are doing a regular log in) instead of having to hammer the “Try another way” link repeatedly as it cycles through options.
WDYM -- I thought "try another way" is supposed to list all possible options instead of cycling through them!
It does when I log in. You click "Try another way" and then it brings up a menu of options you have for 2FA. For some reason they have designed the account recovery flow to be different.
So, if you are used to the "Try another way" flow on login, it can be confusing to see an entirely different "Try another way" flow on account recovery.
I set my father (late 70s) up with a physical passkey (yubikey), and a backup key. He uses it for the important accounts (google, apple, bank, etc).
It’s been fine.
Yubikeys generally have much worse recovery scenarios than passkeys do, for consumers. In enterprise if you lose your yubikey, an IT admin can help you get back into your account. If you lose a security key as a consumer, you're generally in a much tougher account recovery situation.
You need extra backup keys in a safe place. They don’t explain that well.
Not all services let you enroll multiple keys. Amazon, with all the money in the world, was guilty of this for a long time.
Practically, it is a huge challenge. I would want my day to day fob, an onsite backup, and an offsite backup. That’s a lot of hassle and potential for mistakes. To even register the offsite backup means I need access to it. Remotely copying a password database is so much reliable
If you use a security key only for the most important accounts like Apple or Google, keys are set up once and then unchanged for years.
This is why I've always been a fan of these. They are easy for laypeople to understand.
Yep, I've never had Google, PayPal, or Amazon ask me about a passkey with a yubikey.
The current ones are passkeys
Doesn't the passkey have to be on her phone or computer?
It should be but haven’t checked her apple vault. I checked Google password manager and her windows password manager and there nothing in either. She might have used her phone and it’s in her iOS vault which I’ll check next. But this is what makes this entire passkey thing a mess. She’s 75, she didn’t do this on purpose and the ecosystem is just a mess
Everything about it is.
Also in the process of helping my dad with his phone, 76 and my grandmother 99. Maybe this works better with Apple, but the biggest problem on Android is, that it feels like every update shuffles everything around. Allmost no point in explaining, that they can solve some things on their own.
And all the time new things on the screen, new features they don't understand, need nor asked for.
Im young and I dont even bother learning how to use my Android phone's new features since it feels like everything moves or changes all the time. there's no point trying to get familiar with most of the features.
That's because most people at Google use iPhones as their primary phones, they hardly know or care about the UX
if any android pms or execs read this comment, it should be like a slap in the face. a scathing indictment of the state of their product.
just hang their heads in shame and walk into the sea
We're at a point where the biggest possible contribution to humanity of many PMs in big corps would be to just... drop dead. Feature-freeze rather than furthering the enshittification, as that seems all they're capable of.
I'd wish the world would just become boring again.
They’d just hire more to replace them and keep chaos machine running
Apple does seem to have one of the best and most secure passkey implementations.
A little snarky, but...
It _is_ true that it's more secure when even the people that the passkey was created for can't use it.
They seem unnecessarily opaque about it all.
I just made one for PayPal using my MacBook which seems to have ended up in Bitwarden rather than the mac thing. But there's nothing in Bitwarden to say list all passkeys. Not sure how I check elsewhere. Maybe they should email you "you have created a paypal passkey in Tim's Bitwarden" or something. Then at least you could search the email for "passkey"?
I wonder if I can use Bitwarden on another device with that? I honestly don't know.
You can't search for passkeys, but you can search for logins by URL and check the much shorter list for passkeys. The good news is that having the passkey in Bitwarden means you can use it on another device.
Even the concept of "where on the PC" has been totally annihilated by OS vendors and app developers. Is it on the filesystem? Is it on The Cloud? Is it vaguely "In An App"? Is it in some "Secure Enclave"? Who the fuck knows anymore? And the apps are no help--they insist on blurring the lines between local and cloud, hiding full paths, and generally just saying "Don't worry about where your data actually is. We pinky swear to be able to find it for you!"
Windows prompting her about Bluetooth for the pass key threw me too. I thought for sure she had clicked the wrong thing before I realized that somehow her widows pass key requires communicating to some device? Maybe her phone? No idea
I know on my Windows if I sign into icloud.com I have the option of using a passkey which I do by scanning a picture with my iPhone and it also using Bluetooth, presumably to prove physical presence of it.
No, it doesn't have to be associated with the phone, and IMO you are better off not letting the big tech companies own your identity, which is effectively getting Apple or Google to store it in your phone for you ends up being. There are physical passkeys that feel like a door key in everyday use. You can attach them to your house key ring, and like house keys are near indestructible. Lookup the Yubikey 5 NFC.
The only downside is unlike a house key, you can't get a backup "cut". Copying a physical passkey currently isn't possible. If you lose it, you've lost access to all your logins. As the article says, their recommended workaround is to keep backup physical passkeys, and log all your passkeys (including the backups) into every site. Which is insane - very few people have the patience to do that.
The article is really a long rant about that one issue - there is currently no way to securely backup a physical passkey. Solve that, and all the other issues melt away.
Who the fuck knows?
I for sure don't. Websites only know there is a passkey associated with my account, and the OS only knows there might be one on the device, or maybe on another device, and offers me options to check here or do a Bluetooth/QR Code dance, and when all of them fail, I'm no closer to knowing where the damn passkey is.
I had to mess with this just yesterday.
I got a new cell phone and installed Microsoft Swiftkey and tried to login to Microsoft. It said my device's password or security manager would popup, but it never did and it never showed an option to login via password, just a mostly blank screen. I tried logging in from my laptop browser and it immediately tried using a passkey, but I've never created a passkey for Microsoft, so it errored out, still never showing an option for password login. I tried again and it errored out again and FINALLY showed the option to login via password. It had to fail 2 times to finally show the option for password login.
I was finally able to login via password, then had to go to Microsoft's passkey management page to create a new passkey, store it in 1password, and use that on my phone.
I'm a software engineer and it was annoying and time consuming and took a minute to figure out. How are non engineers supposed to even use this crap?
It's gotten to the point where I assume "product manager" is a synonym for "incompetent person who breaks working products."
> how do I log in on a device that I don't own?
This is solved by passkey-implementing software and devices (with Bluetooth) allowing you to log in with a QR code (Webauthn via CTAP hybrid transport). iOS and Android support this, and it’s generally not a locked-down thing if other devices wanted to do it too.
The only use case left is in “how do I login if all my devices are stolen/fall into a body of water” in which there really isn’t an answer beyond “get (a|your) device back, sign back into your password manager, use that to get back into critical accounts”.
What if the computer you want to log in on doesn't have Bluetooth? Probably most public computers (like ones in libraries) don't have it.
The website should display a qr code you can scan with your phone that allows you to then login, unfortunately a lot of sites don't implement this, and some don't implement backup codes. This isn't the fault of passkeys per se, but of poor implementations.
> The website should display a qr code you can scan with your phone that allows you to then login...
A malicious website can display a QR code too. I think this "feature" could cause some of the security issues that passkesys were intended to solve.
I use Keepass and the free tier of Dropbox, to keep my passwords strong and available across multiple devices. (Dropbox not required, you can store the database on a thumb drive.) Backups are no problem.
Keepass (or KeepassXC) stores other data as well, including the correct URLs for sites. So my workflow is simply to click the URL from within Keepass, copy the username and password, and paste them into the login screen. So easy even an adult can do it! (Humor attempt)
For convenience, Keepass database can be unlocked with either a password or biometrics (your fingerprint).
(Not affiliated with Keepass, just a happy longtime user.)
That QR code from a malicious website will not actually communicate with the malicious website with authentication from the correct origin, most QR code phishing scams do not actually use passkeys but rather fall back to trying to get the user's fallback login information (if any). By spec, if the domain does not perfectly match the domain where the passkey was originally created, the phone (or passkey provider) will fail to find a matching passkey. And the domain is derived, not provided by the QR code data (it's all in the spec).
Basically, it's very hard if not basically impossible to spoof a QR code to access the real passkey via a malicious site. (caveat, without already having compromised something like the user's DNS, maybe? Even then the site would likely fail the cryptographic checks.)
Yes, the passkey flow QR code contains a public key, and a local key exchange is done over bluetooth to prove proximity. That is used to set up a confidential channel.
That means attackers need more than to display a QR code, they also need a local presence (radio).
The phishing protections of passkeys also works against "malicious QR codes". Which is a great example of why passkeys are kind of good, you stop needing to worry about a lot of attacks.
The fact that nearly every passkey implementation is lacking in a variety of very impactful ways... is a very good reason to _not_ use passkeys.
When every passkey interaction is a different variety of user interaction nightmare, it's not very convincing that it's a good idea in the first place
They're talking about a web-based QR code solution separate from passkeys.
Passkey QR codes are only WebAuthn via CTAP hybrid transport (with BLE verified proximity)
How does scanning the barcode with your phone log you into the computer? Does your phone need network access for that?
Steam does this. If I want to login, it shows a barcode I can scan with the app and it logs me in without needing to enter my login information. Phone needs internet access, doesn't need to be on the same network as the device I'm logging in on.
I assume the QR code contains a token for the device, which is used by the app to authorize the login and the server automatically logs in the client on the device with the matching token.
Seems a lot safer to me than using my login credentials on a potentially unsafe device.
Yes, this is how it could work, or it could display a code you type into your phone.
There's a whole set of fallbacks built in to the standard, including Bluetooth, local network connections, and going via a relay server. All of them eventually end up with your device signing something and handing that back to the browser on the other device to complete the authentication flow.
Is this why I keep getting notifications that such-and-such a website wants access to devices on my local network? I've been denying those left and right lately and didn't understand what on earth they needed access to that for.
Android 17? If yes, then that's because they added a new permission specifically to block apps from LAN access, then bundled it together with "nearby devices" (one introduced earlier specifically to block Bluetooth and WiFi scanning and point-to-point connections) because apparently they believe the concept of "local network" is too difficult for normies to understand or something - and due to how it's implemented, even apps trying to talk via loopback with themselves get captured in scope, too. The UI won't tell you which is which, though.
That's likely Google's implementation of Local Network Access (https://wicg.github.io/local-network-access/).
The browser delegates passkey plumbing up to the core platform typically, so it already should have the appropriate permissions.
I cannot speak to how accurate your description is, but this description sounds like there are multiple weak points and multiple attack vectors that open this up to increased risk of compromise, undermining the very security stance it's supposed to provide.
See my response above... I believe the description is incorrect, and bluetooth is required to prove physical proximity.
The spec is quite thorough and well thought out in this regard. Despite what it "sounds like" when described, it is very secure, even with a variety of implementations. What is far weaker is that most sites that offer passkeys also offer a multitude of fallback recovery options.
AFAIK, the "scan this QR code" method of signing in with a passkey on a phone on a device w/o the passkey requires Bluetooth. There's some type of handshaking that goes on in order for you to prove you're in physical proximity of the device you are logging in on, to prevent phishing attacks.
Since I might have made someone mad... to clarify, as I understand it, Bluetooth is absolutely required for this "Scan the QR code" flow to work. However, it's also possible the actual authentication traffic to travel over a different pathway (wifi, cellular), but the bluetooth part is always required though to prove proximity. So on e.g. a library computer without Bluetooth enabled, you would not be able to log in with a passkey on your phone.
Right - you can treat the protocol as having:
1. Initiation (QR code, NFC in draft)
2. (Proximal) negotiation (BLE key exchange)
3. Communication (over websockets or a direct L2CAP channel)
The challenge is that a devices without bluetooth (at least today) don't have another common way to wirelessly judge proximity. A desktop/laptop without bluetooth likely either doesn't have NFC, or has bluetooth disabled by policy and would likely have cross-device passkeys disabled by policy as well.
If you're not happy connecting your phone to the network, then how likely is it that you would you be willing to enter your login details on a machine you don't control?
What if you just can't have internet on your phone? Like if the computer is connected via Ethernet and there's no wifi network you can connect to? What if you're abroad and have no roaming? And the ultimate question about a person that the modern world can barely conceptualize - what if you have a dumbphone? Or what if your smartphone is lost or stolen or dead and you need to access some account? That last one has happened to me, and I sure am glad I know the key passwords that I need for survival.
These may seem like nitpicks, but there's probably a thousand rare scenarios like these that exist. You inevitably have to consider them when you're moving from punching in letters and numbers that you remember in the normal, low-tech way to a complex networked two-device workflow.
I think there exists a vein of contempt for anyone not fully embracing our bold new world, so many implementers etc. get the double bonus of alienating and frustrating all of the non conformers
If my phone is lost or damaged, I would buy a new, cheap Android phone and sync my passkeys to it. But I am curious why one would need to login to a website in order to survive? If one did have say a severe medical condition that somehow required a website in order to manage, I guess I would concede that maybe passkeys aren't the best way to secure such a life-sustaining website.
> But I am curious why one would need to login to a website in order to survive?
They use bank like Ally or Discover with no physical branches.
They use a mortgage provider like Rocket mortgage with no physical branches.
They use a medication delivery service with no physical customer facing pharmacies.
They have an employer that only facilitates reimbursement for expenses via online tools.
etc...
I guess "survive" has a sliding scale, but if I lost access to critical accounts... my life is going to FUCKING SUCK in a non-trivial and very impactful way almost immediately, on many fronts.
And if your answer to that problem is "well, just call them"... then we're right back to the point the article is making: "An account’s security is still dictated by the weakest recovery method"
Passkeys aren't a meaningful improvement in security - assuming you do actually have decent password hygiene like a password manager.
If your phone is lost, how are you going to sync your passkeys to your new cheap android? In a passkey-only future, you cannot login to your Gmail account without your passkey, which is only on your phone, which you've now just lost.
What am I missing? Either we retain passwords as backup for a lost or stolen device - in which case, all the security concerns are still there - or we only use passkeys, in which case we've added a clear nonrecoverable point of failure in the system.
What confuses me is that for a long while we told people to not write their passwords on a sticky note, to not write them in plain text somewhere.
Then we introduce all these "security" mechanisms that make it literally impossible to recover an account without backup codes.
Where do you store the backup codes? The average person, if they store it at all, will store it on a plain text file or in a sticky note.
Except that this creates a much more brittle system. Systems are safe when they are routinely tested/used. If you routinely have to enter your password, you are aware you need it. If you don't need your password, and you never have to enter your backup codes, you won't feel the importance of them until you actually need them.
It's the whole "I have backups" vs. "the backups actually work" problem except it's pushed onto the users who have zero technical knowledge.
FWIW my break-the-glass actual use of backup codes is for access to my password manager.
Everything else which has ever given me a backup code... gets stored in a secure note in my password manager.
It is just another knowledge-based factor. It is one that they are reasonably sure you aren't spreading around the internet. It is one that the site gets to pick rather than the user. But in reality, they are a often just a way to try to reduce some support and identity verification costs.
The path to get to the password manager is the case where the backup codes truly matter, because without them there may not be a way for support to restore access. Those codes may be your only way of regaining the master encryption key.
But that also winds up being part of the trade-off of security vs user friendliness. Some password managers are way easier to get back into.
Doesn't being able to sync your passkeys by entering your conventional password somewhere eliminate the whole point of passkeys? It just shifts the point where you can enter the password to recover your data to a less convenient place. And if your entire stack is passkey-protected (which I'm pretty sure is the case most of the time) then the secondary phone won't do anything for you.
When I said "survival", I meant it in the "being able to make do with few resources in a time of crisis" way, not that you will literally die if you can't access an account. Losing a crucial device without a fallback of being able to log in somewhere else quickly can mean immediately losing access to payments (the most crippling, especially if you're not home), being stranded in an airport or even not having an identity document (in countries with digital ID systems). Any of these happening can lead to enormous losses in time, money or worse, depending on when and where this event hits you.
Passkeys can exist on devices other than phones, so your entire premise is moot.
What? Did you read the thread? I never said passkeys can only exist on phones. The whole conversation is about "how do I log on with passkeys if something happens to my trusted device?". The parent comments talked about just using your phone, I'm saying there's lots of situations where someone might not have access to either a phone or an internet connection for it. And when this happens, you really don't want to be left without a way to access all vital digital services.
> I'm saying there's lots of situations where someone might not have access to either a phone or an internet connection for it. And when this happens, you really don't want to be left without a way to access all vital digital services.
And when that happens I'm usually glad my credential is a passkey on my keyring, as chances are if I don't have my phone and I haven't auth'd on to some computer I almost certainly don't have access to my password vault. But hey, my passkey works just fine without my phone. And I can trust that once I unplug my authenticator and log out of that session, there's no long lasting credentials left behind. I don't get that with passwords.
Aren't passkeys great?
You go to country X (USA sounds good to put in here).
You get mugged.
They take your phone and keyring.
They can't do anything with it since it's locked, but you don't have it.
Aren't passkeys great?
Wouldn't I have the same problem with passwords? I would lose my phone and be unable to two factor log in to my Gmail account or bank from someone else's device?
With passwords? No.
With 2FA? Yes. 2FA is almost just as stupid and almost just as bad for regular users as passkeys are, but it got adopted due to historical loophole - by far the most popular form was TOTP delivered via SMS, then "authenticator" apps, both of which keep the code transferable - you can receive it on one device, transfer to yourself or someone else (which is a feature, not a bug) via any channel, and get it to work. Passkeys were created specifically to close that loophole.
Plus, SMS didn't allow for vendor lock-in, which is arguably why they're so hated in security circles (SIM-jacking is real, but doesn't scale anywhere near enough to warrant deprecating it as mechanism for regular users).
I have over 2,000 accounts. The majority of them have unique passwords. I can count the services that have passwords that I know on one hand, with quite a few spare fingers.
Passwords just don't provide a broad recoverability benefit once you commit to doing strong, unique passwords.
> Passkeys were created specifically to close that loophole.
Credential sharing? I have a family share with passwords and passkeys in it. Passkeys most certainly didn't stop this.
They did add friction to having a user being duped to share their password to someone claiming to be tech support, since you can no longer request plaintext secrets be sent over arbitrary channels.
> Plus, SMS didn't allow for vendor lock-in, which is arguably why they're so hated in security circles (SIM-jacking is real, but doesn't scale anywhere near enough to warrant deprecating it as mechanism for regular users).
SMS is an ugly user experience and more importantly is expensive. Now a lot of services do emailed codes when they don't have a regulatory reason to require SMS - an even worse user experience, but less expensive.
We have authenticator apps which use a standard OATH setup, and quite a few platforms which have integrated support to try to sand over the worst part of the UX. Unfortunately they just didn't become popular, and OATH fails the same regulatory requirements that emailed codes fail.
Passkeys are not meant to have a vendor lock-in story. Credential exchange allows for credentials stored in consumer credential managers to be imported into another credential managers. The platforms have added infrastructure specifically to make this easier for users.
The exceptions are when enterprises run their own passkey stores, or when the user explicitly picks a solution that doesn't allow export (like a physical Yubikey).
"SMS is an ugly user experience"
No, it's fine. Most common example, I log in to my bank, they send an SMS, I copy the code and paste it into the web site. Works fine and I don't have to pick up my stupid phone, like I would if I used an authenticator app instead.
"and more importantly is expensive."
Not for me. The bank made several billion dollars last quarter, don't think it's a big problem for them, either.
Most common example, I log in to my bank, they say they sent an SMS, I sit there waiting to access my account, then 20 minutes later the SMS finally actually gets delivered after I've given up and left to do something else. Rinse/repeat.
Or another example, someone hijacks my SMS'es, and then they log in as me.
SMS sucks. SMS is insecure.
The amount of times I've experienced customers complaining about SMS 2FA not working well despite it being on their carrier failing to deliver the messages in a timely fashion really showed me how terrible it is.
Dunno what to tell you. Several possible points of failure there. Maybe your bank's system for sending SMS just sucks. Maybe you're in a place with poor mobile network coverage (which is a real problem for SMS 2FA, I agree, having lived in a place with nearly none for several years).
But for me, where I live now, with my bank, and my phone carrier, it works great. Never had a problem that I can think of. Typically, the SMS arrives within seconds. It's the least annoying and most reliable 2FA method I use.
I'm not that worried about potential security issues. Sure, it's a possible problem, but pretty low on the list of things to worry about.
A passkey or a 2FA requiring a non-trivial device are functionally equivalent. Passkeys and app driven 2FA are the same when shit goes bad.
They can’t do anything with it
I have a backup key at home
Mission accomplished
But the problem is that you can't really backup passkeys and because people are frankly frequent tricked into using them, they have no good recovery options.
I know plenty of people who only have a phone, no other devices. They don't backup that phone, they should but they don't. They don't use a password manager either, maybe they should, but they don't.
My issue with passkeys are that they are designed for a reality that don't exist, or at least only exists for people who are already doing a lot to secure their devices.
> But the problem is that you can't really backup passkeys
The individual passkey? Maybe not. But I don't really need to backup the passkey, I can just have backup passkeys or other backup authenticators, including complicated stored one-time passwords.
To answer your earlier hypothetical, I'm out traveling and I'm mugged. Well, hopefully, I'm not mugged in the part of the travels where I'm carrying truly everything at the moment, and I can just go back to the hotel room and re-auth with a device I saved there Problem solved, no big deal. If I lost truly everything while I'm out, I'd do as suggested elsewhere here and call home to get a trusted friend/family member to read me off the one time password saved at home or whatever, or figure out some way to get me money to get home. Chances are I'll end up having to work with the embassy anyway.
> My issue with passkeys are that they are designed for a reality that don't exist
The reality of passwords being hijacked is absolutely a reality of today and is a constant issue for tons of people.
> I know plenty of people who only have a phone, no other devices.
And I really don't get why we can't also teach these people to also have a little token they use that can also be a part of their online identity. And sure, for certain kinds of accounts have appropriate levels of recoverability, but for the normal authentication workflows its so much better in so many ways.
At this exact same level I posted this.
>They are designed for a wealthy technologically inclined user with a very stable lifestyle and trusted resources and connections to other people. You know, the exact people who developed them.
And here you go posting
> I'd do as suggested elsewhere here and call home to get a trusted friend/family member to read me off the one time password saved at home or whateve
If you read what I posted you see why you live at a particular place of privileged and are seemingly incapable of putting yourself in another persons position where these things do not hold true.
"If you are a white male earning over 100,000 a year in a stable relationship with living family members, excess savings in the bank, in a stable first world country everything is going to be fine and the rest of you can get fucked" --what you keep repeating in different ways.
I agree every kind of account should have a reasonable level of recovery process in place.
Also, you're posting incredibly racist and sexist statements here. Why does race and gender matter here?
Stop being racist.
I mean I was pointing out that you were being racist and sexist from a position of privilege without realizing you were doing so. A kind of systematic failure caused by not realizing our choices as developers has real world impacts on the less privileged.
You're being racist and sexist by assuming wealthy westerners or those in stable relationships or those being able to call home to family are white males. If that's not racist I don't know what is. I don't think it takes being a white male to be able to call home to family when traveling internationally. You're assuming a point of view is invalid due to someone's race and gender.
Quit being racist and projecting identities on people.
This is about people who would have a hard time recovering digital identities. I imagine there were lots of white males fleeing war in Europe who probably struggled to get access to accounts backed with things like passkeys and other forms of 2FA. But I guess to you their struggles don't matter.
Its almost like you including gender and race was just your own projections of your own hatred for a particular group. You should probably think about things when painting people with such a wide brush of "white males" when trying to paint people in a derogatory fashion.
I spent a chunk of my life homeless. Don't project some identity on me that's not valid, or that I just totally lack some perspective due to your assumption of my race or gender. Its not a fair thing to do, its literally racist and sexist.
You could have tried to make your point without throwing in racist and sexist comments by just saying "wealthy western software developers" or whatever.
> designed for a reality that don't exist
They are designed for a wealthy technologically inclined user with a very stable lifestyle and trusted resources and connections to other people. You know, the exact people who developed them.
Do you have a plan for getting home without access to any of your accounts? And one of the problems with passkeys is that it's unreasonably difficult to keep a backup key.
You're asking way too much foresight in this thread I guess. There are some people who have lived lives without any series of unfortunate events, they can't even imagine what the world can serve up.
If nearby (some country) any credit card or even my ID card will get me home. I can walk into a branch of my bank and - with some waiting and paper work - I should be able to get enough cash to get myself home.
Abroad I’d head to the nearest consulate of my home country. Might be difficult to get to if it’s in a far away city. Hard to prepare for abstractly.
I've done a mock "what if I wake up naked in Tokyo" for my own recovery several times, mostly because I keep things really tied down.
I have not yet done an actual test within Japan, however.
Great, now I just need to get back home to use my uncompromised accounts (which would have still been protected by my device as long as the thieves aren't NSO Group, but whatever). Gee, it seems my tickets back home were taken with my stolen phone! Not to worry, they sent me an email confirmation, so all I need to do is log into my passkey-protected email on my friend's phone and have them download my ticket in addition to theirs, or print them at a public computer. Oh wait
As long as you still have your passport, which you’d need for international travel anyway, you can get your boarding pass at the airport without any hassle.
Poor people exist.
The poorest country I'm familiar with is Zambia, where about 90% of the population have a mobile subscription.
The number of people sharing GP's concerns for reasons of poverty rather than because of their personal security posture will be vanishingly small.
> The poorest country I'm familiar with is Zambia, where about 90% of the population have a mobile subscription.
Only 85%¹ of the population are over the age of 4. Smart kids they've got.
¹ https://populationpyramids.org/zambia
They still exist, though. And in my experience people in vulnerable positions have somewhere between zero and one phones at any given time, without necessarily any good continuity between them.
I don't think "fuck 10% of the population" is as strong an argument as you seem to think it is.
I'll have to remember this one the next time I hear the phone/poverty argument made in bad faith.
> willing to enter your login details on a machine you don't control?
Are you talking about your phone here?
Sure, your personal security posture might very well preclude that.
But, again, if you don't trust your phone then how likely is it that you will be prepared to trust a public computer?
what good is a phone if it isn't on a network?
> what good is a phone if it isn't on a network?
1. It might be on a voice network but not on a data network; for instance, if you don't have a data plan.
2. Modern smartphones are actually a hybrid of a traditional cell phone and a traditional PDA, and you might be using it for the PDA part.
Have you ever been in a large building with awful cell reception and no wifi access?
That's still a terrible solution. Plenty of people don't have phones that can do that, or dont have e it with them when they do etc..
My suggestion would be to not do that. But keep a password and an offline TOTP app if you must. It’s still an option.
Only if they’re a bit old. Nowadays WiFi chips double as Bluetooth chips on newer platforms.
Only if they’re a bit old. Nowadays WiFi chips double as Bluetooth chips on newer platforms.
That's a technocratic reply, not one that is useful in the real world.
As noted by the person you're replying to, it's not his computer. It's a public library.
Most computers in non-residential settings will have various features locked down, including Bluetooth.
Hotels, clubs, airport lounges, various government facilities… there are thousands of places where you might really need to use a computer but don't control the technology.
> > What if the computer you want to log in on doesn't have Bluetooth?
> Only if they’re a bit old. Nowadays WiFi chips double as Bluetooth chips on newer platforms.
What if the computer you want to log in on doesn't have a WiFi chip?
It doesn't have to be an old computer; for instance, the desktop computer I built last year uses a wired gigabit Ethernet connection to the router right next to it, and doesn't have (or need) any WiFi or Bluetooth chip.
The computer I just replaced had neither wifi nor bluetooth. It was a desktop device and had no use for either.
>This is solved by passkey-implementing software and devices (with Bluetooth) allowing you to log in with a QR code (Webauthn via CTAP hybrid transport).
Ok but how do I share my Netflix or Spotify accounts for example with those?
The same way you share them now: sharing the account name and password and doing whatever you currently do to deal with any 2FA they occasionally toss in.
If they also allow passkeys as an alternative form of login that doesn't need 2FA you can use those to make the account sharing more secure.
When setting up sharing with someone first change the password to something else, and then share the account name and password. After they log in the can add a passkey to the account on their device or devices.
Then you can change the password back to your real password. When they want to use the account they login with their passkey.
If the service doesn't accept login passkeys but does allows passkeys for 2FA, you have to use real password sharing, but at least they can have a passkey for 2FA which may be easier than how you know handle 2FA.
How do people handle 2FA with account sharing? If the site uses TOTP you can give them the QR code that you received back when you made the account (you do save a screenshot of such QR codes for backup, right?).
But how do you handle SMS 2FA, which seems to be far more commonly offered than TOTP?
For email 2FA I suppose you could set up a filter on your incoming mail that forwards any incoming code emails to the people you shared with, and hope that the time limit on the code is long enough for this to work.
In general you shouldn’t - Netflix[0] really should get proper invite-based family sharing, and Spotify’s subscriber agreement has a section that defines Premium as a “Single-user Paid Subscription” and thus can’t be used by multiple people, legally (and you might be at risk of getting banned if they detect it)
However, passkeys can and are available to be shared via password managers. They’re not locked to the secure chip on the device where they live usually. iOS’ Passwords app has a share button and 1Password lets you share passkey-containing items.
In fact, the QR code login feature makes it even easier to do a one-time sign in to your account for a friend, if you don’t want them to be able to login to your account indefinitely.
0: Netflix doesn’t support passkeys because their main audience is people signing in via smart TVs and whatnot, which largely don’t support CTAP or Webauthn in general)
>In general you shouldn’
Me to said companies: I will do what I want.
Said companies to you: sounds like what you want is to get booted from our service.
Me: Invents more new ways of being problematic for the company spreading the ideas to millions of others decreasing their profitability to almost nothing.
Me to company: Damn, guess you shouldn't have been an asshole about it, kind of backfired on you.
Ok so when is Netflix going unprofitable?
The responsible product owners will already have bounced 18 months prior after tweaking the stats to falsify the customer satisfaction rate and grabbing their bonus on the way out.
2FA is lowkey designed to reduce paid account sharing. It's always those services that are so eager to get people 2FA'd. Microsoft Minecraft account is the hardest thing to log into, and they even perma locked tons of people out.
Can't you just share the TOTP secret key?
TOTP is unfamiliar or hard to use for most people, so they use SMS. Most sites don't support TOTP either.
Even if you use TOTP, it's not designed to be shared, for example look up what hoops you need to jump through to export a single TOTP code in Google Authenticator. And they used to not even have that option; they told you to set up multiple TOTP codes on each website instead. Even on 1password I had to look up a tutorial on how to import a TOTP code cause the menu is in a very non-obvious and deep spot.
I've shared with non-tech people a few accesses with TOTP codes and it's just a WhatsApp message away "hey dad, enter 12345 when asked".
Code is different from key. The secret key is how he can get new codes without you having to deal with it every time he logs in.
What if my phone is dead? Stolen?
In the same vein as 2fa, going up to a fresh computer and trying to log into anything is now a nightmare. Every service has a 2fa that somehow loops into another provider that also has 2fa.
And some 2fa, if not many, make accounts weaker. Apple's solution to get around 2fa is to put in SOMEBODY ELSES phone number that I trust, as a backdoor. It's an insane solution. And its normalized, and nobody questions it.
While we're at it, the insanity of those "recovery questions", made even worse when many companies demand the same ones.
but you can type anything in the recovery box.
its just three additional passwords.
should you type the same brother name in each time? should you even answer with a name?
don't get me wrong, they were insane, but they can be repurposed.
Good luck remembering what you put there when asked 10 years later.
Yeah, many do not even allow you to enter in a custom question, which would be marginally better--at least for users who care about security.
Then you'd have the option to craft a question which is (A) personally memorable (B) specifically phrased to avoid ambiguity, (C) not public or guessable, and (D) unique to a service.
* "Where is your first pet buried?"
* "While on vacation, The Noodle Incident happened in which city?"
* In what year did you first see Example Band live in concert along with Alice and Bob?"
put it in your password manager?
Awesome. I'll just find the thief and ask nicely, shall I?
Sign in with a QR code is dangerous though because at that point theres very little stopping QR phishing and forwarding the bluetooth request to your browser. See the most common Discord scam.
> forwarding the bluetooth request to your browser.
This isn't a thing. Discord's QR Code scanning is entirely a feature they made unrelated to passkeys or bluetooth. Passkey auth using a QR code has a step that verifies the proximity of both devices using BLE.
Passkey on NFC/USB hardware token (x2)
They're cheap enough if you lose one it's not the end of the world. Goes on your keyring. Doesn't require esim management. Use NFC swipe/usb-plug-in + pin to use.
The problem with hardware tokens is that they 1) Only store a limited number of logins, 2) It is very difficult to keep them in sync- every time you need to add a passkey, you have to get them both out, which makes it difficult to keep one a in a secure safe to keep it safe from damage/loss
This two fatal flaws are what limits their usefulness to enterprise SSO and perhaps some other limited uses where the organization has the ability to replace tokens. (Even in a distributed enterprise, enterprise SSO may not be a good fit for hardware tokens, if they can't get replacements out to employees fast enough).
> the problem with hardware tokens is that they 1) Only store a limited number of logins,
1) It's one passkey used over and over, so it only takes 1 slot.
> 2) It is very difficult to keep them in sync- every time you need to add a passkey, you have to get them both out, which makes it difficult to keep one a in a secure safe to keep it safe from damage/loss
2) With SSO used across enterprise exactly like you're talking about, works fine without having to reregister over and over. Been using this and have implemented it myself for years.
3) much cheaper than a phone with a much cheaper recovery path
4) no path is a free lunch, you're always going to be making compromises somewhere, it's the nature of security - it is adversarial
> it's the nature of security - it is adversarial
Yes, this is the issue. People don't like how adversarial security people act, and how they force things onto people. It's fine if a corporation wants to have some internal policy since they're the ones eating the cost if an employee can't work or whatever. Less so if individuals are forced into these wonky setups for no benefit. e.g. now I have to run and maintain and backup a Vaultwarden server just to log into my HSA, which is absurd (I also have to keep an old version of the bitwarden extension around and use that because the latest requires TLS, which is another piece of infrastructure that I don't want). My password manager already generated random site-specific passwords. And for some unknown reason, browsers didn't start with the obvious step of software passkey support in password managers, and then allow hardware keys for the nerds that want that.
Oh, right, because it's actually a lock-in play, and it's designed to be unusable unless you tie your entire life to Google or Apple's cloud platform.
The problem isn't the cost of replacing it, the problem is - how do you log in when all your passkey-bearing devices just got flushed down the toilet?
Copy pasting my other comment from an earlier thread
FIDO2 USB Security key -> Bitwarden (With master password) -> Every other method (topt/password)
I have 3 FIDO2 USB Security keys, One I carry with my persons at all times, one that stays with my main machine at all times and an offsite backup that is sitting in a friend's server, if my house burns down, I can either physically collect the key or use USB-IP to authenticate back into bitwarden and enroll a new key. (Actually all 3 are at home right now but that's ok)
How is that different from accidentally deleting your keepass database? Or forgetting your password? I think it’d be easier for me to forget than find myself trying to flush all my hw tokens…
I can back up my keepass database, and I can write down my passwords.
I can back up my FIDO2 (non-)resident keys too. In the end it's just a piece of HW with some secret material inside. non-resident FIDO2 keys are easier to back up, because the master secret seed is fixed and shared for all origins and there's nothing stored on the key.
Same way. A majority generally have a old phone that was already signed in to google. Or if they remember only Apple ID and password (one very difficult password) + sms. They can login on to a new phone.
Everything is SYNCED immediately.
What if you have a ransomeware that destroy everything on the same day your house and all backups burn down. And you cant get it from immutable backups as you wrote that decryption key in paper. And the bank will not allow you to access it as the govt deported you elsewhere.
I can get another hw key (if one of mine breaks, which I, surprisingly enough, have not yet managed to achieve)
And since I have at least two at all times, the possibility of one of them breaking changes… not much really.
Paper can burn or get tossed, backups files can go corrupt, and I really don't understand what is that extra risk hw keys introduce…
There is at least one valid (in my opinion) reason to not like hw keys though: they cost real money to acquire, so you probably want an extra margin in your budget for the unlikely case they indeed decide to break.
You have more than one key right?
Also... Is flushing your whole keys down the toilet a problem you run into often?
> Also... Is flushing your whole keys down the toilet a problem you run into often?
It's a potential catastrophe I'd like to avoid if possible, but the catastrophe is not inherent to any other key I have.
House key: Make new copy for 10 USD. Alternatively, get a locksmith to unlock the door and change the lock. Even more alternatively, break a window or door. I still get into my house.
Car key: Make a new copy for >10 USD. Alternatively, call roadside assistance and get them to tow me somewhere I can get a new key. More inconvenient, still very possible.
TOTP 2FA and passwords: Password databases can be backed up, and so can TOTP seeds. It's inconvenient to do so, but I can at least still just leave copies around everywhere I can, so that it's extremely unlikely that I'll be completely locked out.
Yubikey: Making copies is literally impossible, so I'll need to buy two or three keys from the get go, and get them all out every time I need to add a new key. This is a huge inconvenience that no casual user will ever do (they might do 3-2-1 if it was set-and-forget, but Yubikeys aren't). If I don't do this, I lose permanent access to my accounts. There is no safety valve built in to the system. If I lose my key, I'm fucked.
My point is if you just flushed your keychain, maybe some terrible accident while drunk at a pub, you should still have at least 1 more hardware key somewhere else. And by the way, your phone is also a viable key. Having a passkey on your phone and a physical one on your person solves most issues, with the rest being covered by having 1 or more in a safe or other secured storage location.
Its going to be hard to flush my desktop and my laptop down the toilet.
I recommend a reciprocating saw with a metal cutting blade to get them into small enough pieces. Do not try to flush them all of the pieces at the same time. It's not just about whether they fit or not, they also need to be light enough for the water current of the flush to carry them all the way through. Otherwise, they may end up in the water trap and hinder your future use of the appliance. For small partial blockages, it may be possible to consume some extra fiber in order to be able to "sweep" some of the metallic remnants along, but this will void both your warranty and your bowels.
I am a doctor -- and a lawyer and an orbital mechanics specialist, as well as a highly respected behavioral therapist -- so you can trust my advice. Also, feel free to consult an AI on this topic; it would make for an amusing benchmark.
Pretty easy for a lightning strike to simultaneously destroy both though unless you always unplug your computers during a storm.
I believe in you.
But a majority don't do that. For them let them use passkeys. If the possibility is once in 10 years then I am happy to do that. A majority is happy to do that.
And yes, Google or Apple - dont say you should not keep passwords in your database and sync it with dropbox. DIY.
Rest of us want convenience.
Enrolling two devices stored in different locations for every sign up is extremely annoying.
I suspect that most people that ostensibly do this actually only enroll one for non-critical accounts and then depend on some fallback mechanism.
This is a legitimate problem, and one of the few cases where a third party login provider makes sense, at least for non-critical “apps”. If both tokens can be authorized to that provider, then you don’t need to enroll any more tokens for apps using that provider. The difficulty is creating a trustworthy provider system without weakening security (the provider shouldn’t be able to login without you) that doesn’t collect information about you and which can’t lock you out from all your accounts.
I’m not sure what work has been done on this since Mozilla Persona. I certainly wouldn’t want Google and Apple, or governments, to be the sole gatekeepers.
Why would you choose that over a synchronizing passkey manager?
A third party OAuth provider puts you at the mercy of the service provider, the other can work fully on your client side even if the app provider were to disappear tomorrow.
The only advantage I can think of is that you have a centralized place to revoke credentials in case your password manager does get compromised.
> Why would you choose that over a synchronizing passkey manager?
No second factor, compromised passkey manager leads to compromise of all accounts. This is a huge problem.
> A third party OAuth provider puts you at the mercy of the service provider, the other can work fully on your client side even if the app provider were to disappear tomorrow.
Yes that’s what I was saying, it needs some thought and careful work. It would need to be decentralized, and I’m not sure that current standards are up to the task.
"A third party OAuth provider puts you at the mercy of the service provider" This is they key issue with trusting a third party to manage my passkeys, they can also BLOCK them and lock me out. An exception is if the passkeys are synced to all your devices and cannot be remotely wiped. I think this is how Apple works.
I didn’t think of this in the moment, but you’re right, this is an even bigger risk than compromise. There’s regularly a thread here about someone getting locked out of their cloud accounts, and now we’re going to gate everything behind those same accounts? Horrible idea.
Yes, I'd absolutely not use Apple or Google for my passkeys, even though they now at least seem to support exporting them to other platforms.
Then don't, there are several open source synchronizing passkey implementations!
> how do I log in on a device that I don't own?
Sad reality is that such usecase is less and less common, thus, no one cares about it. I think majority of my friends would not be able to access their email, or facebook or alike, if they were forced to use my computer in emergency.
And that sounds fine, until you're traveling and your devices get stolen or lost. How, exactly, are you going to get into your email then, once passkeys become the only means of login? Because that moment is when you really do need to access your email, stat.
What services implement it like this? Don't services usually implement passkeys as a more secure alternative to a password, but password login is still available?
Some sites allow passkeys as an option for MFA, so that could be an issue if the passkey is your only MFA option and MFA is required. But I imagine email would pretty much always be a fallback.
Didn't Outlook.com famously rolled out passkeys with no recovery option and no option to sign in using username and password once enrolled. So if you lost your trusted device, you couldn't sign in, nor could Microsoft send you an email, because... Outlook.com is your email provider.
I don't know if they fixed it, they probably did. Edit: Maybe not, because the recovery option at the end is just nuts: https://learn.microsoft.com/en-us/answers/questions/5454924/...
When was the last time you tried to log into something like Google, Apple, Microsoft etc without your phone nearby, on a fresh computer?
Nothing but a memorized password works in this scenario, right?
And not even that, now that I think about it. I have my very long Bitwarden password memorized but if my devices are all stolen I won't be able to get passed the 2-factor, so I'd still be screwed.
Rubbish. Such use cases are extremely common anywhere it can't be expected everyone has access to their own device.
Isn't there a workflow where you scan a QR code to confirm the pass key on your phone?
I've definitely done this, but not sure if the workflow was at the OS or browser level.
I'm honestly confused by all the negativity in the comments. Passkeys are great for convenience. Just leave your password login enabled as a backup. That defeats any security benefit, but oh well.
> Isn't there a workflow where you scan a QR code to confirm the pass key on your phone?
For people in this position, if they had their phone, they probably wouldn't be logging in on a computer anyway.
There are a lot of reasons why I might want to login on a computer I don't own to do something, rather than to use my phone. Having a keyboard is a major usability benefit for many types of work. Larger screen, printer. Software that is on the machine that can't run on my phone.
I agree with you; those are all reasons I only use my phone for on-the-go messaging or navigation. I'm against the idea that you should have to have a secure (against the owner) connected phone on your person at all times in order to sign in to a web service.
You don't have to with passkeys. I use passkeys every day, they rarely involve using my phone.
Thats still irrelevant to the example being discussed.
This is what I use to log into our remote desktop software at work. The passkey is on my phone and I scan a QR code presented by the remote desktop software (in this case it's the Windows App on my macbook and Microsoft Authenticator on my android).
There is. Doesn't work on every browser but it's really nice and I use it routinely.
Which is a trade-off that makes sense for a lot of people. If you have multiple devices, many of which are portable and one you have on you all the time, the need for that is just way lower, so being more secure against commonplace automated widespread attacks is worth it to them.
Many people are moving to only a single portable device that’s easily lost, broken, or stolen, without any understanding of backups or fallbacks for their accounts.
And many are moving to virtual wallets like Cashapp rather than banks with a physical presence where you can take out money without a phone.
It’s a bad situation.
Heh, this situation totally reminds me of politics.
Person 1: "People that end up in this situation that can easily happen should be punished to the full extent of the law with no mercy!"
[Exact situation happens to Person 1]
Person 1: "This is the greatest injustice, do people have no empathy? I could not have avoided this situation!"
That sounds deeper than politics… More like human nature.
A variant of that is alternative accounts that properly live on a different device/context.
For instance YouTubers usually have a different account for their channel than the one they use privately, and don't want their channel account logged in everywhere.
That means having to log in as a guest when push comes to shove. And similar setups are common for most self-employed keeping a "work" account IMHO.
That's actually a good use case for HW keys. Since untrusted computers are much more likely to have keyloggers/malware, etc. So you don't need to reset password and invalidate all sessions after each such login on an untrusted computer.
The offer a strong protection against phishing attacks that would still get plenty of password manager users: fake websites. A passkey is strongly linked to a domain, so a fake site can't get that credential.
Some password managers will only fill if a domain matches, but IRL the response I've seen from most users when it doesn't match is to assume the integration broke and manually copy/paste it in. I've also seen lots of them do stuff like happily autofill on any prefix of the domain, so your credential for `something.example.com` will autofill into `fake-something.example.com`.
"Oh, usually my bank just logs me in, that's strange. Let me just go grab my username and password and type it into this site that looks like my bank."
Same thing is going to happen with passkeys for non-technical users for exactly the same reason you stated. People will think the integration is busted and manually copy/paste the non-passkey credentials in. In that way, I would argue that passkey is not stronger protection against phishing attacks unless its the only way to login. It is, at best, a convenience for users.
If the user just has a username/password fallback and that's it, then yes, but the aim of passkeys is that won't be the norm, rather users will only have passkeys and the fallback would be to, e.g: magic link email log in where the phishing attack is still broken. I've seen some sites explicitly disallow plain username/password login after you enable passkeys for this reason (you can still put them in, but then it just does a magic link flow afterwards as a second factor).
The pitch is that passwords will supposedly be phased out entirely as an option.
I've been told by multiple people that the recovery method of passkeys is to enter your username/password. If passwords are eliminated, your final recourse is fucked.
Why would it be that is the only recovery method? The most convenient one is just more passkeys on other devices of course, but you can have any other recovery methods you want. Magic link emails are the most common, but there is nothing about passkeys stopping you from implementing anything you want.
Which is a laudible goal, but something that makes "oh just fall back to the standard insecure recovery process" not a very good response to the concerns about users being able to actually hold on to their passkeys easily and reliably.
How did fake-something get injected as a subdomain?
Loads of hosting sites do this, username.domain.tld is the most common one.
I guess it's a good thing my bank doesn't have a free web hosting service
> but IRL the response I've seen from most users when it doesn't match is to assume the integration broke and manually copy/paste it in.
I've seen people do this AFK as well, and I'm always helpfully suggesting them the correct way of solving this: verifying the URL again, and if correct, add it to the password manager so it remembers in the future, and never copy-paste passwords on the web. Basically 50/50 if they take the advice or come back after a week asking if it's safe to copy-paste the password into the website, and I try to inform again.
Shockingly, I saw one developer peer copy-pasting a password into a website, but I guess for these people there is no hope.
It should be a big red flag for sure, but the reality is most users aren't going to understand that. They got told to use a password manager by someone or find it convenient, but they don't understand the security flow enough to catch that it's a potential attack, or how to resolve it safely.
Historically I've seen lots of sites do a subdomain shuffle for login pages every now and then which routinely breaks domain matching, introducing false positives that users have to deal with, making them numb to the threat too. Passkeys baking in the domain check with no workaround means that sites can't do that, which is a benefit.
My password manager's browser integration breaks on every update of Firefox, which seems like it is a weekly affair. I got rid of the extension, and copy/paste everything.
Password managers were never meant to solve the problem of phishing, and aren't really capable of that. They solved the problem of password reuse. They do that just fine.
There are too many websites where this is broken for me (even with Firefox's built-in password fill) to go as far as to never copy-paste passwords. If web devs actually implemented it consistently, I might be that draconian about it, but asking them to do that when we already have the '200 MB of JS is needed to view this page' problem, I have my doubts we're going to see this problem going away any time soon.
Probably the whole authentication thing shouldn't be implemented by the website at all. There should be some standardized way to ask for authentication that's implemented by the browser or the operating system.
Your last sentence got me good, as I'm a developer who copy-pastes passwords into websites (from a 12? year old KeePass database, for whatever that's worth).
I've tried using the Firefox integration in the past - more than once - and I don't know... it had so many warts that I got fed up with it and turned it off. And now I have 1Password (from work) also doing its best to feed me credentials all the time. So trying the KeePass integration again is going to have them both drawing suggestion dropdowns all the time..
But ok, I'll give it another honest shot. Because of your comment.
> Some password managers will only fill if a domain matches, but IRL the response I've seen from most users when it doesn't match is to assume the integration broke and manually copy/paste it in. I've also seen lots of them do stuff like happily autofill on any prefix of the domain, so your credential for `something.example.com` will autofill into `fake-something.example.com`.
Why would you trust the very same password managers that don't handle passwords properly to handle passkeys properly?
You don't. The browser handles the passkey matching to the domain which is obviously a better place to do it. There could obviously still be bugs as with all things, but it's much more intentionally integrated into the flow which makes it much harder to bypass.
> The browser handles the passkey matching to the domain which is obviously a better place to do it.
I'm not sure why you're making a distinction. In many cases the browser is the password manager.
Right, I haven't seen that particular flaw in baked-into-the-browser ones (probably because they already having secure domain matching code ready to use), but the distinction is that doing the domain check is a part of the spec and standard, so e.g: sites aren't going to break it by changing the log-in subdomain routinely, as has been common historically.
Password managers have had to be permissive enough to work with most websites, and there is no standard for it. There have been sites that blocked the autofilling of passwords and so on as well.
My point wasn't this one particular flaw in some password managers is the reason to use passkeys (the copy/paste point is the much bigger issue anyway), just that it's an example of how relatively brittle the password manager process is. Having it a core part of the spec gives stronger guarantees.
“There have been sites that blocked the autofilling of passwords and so on as well.”
Sites that do this irritate me so much. Ones that try to block pasting and stuff… like somebody intentionally baked that into the site. Who? And what was their rationale? Are they really so arrogant to think people are going to carefully type in some elaborate password not once but twice?
That and blocking paste in fields like bank account numbers and stuff.
Surely somebody here has been asked to implement these mis-features. Please explain what went through the heads of the people responsible for it?
Blocking bank account numbers from being pasted is considered an error prevention measure. By forcing people to enter it manually at least once, you stop them from blindly pasting the wrong number twice.
There's no real regulation requiring blocking paste but it has become an annoying informal standard of sorts.
Sure but who is reading account numbers off checks? They are copy and pasting from their bank app.
Thankfully brave’s right click menu has a force paste that works quite well
The users are the ones manually copy/pasting the password. There's no way the password manager could prevent this short of disallowing copying/viewing passwords.
The password integration breaks because it's trying to detect password fields rather and failing because of weird HTML/JS code.
The passkey integration goes the other way, which is much more reliable.
> Why would you trust the very same password managers that don't handle passwords properly to handle passkeys properly?
Gell-Mann amnesia effect
https://en.wikipedia.org/wiki/Michael_Crichton#%22Gell-Mann_...
> But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.
This is meant to be solved by the cross-device flow - a QR code pops up that you scan, and a secure channel is established from that with your other device.
[Disclosure: an editor of said standard]
> The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for.
On macOS/iOS, the system gives this prompt regardless of where your passkeys are being created/stored:
Save a passkey?
"<site>" supports passkeys, a stronger alternative to passwords that cannot be leaked or stolen. A passkey for "<username>" will be saved in "<provider>".
There is a transparent upgrade option though that sites can request - basically when a site supports passwords and passkeys, they can request a password manager supporting both create and return a new passkey on password sign-in.
> [...] and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
That's unfortunate. A site/service should absolutely not replace other passkeys, nor should it remove other sign-in options like passwords, without explicit user consent.
The above credential upgrade flow makes that doubly so; even if someone relies on a password manager to manage and provide their credentials for a site, it very well may not be the singular piece of software that does so.
> This is meant to be solved by the cross-device flow - a QR code pops up that you scan, and a secure channel is established from that with your other device.
That only works if the device has working camera and bluetooth. What if I want to log in from my new desktop PC to an account whose Passkey is stored on my old desktop PC?
If passkeys were implemented properly, the would be most useful to relatively technical users that already use password managers. Ideally, the only real change is that a single text password is replaced with multiple non-text "passwords" that cannot be entered on the wrong website by accident.
The problem is exactly that they're being forced on nontechnical users when the UX isn't even good enough yet to sell them to technical users.
> If you use multiple devices throughout the day, registering passkeys in all of these systems becomes a big headache
This is why you use hardware keys which work across devices like yubikeys and the like.
I have two of the old neos and two of the newer usb c + NFC enabled ones.
No issues.
Some would consider spending over $200 on hardware keys an issue.
Peace of mind is a luxury good
I'm just storing my passkeys in 1password, which means they're synced across my two computers and phone and also means I gave up any kind of hardware security.
Oh well.
> I've accidentally set up passkeys just by clicking an okay button a few times in the past and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
No doubt there exist services that do not offer recovery method for passkey or mfa enabled account. But this is entirely on them (the service), to blame for, not the passkeys or the users. It’s bad implementation.
Bad implementations of an otherwise sane/fine technology can sink the technology. Here’s to hoping that happens with passkeys
Sony Playstation will only let you setup a passkey if you disable password auth.
But I have not found any way to use my browser's passkey to login on my PS5. I can scan a QR code, but that requires logging into the mobile app with a passkey. And I can't add one to my mobile phone because I can't login on mobile... the passkey is on my laptop, and it won't autofill from 1Password (Android).
> Passkeys do marginally improve security against MITM and phishing attacks ...
The tragedy of passkeys is that they're a step back from the security offered by the likes of Yubikeys.
But because passkeys are pushed by both Google, Microsoft and Apple: there is is simply no fighting these three. It is impossible.
Passkeys won not because they're better (they're not and the entire concept of "secret behind a hardware security module" that can be transferred to another system defeats the whole point of a HSM in the first place) but because the powers-that-be decided that passkeys are to be used.
It's still a win: the commoners are better served with passkeys.
But a secret in control of Google/Apple/Microsoft that can be backed up is not a secret I control: it's a complete step back from yubikeys.
Passkeys won and we better get used to them (and, yup, there are usability issues as you mentioned).
Why not just use a passkey backed by your Yubikey?
As an IT manager weak and/or re-used passwords are an absolute scourge. Ideally every time you set a passkey you'd also add an OTP Authenticator factor as fallback. Passkeys are incredibly useful and relatively secure when pair with biometric authorization (touch/face ID). I agree with a lot of the points about consumer level use, but still think they're net positive compared with bad password (re)use. I'd advocate for email recover as a decent fallback, but there's only so much you can do when the average user won't establish a base line of security for their primary account and access point.
Security is frustrating and it's hard to get people to do the bare minimum to establish secure access to their services.
> how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.
I agree with you 100%, although I will say that it seems like newer OSes (perhaps it depends on the desktop + mobile combination, or maybe Chrome + Android is enough, not sure) have a way for you to use a passkey from your phone by scanning a QR code. I still think it's not super user-friendly but it is a clever workaround at least. Most people are accustomed to scanning QR codes, so scanning a QR code from your phone to sign in seems like not too big of a leap. (Although I wonder if it conditions users to scan random QR codes to sign in which could be a bigger phishing problem lol...).
This. My simple brain is always like...."This passkey is going to be lost and only usable on this machine and I don't even trust that to work consistently because I do weird stuff sometimes"
> But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own?
at least in Apple land, if you try to sign on on a device that you don’t own (let’s say a work laptop where you’re not signed in to your apple id) it’ll give you a QR code to scan with your iPhone and it’ll do faceID on your iphone then do some bluetooth handshake to use your passkey on the other device. I’m not sure if this is Apple exclusive or if android/windows/linux would be able to do the same
Other OSes can do the same.
I’m a big dummy who commented before reading the article, this is actually called out there
> The last option is to use “Hybrid Transport”, where you scan a QR code and connect via Bluetooth simultaneously to the computer. Whilst this option is secure and works in theory, reality is plagued with edge-cases where connections fail or Bluetooth is straight-up unsupported.
I haven't articulated my thoughts about passkeys nearly as eloquently, but you did an amazing job here. This really sums up a latent problem I've had with passkeys.
Do you have a blog?
Passkeys are awesome if you're one person, with one account, on one device. As soon as any of those three aren't true, they're a huge pain in the ass.
> people who re-use passwords and/or don't use a password manager.
So the vast majority of all humans on this very planet?
I have a passkey on CVS, but that YubiKey was eaten by the sewer.
Thankfully I can still log-in with a password & text. But how to reset the passkey? No-one knows.
Edit: I take that back, for some reason they stopped taking the password I used when setting up the account. It's only email or SMS with code verification + birth-date.
In the Apple ecosystem this is trivial - you select to sign in using a QR code which you scan with a device you do own. It works perfectly in my experience (of using them wherever possible for several years)
> how do I log in on a device that I don't own?
You scan the qr code from your phone and it logs you in on that device. The experience is pretty amazing, honestly.
They mean if you dont have access to your devices.
What if you don't own a phone?
iCloud Keychain? Is there a reason not to use it? Aside from having android.
go back and figure out how to undo it
There's an undo? Could you elaborate?
Except this isn’t true?
I use my github passkey on my phone to log in on my laptop by scanning a QR code. “My” laptop for work, which I wouldn’t put said passkey on.
[dead]
The point about poor support for 3rd party managers is so frustrating. Because this is correct, that is the obvious solution for the normal user, but passkey implementations somehow do not know how to deal with it.
Amazon prompts me to create a passkey everytime I log in, even when I logged in with a passkey, because my passkeys live in Bitwarden rather than my OS or browser.
And the confusing mechanism hurts there too: I'm always a little bit afraid that i'm somehow more in danger because I keep them in a vault that's shared on all my devices rather than a TPM, because whenever the protocol is explained the "it can't leave your device" part is highlighted as the main source of the security, except.... mine obviously do leave my device, with the vault, so.....
Yet, the Apple + Google implementations will sync passkeys between your devices. "Securely", of course. (I've seen first hand how Apple implements this, and it seems.... sound)
Sites can request hardware-bound tokens, which would block any software based password managers. It's an option in the protocol but one not yet widely utilized.
Which is a problem.
It should not be in the protocol. And I don't trust Apple and Google not to lock it away from me.
I want my own open source manager and if that is attempted I want it to lie about it.
I am torn on that. It seems fine for a corporate site to be sure employees are using their company issued tokens to access company data.
It does not seem fine for any other site to do this.
This may be the only place where it would be good with a software patent: corporate would not mind having to pay 10 usd/user/year, Google would never.
Lying about it may become impossible in the future when you throw hardware key attestation into the mix.
https://developer.android.com/privacy-and-security/security-...
FIDO authenticator attestation is dead for consumer-facing RPs. Apple made the right call and simply refuses to support it outside of MDM environments.
Can we try to play nice now and recognize that other people have diverging, but valid, interests from your own? For example, securing things?
Passkeys are not about securing things.
The entire value proposition, and the reason big sites are pushing them, is they take the user out of the loop of authentication. You are no longer authenticating the user, you're authenticating the users device.
For websites you don't have to worry about cookie theft and dealing with the support load of users needing their accounts reset or dealing with fraud. You can also do some level of attestation to hardware which makes automated account creation more difficult.
For the user it offers no additional benefits. You still have something secret that gets presented to a website to login. Password managers solved this problem. But now for some reason you can't log in when you buy a new laptop.
It is playing nice to criticize things. It's not just "different priorities", passkeys have intentional trade offs which cause them to be "more secure" but in ways that users do not want because it negatively affects them. The intentional trade off made in the name of "more security" makes them wildly inconvenient and risks causing massive lockout. Like removing all the staircases from people's homes and replacing them with climbing walls all in the name of "security". You can't just diffuse that by say "well we want banks to be more secure, we have different priorities."
I am already seeing my "normie" friends getting locked out of accounts due to not understanding passkeys. If they don't have their phone, or it's dead, or it breaks, or is stolen, they just can't access their account anymore. They have no idea how they work or what they're trading off, nor do they understand that they should have prepared for this scenario ahead of time somehow. Upon telling them "yeah you have to use your phone now that you have a passkey" they all universally say "wtf, that's stupid, I never want to have that happen again, I will never use a passkey again."
Passkeys should never have been built for general audiences, they are a huge mistake, I hope they cease to be relevant and die due to everyday folks realizing they're inconvenient and the "more secure" gains ain't worth it for the usability nightmares.
"I am already seeing my "normie" friends getting locked out of accounts due to not understanding passkeys."
In a weird way this is good news for us. If people are losing passkeys, getting locked out, and incurring non-trivial support costs as a result to the relevant companies, then there's no way those companies will crank down even harder by requiring hardware keys.
As an option, I don't mind it existing for situations like a work environment. Work environments are so much easier because there is a clear line to get my credentials reset, from scratch if necessary, even if I lose everything. The problem is that the consumer authentication case is even harder because it lacks that clear line without also creating a backdoor.
So I insist on centralizing my passkeys into a password manager. I have no passkeys outside of my password manager and will continue to reject them. If it's important enough to slap authentication on, it's important enough for me to not lose it because I couldn't choose where to stick it, which is in a basket that I protect very, very carefully.
Honestly I just don't see how something like Amazon could ever turn on the "require hardware key" feature without blowing their own foot off, or really any consumer-facing service. Everyone loses keys. To a first approximation nobody is going to buy three keys and correctly manage setting up all of them to work with every service. Even if we magically stipulate that all sites support it and they all have some integrated unified approach so that there's no software-side friction at all to register all three at once everywhere, you just get too many people who stuck all three keys on one keychain, people whose houses burned down, people who so successfully stored both backups "securely" that they have no memory of where they are anymore or how to get them back, an endless parade of lost keys. The consumer as a whole is not capable of managing hardware keys.
Given how often my household loses its second car keys for extended periods of time I am not exempting myself from this. My work key lives a much simpler life... it just sits in one place, doing work things. My family would hardly last a month if everyone had to carry around physical keys to log in to things.
Why should I recognize that as valid interest, when it's straight out hostile to me? I know why they are doing that. It doesn't oblige me to accommodate their selfish interests.
So is there a problem with Apple or no?
I'd absolutely never trust Google to manage passwords/passkeys for me, with their habit of irrevocably auto-banning accounts. Apple seems... better? But that's today. That could change, and then you'd be screwed.
You're not limited to a single passkey by the spec or 99% of sites that support them. The limit is arbitrary and typically when a limit exists it's no fewer than 3 (very rarely 1, but I've only seen that once that I can recall).
I generally add three, one for Bitwarden (my actual password manager), and then the OS passkey store (Android/Chrome password manager or iOS/Apple Passwords depending on the device).
I'm not qualified to say yes or no; but I will say that Apple's tends to make design decisions that try to empower the user as much as they can while still being easy to use, and have more or less maintained that position.where as Google, on the other hand, started as "open" and "you can do it all on our platform" to "we're taking away your control and choice little by little, in order to 'protect' you". Oh, and you hear more about Google perma-banning your account for no clear reasons, than Apple...
> Amazon prompts me to create a passkey everytime I log in, even when I logged in with a passkey, because my passkeys live in Bitwarden rather than my OS or browser.
What setup are you using? Because I don't have that problem on Linux + Firefox at all
Linux, Mac, and Windows (i happen to use all three regularly for work, hobbies, gaming), Firefox + Bitwarden.
It's totally possible there's something specific about my situation, or the way it was set up in the first place that enables this, idk, but somebody else replied saying they have the same experience so it's not just me.
And even if it was just me, it's still clearly something wrong on the provider's implementation, because it should not be possible for software to sidetrack the user into a passkey enrollment flow, when that user logged in with a passkey to open the current session.
I will take a wild guess (based on that you are using firefox) is that you probably have enabled the various don't save cookies, clear sessions on close or other hardened privacy settings that are the source of 99% of problems firefox users encounter, like increased cloudflare captchas .
Could be! I don't recall turning things like those on, I use firefox for features not privacy, and mostly leave stuff like that at their defaults, which I trust Mozilla + uBlock to filter the invasive trackers while leaving actually useful functionality, but it's possible I fiddled with it years ago and forgot.
Some probably kinda strong counterevidence to that though is that this doesn't happen on all sites, only Amazon. I've never been prompted to make a new passkey after passkey login on the 12 other sites that I have passkeys in bitwarden for.
Very strange! Whatever the bug is, I hope Amazon fixes it.
It's quite crazy to just surprise a user with a passkey in any event, even if they get saved and don't reprompt you. Suddenly spawning an OS popup without any explanation, which may or may not try to ask for biometrics, is crazy.
> Amazon prompts me to create a passkey everytime I log in, even when I logged in with a passkey, because my passkeys live in Bitwarden rather than my OS or browser.
I haaaaaate this. And every time I'm like, "do I not already have one??" Passkey implementation has been half-assed by everyone.
I don't have any issues using Bitwarden as the default password manager on any of my devices, except the occasional Android/Google issue with apps where it opens the Chrome passkey store and doesn't prompt for Bitwarden.
But websites pretty much universally trigger the Bitwarden passkey prompt, or I can bypass via the popup and go to the OS passkey manager.
> Amazon prompts me to create a passkey everytime I log in, even when I logged in with a passkey, because my passkeys live in Bitwarden rather than my OS or browser.
I use 1Password and Amazon does not prompt me like that. However I do have two passkeys for Amazon, one in 1Password and one in Apple Passwords. There's not enough data yet to say if it happens to you because of something not working right between Bitwarden and Amazon, or something about Amazon doesn't work right if you don't have a passkey in your OS passkey store.
Might be worth adding a passkey for Amazon to your OS passkey store and see if the problem goes away. If it does, blame Amazon. If it does not, report it as a possible bug in Bitwarden (altough it still could be an Amazon bug that just happens to mess with Bitwarden but not 1Password).
It's amazon, I have 1password and it always asks me to create another security key
While the technology itself may be great (I don't really know since I don't use them) it has been co-opted by the tech conglomerates as another form of isolating and walling off users into their ecosystems.
And honestly, nowadays, if tech companies are pushing really hard for something then that is an immediate red flag for me and it bears more scrutiny. One of those "if you see them running that way you run the opposite way".
Exactly. That's why I'll never use passkeys: they're just another way to force us into a commercial walled garden.
Passwords with 2FA are simply better and more freedom friendly.
I store my passkeys in KeePassXC and I have absolutely no feeling of being walled into any garden, personally.
but what do passkeys offer in terms of security, when stored in password managers, compared to having a (password manager) generated password and a totp?
I believe that by allowing password managers to store passkeys, the whole purpose of "device based security" got lost..
They are 100% immune to credentials phishing. You literally cannot authenticate to an impersonator site based on cryptographic guarantees.
And yes, I know the happy path of password managers uses host-based autofill which does add some friction to phishing attempts, but given the prevalence of unexpected but legitimate urls with weird alternate subdomains/SSO/redirects in modern login flows, you have to manually autofill/add an exception often enough that it's possible to let your guard down once at the wrong time.
Yes. I use hardware based passkeys and absolutely love them. I think it was a giant mistake having them 'software' based. It some ways it kind of defeats the entire purpose...
Wait until websites start demanding device-bound/attested passkeys. Big tech just needs to get enough adoption to make this change.
Nobody is going to do this because Apple’s devices don’t support this for the Passwords app out of the box, by design.
As much as I hate to admit it (because I love passkeys UX), but I do think that device-bound/attested passkeys are going to happen in the future :(
UPD: oh, heck, attested passkeys are actually already in the protocol. Why can't we just have nice things?
I just bought a passkey... It's a USB device, completely separate from any big conglomerates.
But then you need to phisically carry it along with you everywhere you go, if you want to log into a service :/
Yes, it’s like a key. :)
Though realistically I use a passkey for services I care about and a password manager for the rest.
Keys can be copied very easily. It’s one of their primary features. Can you easily copy your USB key?
Physical keys can easily be copied, and physical locks can easily be picked. That might be fine for your house or storage unit, but for your bank account or your car (newer cars no longer have simple physical keys/locks), we've moved beyond that tech.
That any and all physical security measures can be defeated is a feature, not a bug. Almost no human beings actually need that level of security, and the tradeoffs are absolutely not worth it for those of us without Mossad as a threat.
How often do people lock themselves out of their own house? Don't you know anyone with ADHD? Imagine any time that happens it is mathematically verifiably permanent as a fact of reality itself. It doesn't matter that the state still views you as the legal owner, you are never allowed in ever again.
No web service is like that. They all offer recovery options. We aren't talking about Bitcoin here.
The trend of companies becoming easier to contact and customer service becoming better is well-documented.
Tell that to the people who have lost access to their Google account.
Now we aren't talking about a security problem, we're talking about who really owns what. Google can lock you out of your account no matter what kind of authentication they use for that account
It's a lot easier to be locked out with a passkey than without one.
No it's not. Google flips a bit in their database and no matter what kind of authentication you set up with them, you get denied
This does not reflect my own lived experience.
But if true, that means that Google can choose to not provide you a recovery service, which is functionally the same as them not having it.
I'm not even sure what your point is anymore. If Google decides they don't want you to log in anymore, you can't log in anymore. It doesn't matter if you try to log in with a passkey, a password, your fingerprint, or sending a secret code in with carrier pidgeon. This has nothing to do with passkeys vs passwords vs anything else.
If Google does want you to be able to log in then they will work with you to make that happen, whether you forgot your password, lost your passkey, or your carrier pidgeon died.
Passkeys are not special in this regard at all. What does make them special is that nobody can use a phishing attack to steal your passkey and log in to your account. Nobody can guess your passkey and log into your account. Nobody can intercept your passkey in flight and log in as you. That's the important distinction.
Yubikeys are Secure Enclaves designed to not be copyable
Right. That's the flaw I was pointing out.
You can 'copy' it by registering a new one to the service.
That's not the problem for me - I carry a bunch of tokens with me anyway (all my banking stuff is on hardware tokens, for example). My problem is more: My browsers run in containers or VMs, intentionally without hardware access. Getting passkeys to work there would be quite a bit of effort.
And hope you don't lose it, or leave it in a pocket when you do the laundry, or plug it into a faulty USB port that zaps it, etc.
My yubikeys have survived dips in the ocean, spilled beers, run over by cars, dropped in pans of used motor oil, left out in thunderstorms, and multiple trips through the washer and dryer. They're still fine even after a decade.
Nothing survives the xkcd 538 wrench attack.
How do you see passkeys as a walled garden but not 2FA? You presumably store your 2FA seed in a password manager.
I can write my own authenticator implementation in a few hours by hand, maybe 5 minutes vibe coded. https://www.rfc-editor.org/info/rfc6238/
Even if you throw your phone into a volcano and buy a new one, you can still receive SMS verification.
KeePassXC supports passkeys
Passwords can move between walled gardens generally very easily (export) or manually in all cases (enter by hand).
Passkeys only very recently got relatively broad support for migrating data (after years of promise and no support at all), and they report (optionally with hardware attestation) what password manager you're using so sites can force specific ones.
I did a deep dive on this since progressively more places are taking a hard line about Passkeys.
The most flexible, independence preserving thing to do is to use a third party password manager like Bitwarden, and make that the default passkey flow for your devices. If desired, you can self-host something like Vaultwarden so that you can both keep the keys independent of third parties and walled gardens and also propagate them to other client devices.
To be clear I'd much rather not have learned / implemented any of this, and I don't use passkeys unless forced, but this seems like a valid coping strategy.
It’s a bit ironic that Apple is the one that lets you export them.
They're also not supporting device attestation which would allow websites to insist on particular implementations of passkeys.
That's more because attestation breaks their passkey cross-device sync process, rather than out of benevolence.
But only to other approved apps
Not as far as I’m aware? They of course require the target app to be compatible with the way they export them, but I don’t think they vet them manually. At the very least, on my phone, the apps it agrees to export to include Chrome and Bitwarden (the latter of which lets me export them further).
> And honestly, nowadays, if tech companies are pushing really hard for something then that is an immediate red flag for me and it bears more scrutiny.
The reason is the ever increasing number of hijacks of social media presences and code hosting portals, with the latter being a serious financial threat. Done right, passkeys stay in the Secure Enclave, at least for anything Apple and most of the Android sphere. There is no reasonable way to obtain login credentials for accounts protected by passkeys without physical access to the user's device(s).
The doubt is more "how will tech companies use passkeys as an excuse to do something stupid" than "passkeys themselves must have inherent problems because tech companies are pushing them".
Passkeys could be the savior of all security problems worldwide from a capability point of view and tech companies would still ruin it by trying to force ways it pushes you into their ecosystem instead of just being whats both secure and convenient.
As an example, I have 3 different passkey _APPS_ on my phone and cannot go down to one because of various reasons with each (such as MS authenticator, forced for integrating to Microsoft at work).
> There is no reasonable way to obtain login credentials for accounts protected by passkeys without physical access to the user's device(s).
Click "I lost my device", enter contact, get a reset link via email/sms
Email and SMS are not reasonable and both have an extraordinary number of flaws.
So use the recovery codes. Or scan the QR code and auth from another device
I’d buy that there are too many different confusing ways to recover from this situation, but not that it’s impossible
>use the recovery codes.
Fun fact: Google can decide to reject these. Lose access to the original device, try to rely on recovery codes to login with known current password on family member’s device… nope!
Wait, so I set up 2FA, printed the codes, but now if I ever lose my phone or it's stolen I'm screwed?
I guarantee you this is within the realm of possibility based on one single experience.
When you upgrade your phone perhaps keep your old one in a safe and charge it and login to Gmail monthly or something?
I’m also quite certain the codes could work instantly with no trouble in some circumstances. Now know it’s risky though. And I’m sure it’s a security measure based on real, deeply painful and costly instances of unauthorized access. Just don’t know what we’re exactly supposed to do…
Google gives you no guarantee of service for your account. They could arbitrarily decide to lock you out for any reason and you have literally no recourse.
Sure, yet in the real world those are the acceptable means if you want your customer to continue to pay you when they've lost their phone.
[dead]
Very solid points, and I love the focus on the fact that passkeys are addressing threats irrelevant to regular people, while ignoring those that matter. But I think it's still incomplete, because it's missing the biggest blind spot in design:
Password sharing is a feature, not a bug.
Security industry failed to implement the most basic feature one does with access control at individual level, which is delegation of authority. Physical security in form of "bearer" devices, such as keys, credit/debit cards, transit tickets (except those newfangled ones bound to photo ID), etc. all support this by default.
Ad-hoc delegation of authority is a normal thing to do, something we do all the time without thinking. Asking your kid or friend to do groceries for you? You hand them your debit card and give the PIN. Need a nanny to walk your kid from school and stay with them until you're back? You make them a copy of your house keys.
This carried over naturally to technology realm. A colleague needs to get some data that happens to exist only on your machine, while you're away? In normal non-corporate places, you just write the password on a post-it and give it to them, or put it in a drawer and tell them to go look there.
Security industry failed to provide a reasonable alternative path for over four decades now, and instead continues to deny the very existence of the need for ad-hoc delegation of authority. Passkeys are a bad choice for regular users largely because they're designed to prevent delegation - on top of the other issue, that the author correctly recognized, which is that by far the biggest threat to regular user is that of loss of access to account.
On a system I'm designing, you can provide a 2nd (or 3rd, 4th) password, which affords an user of said username/password combination a subset of the permissions _you_ have, which stops working after a date.
This has made multiple product owners cry. I am wondering if it would make sense to add a 2ndary action prompting the user at the eol for this secondary credential asking them if it went fine, to try and collect some information on how popular the feature is.
Oh cool. Would you mind expanding a bit on the implementation? I have been thinking about a generic auth system like this for some time.
That's nice and I applaud you for attempting to solve it in a user-friendly way.
Sadly, because that'll come off as unusual to 99%+ of your userbase, you'll probably face challenges explaining this to the users, and it'll skew statistics you gather here. Chicken and egg problem, really :(.
>passkeys are addressing threats irrelevant to regular people
phishing is very relevant to regular people
Not really that much in comparison to losing access when needed. It's relevant to corporate employees, where phishing is worthwhile to attackers, while losing access means creating a ticket on internal helpdesk and having rest of the day off.
corporate employees are typically regular people, and where phishing resistance is most valuable.
if by regular people, you meant "in someone's personal life", i would say phishing resistance is still relevant but agree that loss of access becomes a bigger risk to balance
> if by regular people, you meant "in someone's personal life"
Right, this is what I meant. I used "regular people" as shorthand for that, which I see wasn't a good choice. Next time around I'll be more clear.
Don’t you remember the giant phishing campaigns like back when lots of celebrities got their nudes in iCloud stolen and published? These things happen all the time, and are incredibly painful. Much, much more so than being unable to share your account with a coworker.
> ...when lots of celebrities got their nudes in iCloud stolen and published?
Right-- high-value victims of targeted attacks. So not regular people.
Regular people get their data stolen all the time, you just don’t hear about it. Just look at the credential dumps and the most common passwords.
I don't get the sense that regular people get data "stolen".
Ransom is the only thing I see happening to end user data.
Credential thefts facilitate theft of money. It might might help the attacker to rifle thru somebody's data to find information that helps answer "secret" questions, to trick friend and family into getting phished, and maybe blackmail, but I don't see a market for end user data that would drive data theft. Nobody is buying end user photos, videos, email, etc. (Anybody who would possibly buy it just tricks/entices users into giving it to them for free to train their AI models anyway.)
LLMs ironically are changing this[0], but at least until now, rifling through random people's data did not scale, so aside for a subset of cases where it was possible to automate access to some services or otherwise leverage them into a scam on the cheap, it wasn't of interest because there was literally nothing useful to do with it.
--
[0] - LLMs, whether multimodal or combined with modern AI-driven STT / TTS pipeline, enable running highly personalized scams cheaply and in an automated fashion, which does scale up and suddenly makes this data important. But that's a very new consideration, one which passkeys were not designed for, because it literally was not possible or conceivable even few years ago.
At the scale you'd expect that to happen, looking at credential dumps, you'd also expect to hear a lot about it.
And yet, you don't. Which leads me to the conclusion that the data dump are overblown.
I think companies around the world come to the same obvious conclusion, which is why these data breaches keep happening, and the companies whose systems were breached are never any worse for the wear.
All true, but there's a wrinkle with delegating auth in computer systems--the same wrinkle that comes up when thinking about digital data as property/copyrightable etc.: when you delegate auth, you copy the access; you don't loan it. So every digital delegated-auth scenario is like your "make a copy of your house keys" example, not your "loan out your debit card" example.
If we extend the metaphor, this would be like making a copy of your keys and handing those out every time someone other than you needed access to your house. Dinner guest? Key copy. Neighbor dropping off a borrowed tool? Key copy. Relative from out of town visiting? Key copy.
In the same way that I think most homeowners would look askance at passing out so many copies of their keys, delegated digital auth is troublesome. Nontechnical users are unlikely to pay attention to "what clients are using delegated credentials for which actions" dashboards. Revocation, while technically easy, isn't something that I think most casual users will be mindful of, resulting in endless growth in the list of principals with access to a resource (just like the "sharing passwords" scenario we have now). Time-based auto-revocation will be an annoyance for delegates who only need to access a resource rarely, resulting in exasperated administrators rubber-stamping new-delegate-credentials requests.
I don't know if there's a good solve here. Shared passwords might be the local maximum of convenience and security, but that feels pretty bad.
You can add multiple passkeys in the vast majority of websites that support them. There's nothing in the spec that prevents or discourages allowing multiple credentials. I do it on every site I care about so I can fallback to the OS passkey store if I lost access to my Bitwarden account for whatever reason.
Much like with 2FA apps, most of the sites I've seen - including big names - support only one app and one passkey at a time.
I respectfully disagree with the author!
Passkeys have been a massive quality-of-life improvement. Yes, there's the minimal risk of lockout if you lose access to the passkey (though almost every site I've used that implements pk's lays it on top of their traditional user/pass auth flow), but generally speaking most people use iCloud or their Google account to store their passkeys, and because those sync everywhere, this isn't a real risk.
I love not needing to deal with 1Password's autofill being flakey and having to CMD-C/CMD-V passwords/passphrases/OTPs on these sites.
I like Yubikeys as well but they are super inconvenient by comparison when dealing with multiple devices. Setting them up is also very user-unfriendly in general; doubly so compared to passkeys.
Now, what I'd REALLY F'IN LOVE to see go away is the passwordless/magic link auth flow wherein you authenticate by clicking a magic link that gets sent to your email or text message inbox.
"Emails are super easy to hack and we're still not sure whether text messages are safe to send on US carriers, so let's have everyone click on a link sent by email or text so that they don't have to deal with those pesky passwords that iOS or Android will automatically suggest for them." Like, what?
> Emails are super easy to hack
Source? And if somebody hacks my Gmail account, won't they be able to access my Google-synced passkeys?
Magic link auth isn't any less secure than any site that has a password-reset flow.
A family member installed an app into their Android phone from the Play Store.
It was innocent enough until it asked for a truckload of permissions, like being able to change the launcher, which they ofc tapped "Allow" to since permission request fatigue is real and still a bit of an unsolved problem.
So the app delivered on its promise and changed their phone's launcher. It had a fake Gmail widget that showed them their mail but, of course, wasn't actually tied to the actual Gmail app and was an easy way of getting a refresh token for their account.
Bingo bango bongo: their email was now at risk.
They changed their password after I told them to right away upon them asking me to look at their phone because "it was slow."
> Magic link auth isn't any less secure than any site that has a password-reset flow.
Which is exactly the problem. Cloning someone's SIM/eSIM and immediately performing password resets is a well-known security issue.
If you are blanket accepting permissions passkeys do nothing to fix the attack you describe (on device phishing).
> Cloning someone's SIM
Yeah I don't trust SMS either, that's why I said email. You can do a lot more to protect your email account than your phone number.
It's very disconcerting to think about how many malicious apps like that must exist in the Play Store, but again, gaining access to someone's Google account is still game over if that's how you're syncing passkeys.
> what I'd REALLY F'IN LOVE to see go away is the passwordless/magic link auth flow
This seems really naive? That's the only flow that's at the basis if you get locked out. What else, do you put people on the phone to verify people by asking their name and date of birth? That's even worse!
I think they're referring to sites where that is the only way to sign in, which I have seen a few of. Basically you can never register a password or passkey, every sign in requires going to your email and waiting for the link to arrive.
I've seen Slack and Claude doing this among others, it's turned into one of my leading red flags for untrustworthyness.
I get the idea. If email links are secure enough to use for password resets, just do that every time. Then you eliminate a whole category of password attacks.
But it’s definitely annoying for a frequently used service.
Maybe this gets us closer to some idea of email being a more protected digital service, that has some legal guarantees?
Putting the potential negatives under the rug for a second…
I would be nice to have email that (1) you can’t get locked out of arbitrarily, (2) acts similarly to US mailbox (in its protections and universal service), (3) acts as an identity
Is this a bad idea?
Only if it's run by the state and free for every citizen. Forcing more bureaucracy on email providers will just make everything more centralized under Google and Microsoft.
It should be a mailbox with E2E encryption where the keys are stored on your ID card. Backups stay on secure servers that are legally protected from anyone including the police and only given out when you're getting a new ID at a government service center, encrypted with the cards public key so a hacker in the card issuing system can't steal it.
Every user gets a persistent address used as their identity, and any number of anonymous ones. Locking someone out would be both illegal and inconvenient for the government if all their official business is going through the mailbox.
Horrible idea. This will require every email vendor to certify with every country they provide service to that wants to do something like this, which will pretty much kill any small/indie email hosting providers.
I'd much rather have stricter legislation around password resets built into existing reg frameworks like PCI or HIPAA. If you store a form of payment or PII with a provider, then some form of human verification should be needed to perform a password reset.
A German neighborhood social network uses this, and I prefer this over all other sites I visit that have passwords.
I only need a new login link when I switch to a new browser or device, so it's not really annoying at all.
I do it for small projects with about 10 infrequent users. They would ask me to reset it almost every time anyway.
Though next time I'll probably try oidc if I can find a common provider that isn't a hassle
Untrustworthy... yes.
I get more annoyed by the timeout it adds. Logging in 10 years ago? A thing of seconds.
Logging in today? Either magic links through mail (delivered to you within the next 30min thanks to graylisting or spam filters) or a login flow with requires 5 dialogs and 5 confirmation of "no, just log me in".
I think all Shopify sites also do it now? I'm migrating password managers and have been going over all of the old accounts I've had. Several sites that use Shopify for their stores now just don't accept any kind of a password.
I despise that too. One website (was it walmart?) gives me option to use that or a password, I select password and after entering it it tells me that it needs to verify my e-mail "for security" where I get link or code to log in.
At that point what's the point of password? Just an optional extra step?
Correct; that's what I'm talking about. Sites that send you a link first before letting you enter a password (Spotify) are also on my bad list.
I mean, if the session token basically never expires it's kind of fine?
For services that have your PII or payments details, yeah, that should be the only way to do a reset. Super inconvenient but much less so than dealing with stolen identity or credit cards.
Majority of websites use email to authenticate (“forgot password” flow). Passwords/passkey is just an optional convenience for quicker login.
Yes, at this point I have probably saved literal hours in time added up by being able to skip MFA prompts on sites/apps I use regularly via a passkey login flow. It was becoming ridiculous how often I'd hit a "verify who you are with your phone/email" gate even on services I use constantly, a gigantic waste of time.
> Yes, there's the minimal risk of lockout if you lose access to the passkey (though almost every site I've used that implements pk's lays it on top of their traditional user/pass auth flow)
Exactly, if you lose your passkey you just sign in with your password like you did previously. I'm yet to find an app/website that has passkeys only and no passwords.
Seems like a total non-issue to me.
One of the big benefits of passkeys is that you can completely remove the ability to log in with a password!
Just spitballing here, but it seems like a good mix of phishing resistance & lockout recovery would be to have passkey-only auth, but with email recovery.
So no password login, but then you can recover your account by adding an additional passkey by receiving an email.
Just make sure you don't lose the passkey to log into your email.
Isn't it the same as my password manager's vault? I only remember my master password so if that vault is lost I can't even log in to my email
Kind of, but I have some of my most important passwords and account recovery codes duplicated on paper in a secure place. If there was ever a service that only allowed passkey login (do those exist?), you can't print those out.
I'd still prefer password+2fa+backup codes for email.
I wouldn't be okay with that. Say you're setting up a new iPhone with a new iCloud account because you forgot the password to your old one. (Unlikely scenario amongst us nerds, but very very likely outside of our bubble.)
If you want to log into, say, Google, but the passkey flow is the only way in, then you're almost-completely SOL unless you have some way of getting the passkey out of your iCloud keychain and into the keychain of the phone you're setting up.
If you still have your old phone, you can scan the QR code and get in that way. If you don't, then you're completely SOL.
Ok, so the big security risk that passkeys are supposedly designed to stop, is actually still there?
If you can still be phished, remind me what the point of any of this was, again?
Ignoring any supposed security benefits, personally I use it because it's much more convenient/ faster than logging in with a password since.
You're still slightly less likely to get phished if you only ever login with passkey and only use the password in case of lost passkey. Of course you could get phished that one time but entering your password once (maybe never) has got to be better than entering it daily.
I don't have any passkey accounts where I didn't start off with a password and after adding a passkey the password login method was always retained. What services are people using where you don't need to set a password?
> I love not needing to deal with 1Password's autofill being flakey and having to CMD-C/CMD-V passwords/passphrases/OTPs on these sites.
But that requires that website implement support for passkeys, and is that easier than just implementing a login form that doesn’t break password managers’ autofill?
Low risk of lockout, but about as high-severity as one can imagine. Yes in theory sites should offer a password fallback, but how many actually do? And of those that attempt it, how many get it right?
Not even Google reliably lets you fall back to a password, according to the comments in this article. Losing access to your google is anywhere from major inconvenience to professional disaster.
Expecting every user (site using passkeys) to implement complicated flows is a time-tested recipe for disaster, and it's a bummer to see that unfolding yet again with passkeys.
>Not even Google reliably lets you fall back to a password, according to the comments in this article.
I logged in with my google password (on my TV, the other method using my phone wasn't working for some reason) the other day even though I normally use a passkey from my phone or computer. It worked just fine.
Sometimes it works, sometimes it doesn't. I've had Google block my login because it was sus (it was a new computer or something...) and they wanted to verify a whole bunch of information. If you haven't given them that info, you just get locked out.
To the day where your device breaks, you had set a passkey to access your Google account (because the phone did prompted it up and you did not understand and clicked yes), you did not setup a recovery method (such as another email/SMS) or you did setup a recovery method that still depends on the Google passkey access (e.g. a second email account where you sign in with Google or has Google as a two factor verification!) and you are locked out of your Google account. Good luck at that point contacting Google assistance, you may as well consider that account as lost forever since there is no way to talk with an human being.
And unfortunately is something I start to see to family members/friends that are not tech experts when they ask me to setup them up a new phone... at least the passwords they would have written them in some notebook that they had at home, or always used the same for everything, but with passkey... and when you tell them that they lost access to their email, possibly the files backed up to Google Drive/Google Photos, etc they are surely not happy.
Also passkeys makes it difficult to get access to your account in an emergency scenario, what if I loose my phone and I'm not signed in to other devices? Maybe I've setup an SMS as a recovery method, but first I have to get to my phone company to request another SIM card, maybe I'm on vacation on the other side of the earth in vacation for 2 weeks, I'm locked out of my Google account, and from all accounts that uses the passkey as a sign-in method (including, for example, the account that I need to use to check in on my return flight, or my banking app that I need to pay stuff!)
Partner's mom lost phone. Partner called me with mom's password. I went to Find Hub. Entered email and password. "Hold on, we're sending the lost phone a verification text."
> and because those sync everywhere, this isn't a real risk.
Do they sync between Android and iPhone devices?
I wouldn't even know how to sync any of those to my Linux PC.
> those sync everywhere, this isn't a real risk I hope your main account at one of these two providers gets banned for whatever reason so you'll never utter such frivolous claims ever after :)
I'm in the same spot. It seems like every month a post pops up here that's "I hate passkeys" and most of HN seems to agree.
I use 1Password, but passkeys have made things even easier. I'd rather have them than any 2FA method. So many websites make me use a login/password AND then send me an email or text with a code. Every. Single. Time. You're really telling me you would rather do that than have a passkey?!
And, like you said, passwordless email auth is really terrible.
I try to boycott passkeys due to built-in attestation feature in the standard. Not active now, but given how Google+Apple already use the passkey feature to lock you into their ecosystems, it is just a matter of time until their service will require that the passkey is attested from a non-rooted Google or Apple device. I think this will especially be true for Google to prevent AI scraping bots. Turning this on does not require anything, once passkeys are widely used, Apple, Google and Co. simply can flip a switch.
> Not active now, but given how Google+Apple already use the passkey feature to lock you into their ecosystems, it is just a matter of time until their service will require that the passkey is attested from a non-rooted Google or Apple device.
I'm with you 100%.
There will be evil and stupid uses.
The brain-damaged people who think disabling paste on password fields is a security feature will be all over forcing device-attested passkeys as soon as they learn about it.
Evil people will see it as a proxy attestation of humanity.
Either way it will be rammed down our throats if passkeys are widely adopted.
My favorite FireFox plugin : https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi...
I imagine that's why they're pushing them so hard, especially given Google's recent anti-user lockdowns. I have a hard time imagining they'd expend so many resources to protect a tiny percentage of users from having their accounts hacked...there's no way they actually give a shit about that. Their bread and butter is instead protecting the value of their product, which is their captive userbase.
Apple and Google don't need the passkey spec to mandate that you only use their services from non rooted Google/ Apple devices. They could do it before passkeys existed, and they can do that right now if they wanted to.
What's any of that got to do with passkeys and attestation?
User convenience.
TIL about the attestation. Ohhhh, why can't we just have nice things?
I continue to avoid passkeys but it's becoming an incredibly dense minefield. Certain sites try to trick me into adding one each time I log in and I have to be careful to dismiss the 1Password prompt, then dismiss the chrome prompt, then dismiss the OS-level prompt (all back-to-back). It's so incredibly user-hostile.
The worst offender for me is the Costco mobile app. It's handy because it allows you to enter the store by scanning the QR code it displays on start up. However it also nags you to create a passkey. You can dismiss this by saying that you want to keep using a password. But then it nags you again next time. This behavior is problematic because the delay between opening the app and the "create a passkey" splash dialog (which hides the QR code) is exactly the time it takes to pull the phone out, open the app and present the screen under the reader at the door. Every single time I need to look back at the phone screen to see why it didn't scan, dismiss the passkey nag, bring up the QR code again, scan.
Wow, we live in completely different worlds. I don't remember seeing a single passkey prompt. I basically only login from my Linux desktop using Firefox, do I assume my software stack just doesn't support them?
IIRC last time I cannot access outlook email (the website one) without setting up and use passkey
They try to make it feel that way, but you can. Just keep pressing escape/cancel, then it shows an errorish screen but from there it lets you continue without one
I love your username. /)
Three of those four prompts are opt-in and configurable and aren’t the site’s fault, no? I disable the browser and OS password managers because I use 1Password… why do you have the Chrome and OS password managers enabled if you’re using 1Password? Or if there’s some reason you need them all available, at least rather than dismissing the prompts, why not add an entry to disabling prompting for a specific site in the 2 managers you don’t want to see again? All three support that.
On my phone I don’t see any way to disable the system passkey option. I have only 1Password toggled on in my settings but I still see the system prompt to save a passkey. It’s maddening. I’ll have to double check on desktop but I thought I had toggled off everything but 1Password.
Perhaps I missed something or perhaps it really is that user hostile. It wouldn’t surprise me in the slightest.
If any of them are configurable, I'm not smart enough to figure out how. I looked again, and I'm still not seeing anything. Even if it's my fault I'm seeing these, I still resent them.
Where do you have so many sites asking for passkeys? I’m desperately trying to have more but I have ~1.1k passwords in my password manager and only 63 passkeys!
It's the banks/Amazon/etc-type places that keep prompting me, coupled with random one-off websites here and there. When I upgrade my phone in a month or so I'm dreading the deluge of passkey requests I'll run into and having to deny it multiple times per initial login.
My annoyance with the prompts is not evenly spread over the sites I use, it just so happens the same sites that think short login periods = security (it does not) are also the same sites that think passkeys are the best thing since sliced bread.
I have such a low opinion of any company that logs me out every time I turn around and those are the same disrespectful companies that think it's appropriate to spam me with passkey requests when I login. My dislike also extends to those companies they have a "Remember me" or "Remember this choice" checkbox that is decorative, as in it doesn't do anything. Often paired with clicking external links in things like a banking website "Warning: You are leaving this site!", yeah, I know how the internet works, I don't need to be babied by a completely ineffectual dialog (if you think normies are reading that and not just clicking through, you are living in a fantasy world).
Interesting. For the GAFAM yeah, I got those. But for banks, in my country at least, I’m not sure they are even allowed to use passkeys. Instead we have a glorious numerical keypad where we have to manually click on the keys and the keys are never at the same place. I’d love to have passkeys instead…
It's usually the same site that keeps asking in my experience - they don't bother to remember your preferences
You lost me at "chrome"
lol, what on earth?
What is the confusion here? Like it or not (and I definitely don't like it), most people use Chrome.
YES. This exactly. I work across multiple devices, some of which are nonstandard/uncommon (Linux, Xiaomi China ROM, ...) and I've NEVER had passkeys work properly - yet everything constantly prompts me to add one. Even if they did work, I'd have to carry around hardware keys or register each computer separately. And the lack of backups if a device is lost/broken is definitely a larger concern for me than being phished of my TOTP keys.
My wife clicked through a Google dialog and suddenly was using a passkey. It absolutely happens, though IMO more to the non technical users. I know what those login dialogs and pop ups mean, and decline them.
(At least til I get around to setting up my new usb c yubikeys!)
I'm convinced that most Passkey adoption is accidental.
I'm convinced it's over 80%.
> lack of backups if a device is lost/broken
Same as traditional physical keys, you don't have a single key, you have multiple ones precisely so that if you lose/break one, you are not stuck and can go to the local locksmith and get another one in minutes.
In fact it's even nicer since you can just re-use the backup key with no security loss by revoking the other one, and buying another key.
> Same as traditional physical keys, you don't have a single key, you have multiple ones [...]
I have multiple identical ones.
> [...] and can go to the local locksmith and get another one in minutes.
Can I go to the digital equivalent of a locksmith (like a backup software) and duplicate my passkey? Can I do that with only my passkey in hand (without having to do anything to the corresponding lock, or having to contact its issuer), like I recently did with a physical key?
Heh, in the security world, this shows how your traditional metal key is "something you know" (like a password) because it can be copied and many people can know it at once!
So if we are enforcing MFA requirements and allow this kind of clonable key, then we should really require some other factor that is not clonable.
That's the core silliness of this whole passkey mess, IMHO. So many turns of rhetoric and weird compromises, we have cargo cult security and no real understanding of what security level is in place.
Instead of the best of worlds, we can accidentally have the worst of worlds without realizing until it is too late and we're painted into one of those ugly corners.
> Heh, in the security world, this shows how your traditional metal key is "something you know" (like a password) because it can be copied and many people can know it at once!
If you have a photo of a traditional metal key, you can duplicate it. AFAIK, there's also a numeric representation of the height of each position on the key; if you know that number, you can duplicate the key. A traditional metal key is more like a password than most people think.
For physical keys I don't need to ask permission to be able to make a second or third copy.
You don't need to ask permission to buy another key then register it to your self-hosted service.
In fact if you have the technical skills to make your own physical key and respect standards, e.g U2F, you don't even need to buy one and it will work with existing devices and services. I can recommend the Precursor for an interesting exploration of that from a verifiable software/hardware perspective.
It's not like physical keys at all. You can get copies made of those. Passkeys deliberately are not copyable.
You don't copy the keys themselves, instead you make multiple relationships with different keys. You can get as many or as little keys as you want. The point is the keys themselves are not important.
The keys are vital, and if you lose them you're SoL. A major hurtle is that you cannot create multiple relationships with different keys. Each key can only be used once.
> lack of backups if a device is lost/broken
That's not accurate. Bitwarden syncs passkeys across all my devices including both mobile/desktop (iOS/Android/MacOS/Windows/Fedora) using Chrome/Edge/Safari (I haven't tried Firefox).
KeepassXC is an open source alternative for cross-device synced passkeys. Marginally less secure than device bound passkeys but it's seamless and I save so much time now being able to login with one-click everywhere instead of wasting it on arbitrary "let's make sure you're you" MFA nonsense.
Passkeys have a marketing problem where no one is able to describe simply what it is without having to use technical jargon. There's also the problem where each OS tries too hard in pushing this to the face of end-user
> Passkeys are passwords your second device makes/types for you, without you ever seeing it.
My bigger problem with passkeys is how there's no universal way to register more than one device (in case the first one is lost).
This burden is on the site using passkeys. There should be some equivalent of “My Account > Security > Passkeys > Add Passkey.” There often isn’t, which is an incomplete implementation. And yes it’s frustrating.
Sites didn't need to do anything special for this use case with passwords so it is a passkey problem.
It doesn't matter whose problem it is, it shouldn't be there.
Proton Pass. I moved to it and love it.
Proton Pass hardly meets the bar of "universal way to register more than one device"
Proton Pass is a specific way to do that, but not a universal way. Bitwarden can't use proton pass to move keys around, google can't, firefox can't.
As implemented they also lack conceptual integrity: you get them somehow (where are they?), and somehow you can use them (how, exactly?) but you can't enumerate them anywhere, see them, see where they came from and what they can do for you.
Imagine a password, but it a) types itself for you and b) detects when it's being sent to an impostor site and blocks them from seeing itself, so it can't be phished.
Tada, passkeys.
Cool, where are they stored? (I know the answer: 'it depends', and that's the big problem with their usability: most users haven't a clue what the answer is and most tech support can't answer that question straightforwardly because it depends on some decisions the user probably didn't even realise they made).
On my keychain in a USB hardware token. With a couple of backup tokens in fire safes.
If you're using a USB hardware token your knowledge of it is at least an order of magnitude better than the median user's. I know where my passkeys are stored, I don't know where my family member's passkeys are stored and neither do they. The same is true for most of my otherwise fairly technical co-workers.
There needs to be industry and government leadership on this to gradually require hardware token usage, for at least critical financial and government applications. Right now everyone is putting their energy behind passkeys, but those are much harder to understand than a physical token. I don’t know any non-technical people who understand how passkeys are normally tied to the device (or the manufacturer-provided cloud account in some cases), how to set them up on a second device, why you might want to do that, etc. And many technical people still don’t get it either!
Absolutely not. If that is required, I will do my damndest to only use implementations that deliberately lie about the hardware status. Your line of reasoning is dangerous.
Then that family member does not worry like you do worry. The main point is assuming one can have a proper security for Google account - everything else becomes easy.
The fearmongering of losing google account should stop. Yes, some people lose it. There are a larger proportion losing/getting pwned by repeat use. For the majority - just pressing the fingerprint to access an account (like amazon/eBay) via passkey is great.
Fairly technical co-workers - I used to suggest them to buy USB security key few years ago. Now that same fairly technical some how has at least 2 devices with them - so they just skipped the USB security key need - and just use Google (in Android) or iPhone in Apple ecosystem. Everything just works.
Yes, there will be a poor soul that may lost everything with only one device.
People keep their entire lives in cloud accounts these days. Their passwords, financial history, copies of important documents, baby photos, etc. Losing access to it is incredibly disruptive and may result in unrecoverable losses.
It shouldn’t be this way, but it is.
At the same time, I know so many people believing DIY raspberrypi based NAS and losing lots of data (thankfully they had cloud backups).
Not everyone has access to server grade hardware.
>Then that family member does not worry like you do worry.
Until they lose access to that account and then it becomes my problem to solve.
This is a different issue. Not everyone has a data engineer - know it all as a family member.
And you need to accept it works for millions.
Working for millions doesn't imply a good hit rate. Google could release a feature that worked 1% of the time and manage that, as well as barely noticing if it wipes out 10% of their users. My actual experience is that almost all the people I know who are using passkeys are using them by mistake and it's only not a big problem because they aren't currently being used up to their promise of preventing the vulnerable authentication methods.
My actual experience is people with passkey are fine. No more account take over. Mote over they like frictionless login.
Yes there are few that used bitwarden and lost everything as their sync using syncthing failed.
The biggest issue with passkeys is that since most USB tokens that support them don't allow syncing the private key to a backup device you have to enroll ALL of them to every site that supports passkeys. This is annoying but it makes storing backups in secure offsite locations impractical.
This is a fair criticism and needs work, I have some short thoughts on it here: https://news.ycombinator.com/item?id=49755217
The entire problem with passkeys is that zero of the issues should have been a surprise, because it should have been part of the design discussion from the start, so the fact that it's not properly implemented before being forced on users says that either it's been done horrifically incompetently and nobody should trust it, or they internally found these concerns and ignored them which means this system is not at all meant to help us, so why is it being forced on us?
It's beyond annoying. It's creating needless toil that no "normies" will ever actually do.
I'd love a hardware sold in multi-packs and "born" at the factory with identical internal device key encryption keys (DKEK). I'd love, even more, if a token just allowed you to "commission" new ones w/ a user-specified DKEK on first use.
I'd use one token as a daily driver and store the other(s) in safe location(s), empty of my personal key material. (Or, if I can just commission a new token w/ my DKEK, store a printed copy of my DKEK in a safe location.)
Give the token a mechanism to "type" a backup of its internal state, encrypted with the DKEK, as a USB HID keyboard. That gives me an easy way to backup the token each time I enroll a new website.
If I lose my daily-driver token I just pull a spare from storage, import my last backup, and I'm up and running.
That would kick ass. No "You just need to buy two tokens and enroll them in every website" bullshit.
Maybe each token also needs a second key, with the DKEK used for authentication and the second used only for revocation. The main reason not to reuse the DKEK is so a lost key can be easily decommissioned.
You would need some out of band way to collect and save your key IDs and publish revocations.
I’m not sure if this would work from a security theoretic perspective, need to think about how the request is signed and transmitted so someone can’t fake a key being “alive” when it’s really “dead”.
I do agree this would be incredibly useful if it can be made to work.
I haven't used a FIDO2 token other than playing around with it on a Yubikey. There, at least, I have to have the PIN to unlock the Yubikey before I can use the FIDO2 credentials (if I'm remembering correctly).
Are there hardware token implementations where mere possession of the token is all that's necessary to use the passkeys stored on it? That's incredibly stupid, and should have been disallowed by the standard, if that's the case.
Yes, the PIN is optional even on Yubikeys, although I think individual providers can require it. Ideally a strong PIN should be used but people may just reuse their ATM PIN, birthday, etc.
I didn't realize PIN was optional.
See my other comment re: the IT industry being fools.
That is how almost all standard FIDO2 tokens work. You just have to press the capacitive sensor when prompted. You can get fancier biometric tokens that require a fingerprint.
That's the stupidest thing ever.
All this hullabaloo taking away user freedom to export keys and backup tokens but physical possession is all that's necessary to use it by default.
We are a ship of fools, the IT industry.
In a secure vault on your phone
How do I use it on my desktop or laptop then? What if I switch browsers on my phone? What if I get a new phone? What if I change from android to iOS or visa versa? What if I need to log into the site on my Wii U's browser?
>How do I use it on my desktop or laptop then
>What if I switch browsers on my phone
>What if I get a new phone
You can let Apple sync your passkeys between devices using iCloud Keychain. Then you can create a passkey on one device and have it available on all of your devices. Google also syncs passkeys to the cloud and lets you use them on Windows (with Chrome)
>What if I change from android to iOS or visa versa
I resolve this by storing most of my passkeys in my password manager. I still store the "important" ones (like online banking) in my phone so a password manager breach doesn't make me lose my money.
>What if I need to log into the site on my Wii U's browser?
Passkeys were designed to let you have more than one, so if you have a device that doesn't let you use your password manager, then just set up another passkey.
Nothing wrong with your answer itself, but having to be Apple or Google is a PITA. These account are ultra critical already and you will want maximum security to access them.
This means if you go on a trip somewhere you absolutely need two devices. If you kill your phone and want to buy another one ASAP, you wont be able to do anything with the new device until you can convince the platform it's you. With passkeys you're just SOL. Imagining if you needed a phone to get back from your trip - e.g. etickets, auth needed etc. - it becomes a nightmare scenario.
A third party manager makes it easier, but it's a lot less usable that the first party ones.
Reasonable people make different life choice, having to constantly think about backup strategies whenever I'm away from home would be so stress inducing to me.
If you lose your phone in 2026 while on a trip to Italy and try to enter your Gmail user/pass from your wallet, there's about a 100.00% chance you'll hit a "let's verify you're you" gate, that's been the case for 5+ years.
With passkeys I'm not stuck clicking Yes in the Gmail app or typing in the numbers on Apple hardware, I can skip the Apple/Google specific MFA nonsense and keep the passkeys in Bitwarden where they sync seamlessly between devices.
It feels truly liberating being able to skip MFA everywhere and login with 1 click, like a throwback to the golden age of using a password manager in 2010. Before passkeys it started to feel like I was spending 5% of my waking hours every day copying 6 digit codes from phone/email/TOTP after twiddling my thumbs for 15-30 seconds.
>This means if you go on a trip somewhere you absolutely need two devices
If you want multi-device redundancy, you have to carry a second device of some type, it's hard to get around that. I almost always travel with an iPad in addition to my phone, so I have a second device.
In addition, my wife (who travels with me so if my iPhone is stolen, hers might be too) is one of my Apple account recovery contacts, plus I've set my sister as an addtional recovery contact, so even if I'm out of the country and I have to activate a new iPhone, I can call her to help with the recovery. So all I have to do is find an Apple store and buy a new phone.
I also carry a USB key tucked into my luggage with the recovery kit (encrypted) for 1Password so I can activate 1Password on any new device and have access to my passwords and whatever passkeys I don't have in iCloud.
I just don't use Google or Apple accounts for everything. I don't want my whole life in the hands of some big tech deciding how I should prove to them that I'm me.
I did use Microsoft 365 (business version) for my email but they also decided I should use their MFA app so I left. I did have my yubikey as second factor but they keep pushing their stupid authenticator app.
Apple can sync to my wii u?
I updated my reply to be more complete.
as long as you have one working device all will be OK. Either you scan the QR code shown by the website. or if you did login to Chrome with google account then desktop or laptop will just sign you -friction less. Same with iCloud account.
If you browser vendor has implemented passkey then all good.
Most things are built for the majority users. Most don't change. Most don't debate browser wars in hn. Life is like that.
For Wii etc. You just scan the QR code shown in the TV interface. all just works.
Yes, if you want 100% privacy and will do only your own dovecot server then it is not for you.
So if I drop my phone to the toilet, I will forever lose access to everything? Since the vault is on my phone.
A majority have more than one phone. Or at least they can get a new SIM card and sign into the iCloud account. Then all passkeys are synced from cloud.
Yes, if you are edward snowden then not for you. For rest of us - it is useful
This is crazy. I have one phone and zero iCloud. I don't think I'm that unusual.
You are exaggerating. If the loss or lockdown is so bad then many would have stopped using any of icloud or google equivalent. People are able to depend on it. People are able to repair and use phones even when it falls into abyss.
Well, I mean yes. People for whom it works. Others never started.
Idk how much money you must be having, but all of my bubbles only ever go with one device
this is ridiculous. I don't even have a bubble device. Run lineageos in a decent 2020 device moto G32 for €100.
Yes, you can afford to host everything locally. Not everyone can.
A majority have more than one phone?
Or they have a laptop or tablet - even the cheapest one that has logged into Google or Apple. That way they can recover.
Not always. And which vault? There can be multiple on a given device. This isn't some hypothetical 'mollify the user's worries' question, this is an important practical question of what do they need to worry about losing access to. Trust me when I say that most users I have talked to have absolutely no idea about this, and usually only find out when they've already lost them.
Great, what happens if I lose my phone?
in 1password
As others have pointed out, this is a terrible oversimplification which misses all the nuances which cause people headaches when using passkeys.
To your point, I for example would add point c) - Is linked to the device you are using currently. If you want to use another device to log in you are in a world of complexity and pain.
But how do I type it into my new phone?
It depends.
Are you part of the 99.99999% users of one of iOS+Apple or Androidlike+Google/Tencent or HarmonyOS+Huawei? If that's the case, you don't need to as the key is automagically saved by your OS' platform and synced with your new device.
Otherwise, you're such an extreme outlier that you probably either know what you're doing or can find out by yourself, right?
> … users of one of … Google …? If that's the case, you don't need to as the key is automagically saved by your OS' platform and synced with your new device.
This absolutely does not encourage confidence in me. We all know how easy it can be to get locked out of a Google account and have no way of getting back in unless you have enough clout to make a huge noise online so a human there pays attention instead of you being stuck in the 'ol support-bot-run-around loop. It doesn't happen often when you consider how many users there actually are out there, but the potential inconvenience is high enough that “fairly rare in the grand scheme of things” is still enough to be reason enough to be wary.
How can it be saved and synced without credentials? I'm in that overwhelming majority, but I don't grok how I can recover the account when my phone is lost/stolen/damaged. The answer appears to be, use another device that was already logged in?
The point is people like this usually are arguing as they hate adopting new tech. And they hate FAANG. No way to convince them.
I tell people a website is like a payment terminal. Your device is like your debit card. A password is like a PIN on the card. A Passkey is like a chip on the card.
Logging into a site with your device is like putting your card into the terminal. The site can ask for a password the way the terminal asks for a PIN, but if your device supports Passkeys, that’s like your card having a chip, and it’ll use that instead.
So think of Passkeys like using a chip card.
I dunno how well this analogy works down to the last detail but it has gotten it across to all the parents I’ve used it with
Do most people understand why cards have a chip in them now?
Probably not. The magnetic strip was easy to explain (it contains some info the terminal checks, it's functionally just a long password), but it's also pretty easy to explain why skimming was a problem. Explaining how chips fixed that (signing keys and cryptography) is probably beyond a 30 second explanation with Joe Schmo.
Then again, I doubt most people care to know, which is why that explanation works. They're not going to ask 'where is the passkey in my computer?'.
Great analogy, am going to use that going forward, thank you.
It's a key, what else do non-technical people need to know?
Ironically on macOS we used to have an app called Keychain which unfortunately was effectively renamed to Passwords for non-technical users.
It's a digital key.
Unlike physical objects they may reside in a TPM, a software vault, an export/backup, or any combination thereof. You may or may not be able to recover or migrate them, depending on where/how they were made.
Therefore you may need multiple per service, or maybe not. Services which only allow one may end up locking you out with no recourse. You get to find out.
None of this is obvious or self explanatory to normies.
That's false. It's a digital key and it doesn't matter where it's stored. My key is on iCloud and it can be unlocked with my many recovery methods and contacts https://support.apple.com/en-us/102641
As for normies, passkeys or passwords it doesn't make a difference. Either you have people who use love1969 everywhere or those who constantly lose their passwords.
All passkeys accounts for normies require an email or phone number, which is what you can use to recover a password or passkey exactly the same way.
Where passkeys are stored is as important as where physical keys are stored.
People must understand security controls, at least at a surface level, in order to effectively manage and trust them. Passkeys fail that test.
Probably because these caveats and weird behaviours are platform-dependent, not really the passkey’s fault.
Passkeys really are not any more difficult to explain than 2-factor authentication. Anyone who’s currently been able to actually create an Apple or Google account and successfully navigate their devices up to a passkey screen will be able to grok how it works.
People around here really ought to stop thinking users are complete idiots. Hell, you don’t even to scroll that far to read people calling users “normies” for crying out loud. What is this? High school?
I don't care about the theoretical sufficiently advanced keypass implementation that works perfectly. I want to know about the half baked ones in the real world that I'll have to deal with.
Do you know how many Google and Apple accounts my boomer parents have?
Roughly one per smart-phone that they've ever used. They don't know the passwords or even the email address of any of them, not even the latest.
Tell me how passkeys makes this any worse. If one's digital life is a mess, there's no magic solution to it.
Arguably Yubikey and similar are better. Even vanilla passwords are at least understood by my parents, despite their confusion over account proliferation. Passkeys are a step backward for them, even more so in light of account confusion.
You obviously dont have to deal with anybody who doesnt know how or want to use computers.
The keychain and passwords app are separate and keychain still exists
I always operated under the assumption that the passwords app was just a more casual view into the keychain
Maybe that's a bad assumption
They're separate stores. I was under the same assumption until I tried to use `security` to get a saved password. It doesn't work, and as far as I know there is no CLI for the Passwords app's store.
[dead]
Surely it's a pretty easy pitch to average Joe: Using a passkey takes the place of typing in a code they sent by text or email.
That's a pain point in everyone's day that should make the benefit easy to understand.
ok cool so when somebody logs into a site on their phone and sets up a passkey, then goes to their laptop and tried to log into the same account, how do you easily explain how to deal with this situation?
You don't. A laptop might still be a general-purpose computer under the owner's control, and we discourage those.
What I have seen is that the site gives you a QR code to scan with your phone. People are already used to needing their phone to sign in via an Authenticator app or SMS code.
That's the main thing I wish was done better. There was barely any actual lead up from the perspective of an average person. Just a new unfamiliar flow on half of the login screens that they use.
Sure, its explained. But not in a satisfactory way that would reach all users at their level.
This is a bit of an exaggeration and out of proportion, but I think my ideal would be one of the big tech companies should have bought out something like a super bowl ad. Something that actually conveys the idea "hey, we know you've used passwords since you were able to type on a keyboard, but here's new technology that's better and here's why" in plain language that the average person can understand.
Unfortunately, XKCD 2501 continues to be relevant. [1]
[1] https://xkcd.com/2501/
The average person? I have a Master's and PhD in CS, code regularly, and have followed and used all the cool technologies from the days of gopher, telnet and Mosaic to crypto, and lately LLMs. And I still don't have a clear enough picture of passkeys to know really basic things like "what if we have a family computer but each wants to access their private accounts and keep the others from accessing?", "what do I need do to login from an airport computer?" or "what should I do if my phone is stolen?"
If it's that unclear to me, I can't imagine how it can be to the average user.
The way they explain them is atrociously unclear, borderline negligent for services that nag people to activate it for accounts where they may hold valuable data for their personal lives. And while I don't want to spend much time finding out the details as long as I have the option to decline them, I suppose if they can't explain it and convince people of its advantages, it's because it's just bad tech.
> "what if we have a family Computer but each wants to access their private accounts and keep the others from accessing?"
That's what OS level user accounts are for. Tbf
> "what do Ineed do to login from an airport computer?" or "what should do if my phone is stolen?"
Indeed I don't know the answers to these either if I wasn't syncing passkeys in 1password. Honestly we should educate people to use password managers more than any thing. It's also a smaller jump than to passkeys. Passkeys can be more of an advanced convenience feature after they get used to using password managers already.
I cant upvote you enough for this very concise explanation of passkeys pain points.
[dead]
Passkeys remind me of ipv6 in that they are a "solution" coming from the supply-side, without (apparently) having done any research in what motivates actual users (and what would motivate them to switch).
<<ducks>>
They make sense as a technology for businesses & their users. In that scenario, the owner of the account is not the user, but the business. It makes sense for the business to be able to place strong restrictions on how & where the user may log in, it fixes a lot of real problems businesses may have thanks to sloppy user behavior, and the business is also motivated to provide a way to fix broken logins. It's a good solution for that scenario.
But for regular end users where services are primarily motivated to take money from those users and lock them into their ecosystems, they are a usability disaster and yet another exploitation vector.
It's one solution for two very different usecases, and it just does not work. There is an approach that could work for end users who own their own accounts, but they need to go back to the drawing board and rewrite the protocol with the assumption that the keystore is hostile to the user's interests. That means strong guarantees on key portability so users can migrate away from hostile keystores, and absolutely no ability for services to restrict the user's choice in passkey provider software.
> and the business is also motivated to provide a way to fix broken logins. It's a good solution for that scenario.
This is a big part of it. An employee at a business will be able to talk to someone in person and say 'I can't login. Can you reset my password?' or whatever equivalent, and be made whole. Even if the business is is made up of 10000 people and the identity of the employee is for some reason in question, the situation can still be resolved with a passport or a driver's licence.
Google is never going to make you whole again if you're locked out of your account, unless you're a celebrity and make a stink. There is no help desk where you can prove who you are (and even if you could, would you want to? That's a whole second domain of problems that I'm not sure will ever be solved completely).
I think passkeys were made to work in mind with complete idiots (here's a pop-up, tap it, now you have access to website without password, don't think about where it was saved or that it exists at all). I can understand parts of IPv6 like Router Advertisement being like that but there is so much customizability for the user that I can't really see them being similar that way.
Except they never considered that "complete idiots" could lose access to their phone's passkeys.
They did, that's why they sync
Right... just let me pull out my non-existent spare phone when mine breaks or gets lost.
It'll work if you have a laptop on the same account, iCloud or 1password or whatever else. If you only had a phone, you set the account up again on your new phone.
How does a person sync their passkeys between devices?
iCloud, Chrome, 1password, etc
To make it about security on both sides: IPv4 NAT is idiot-proof. IPv6 replaced that with a firewall that may or may not be default-deny.
Nah, TOTP was like ipv6. Passkeys have their UI issues, but at least they had syncing day 1, so they're now a serious contender to SMS auth.
[flagged]
[flagged]
> To an individual, the greatest risks are instead permanent account lockout, automated account bans, and device loss. By using passkeys, you gain better security against man-in-the-middle attacks but face the higher probability scenario of losing access to your accounts.
I'm glad to see this view becoming more mainstream. Passkeys are grotesquely insecure.
The only possible way to consider them more secure is if phishing attacks were more common and more damaging than lockout, which is so implausible that I reject the idea that someone could take that position in good faith.
> Passkeys are grotesquely insecure.
Lockout is a real risk, but there is nothing insecure about passkeys. Private keys stored on the secure enclave + biometrics or passcode before any signature is produced + origin binding mogs a static string and a 6-digit TOTP (often generated with a secret key outside the secure enclave) that can be phished and entered from anywhere. Also, in many (possibly the majority) of scenarios where someone is locked out of their passkeys, they’d also be locked out of TOTPs and passwords.
> The only possible way to consider them more secure is if phishing attacks were more common and more damaging than lockout
You’d be surprised.
Security as a field would be a lot less obnoxious if it did not neglect availability as an important facet of security. A 'security' system that obstructs legitimate access is also failing at its job.
> Lockout is a real risk, but there is nothing insecure about passkeys.
secure - adjective
se· cure si-ˈkyu̇r -ˈkyər
securer; securest
1
a: free from danger
b: affording safety (a secure hideaway)
c: TRUSTWORTHY, DEPENDABLE (a secure foundation)
d: free from risk of loss
Passkeys as a sole/required method of authentication increase the risk of permanent loss. In any other configuration they do not mitigate phishing risk.
It is not possible to say there is nothing insecure about them.
Reliability != security
If a car breaks down every 50 miles we would call it unreliable. If a car’s doors don’t lock we would call it insecure.
Information security has the concept of the CIA triad: Confidentially, Integrity, and Availability.
Being able to access the secured data is an essential element of security, otherwise a safe encased in concrete dropped to the bottom of the ocean would be the most secure storage available.
Pro tip: if your substantive argument requires gaslighting people about the literal definitions of words, maybe you should take a step back.
> gaslighting
That is some serious semantic bleaching!
I’m not disputing the fact that “secure” has different meanings in different contexts. My point is that when we talk about the “security” of authentication methods, we almost always are referring to its resistance to attacks, exploits, social engineering, etc.
If you tell the average non-technical person that “passkeys are insecure,” they’ll think that it’s easier for (WLOG) Russian hackers to phish or bypass their way through some website’s passkey requirement.
And to be clear, I don’t think it’s ridiculous to say that right now, the risk of lockouts outweighs the security benefits of passkeys. But this is a fixable problem. If it gets easier to securely recover or back up passkeys, I think we can reach what is more clearly a “best of both worlds” of security and reliability.
The context is literally the line quoted from the article, which made it reasonably clear what the word was supposed to mean, and you decided that (1) you understood what they meant, and (2) deliberately tried to bring up an alternative meaning and object to it, and (3) continue arguing why (2) was justified by taking the sentence out of its context (and into your hypothetical context).
This line from quoted from the article?
> security against man-in-the-middle attacks but face the higher probability scenario of losing access to your accounts
The author says "security" against man-in-the-middle attacks. Are they not using the typical cybersecurity-context meaning of "secure" that I just mentioned? (Resistance against exploits, attacks, social engineering, etc.) And note that they say "higher probability scenario of losing access to your accounts" rather than something like "lower security against account loss" which would have been admittedly understandable, but a bit less clear since the more common cybersecurity meaning of "security" was just used.
> deliberately tried to bring up an alternative meaning
I am using the typical understanding of what "secure" means both 1) in the context of the quote from the article you used and 2) generally in the context of authentication methods. Let's not act like I dug up some obscure and irrelevant alternative definition.
> and into your hypothetical context
Is it really so unrealistic and hypothetical to think about how non-technical people (i.e., the vast majority of people) will interpret the at best questionable statement that "passkeys are insecure"? I stand by my claim that most people will get the wrong idea when they hear that.
> if phishing attacks were more common and more damaging than lockout
The calculus changes if the service is a bank or your stock broker, which, if you are in any reasonable jurisdiction, if you can prove your identity (in court) they are legally obliged to ensure they give you back your money.
But, for the vast majority of other internet services... I honestly don't think anyone would want to MITM my instagram account for example.
Lockout sucks, but it’s not an indicator of insecurity. If anything it’s the opposite.
I don’t use passkeys because I like BitWarden and two factor
Just sayibg
> When you have to handle a colleague’s computer, it gets much more inconvenient.
Let's add to that: What if you're on holiday and your phone gets stolen or is suddenly 20 meters under water because it fell off the boat?
What if you are a normal person who only has a phone and it simply dies for one reason or another?
You get a new phone then hire the boat again, go above where your phone fell in and hope it syncs your passkeys?
How do you solve these problems other than memorizing every password? I guess you could keep a piece of paper with backup codes, but that works for passkeys too if you use the right manager.
You should always plan for your currently active device to be bricked suddenly and act accordingly.
You either should treat your passkeys with a backup like any data, this can mean multiple hardware keys or a cloud backup of your passkey, like bitwarden or the provider's native backups.
The key word in the post you're replying to is "normal". Non-technical people don't (in my experience) plan for this kind of thing, like at all.
The idea of multiple hardware keys, which have to be enrolled individually to every site, is just not an ordinary end-user friendly activity.
So passkeys may be great for technical users (who are happy doing that) or corporate users (where centralized IT systems can be put in place) but not for standard non-corp users (which realistically, is most people)
Bet you have a home lab.
Not talking about you. After all passkeys are not there to protect people who have home labs and don't recycle passwords anyway? They're for normal people who only have one device.
> who are happy doing that
You think they're happy? I'd say they grudgingly comply at best.
Suppose you do want a secure solution for the main sites your stuff is on. But every piece of shit content mill also wants to set up a passkey.
Edit: wow i missed this:
> a cloud backup of your passkey
... which is protected with what, a passkey?
They're a solution to a problem that were created by people who are completely out of touch with normal users and how they use computers.
Sure they work fine on a technical level, but they're frustrating and confusing for the vast majority of people I know.
Depends. They make it pretty easy for people who don't think about the consequences of things.
I worry I am going to get locked out of my Google account, muggles don't. Doesn't stop them from getting locked out.
Apple has a vision where you have an iPhone and a mac at home and a mac at work and a vision pro and an Apple TV and all of that and your passcodes "just work". Doesn't work for the "rest of us", like we're already used to AirPods punishing us for using Windows.
>Apple has a vision where you have an iPhone and a mac at home and a mac at work and a vision pro and an Apple TV and all of that and your passcodes "just work".
I have many of those and I fucking don't want them to "just work". My iPad is not my iPhone. My Mac Mini is not my iPhone. Yet my iPad at home pops up the speech-to-text voicemail notifications from phone calls that I chose not to answer while I am miles away at work. It's so fucking annoying that you can't specifically turn that off.
It's funny.
My usual "go kit" has my iPhone in my leg bag and then my iPad is either my main bag or one of those pouches that waitresses wear which has plenty of room to pack a tablet. I like using the hotspot (being parsimonious with data) and being able to respond to texts with tbe big screen. It's also nice that I can share passwords and passkeys easily between them.
Other aspects of the "Apple Lifestyle" make no sense to me, like I an a mirrorless photographer and use my iPhone like my Sony, I will go out with my selfie stick and shoot 200 selfies, transfer them to my computer, pick the best 3, them clear them all out.
I plugged my iPhone into my Mac when my wife was logged in and it tries to back up the whole 'freakin phone and renames it "Olivia's Phone" which is just nuts. Of course their answer is that you never clean out your phone, you just upload it all to iCloud, where I think the value proposition is you can pay $1 a month and stop all the dialogs nagging you to get it... Now only if I could have made the badge for Apple Arcade to go away by trying the free trial and canceling it!
Similar for "automatically enabling Bitlocker and uploading the keys to microsoft server".
If it works without any issues, great.
But if you ever run into one of the 50 messed up situations, good luck.
No, microsoft uploading disk encryption keys to your account is the exact opposite situation. It's microsoft purposely reducing security to ensure there is a recovery path, because average people don't need or want the security tradeoffs where "You permanently lose access and it mathematically cannot ever be recovered" is a failure mode.
If it was possible for a key to your house to have that failure mode, nobody would ever lock their doors
A recovery path that is taken from you if you forget your Microsoft account password or your account gets banned on a whim. Sure.
I have worked with windows PCs for a living for many years and I have never seen one do that.
Hint: google "lost bitlocker key reddit.com"
It's the classic "make your problems worse to fix my problems" that you see across tech. Since they don't care if you get locked out or leave their platform, it's designed to make them maximally profitable. It's the same thing you see when sites "offer" to let you do pre-registration work before an event or transaction, even though doing that work at registration is often trivial.
Want to get a RealID? You can spend 30 minutes scanning and uploading your supporting documents through the website, or you can hand your documents to the person at the desk and they'll evaluate it in 30 seconds. Over thousands of people, it's rational for the organization to optimize away that 30 second review (it also gives people a recovery option if they don't bring the right documents.) For the customer who is competent enough to bring the right documents, the latter approach is way more efficient. I regularly have to put myself in the "I'm old and hate technology, so lets do this the manual way at the desk" flow even though I'm totally capable of doing the electronic flow.
My situation at work is absolutely untenable. Constant redirects, logins that used to have passwords but now have passkeys, but you don't find out until you enter the password. Chrome hijacks the passkey dialog and wants me to use my yubikey, but I have to fumble around and bypass that to then get it to prompt me for a passkey in Apple Passwords. (as long as 1Password isn't trying to intercept my passkey requests today!)
Then on top of that there's a whole 2nd factor layer which _also_ typically involves a touchid press but for a totally different reason (as the 2nd factor, not to unlock the password safe storing my passkey.
It's just an ugly inconsistent dance, dozens of times a day.
I know these gripes are mostly about implementation, and partially about user-facing software, and partially about user choices, but it doesn't make it any less ugly for the user.
I love passkeys. Really. They completely eliminate the need for a password and OTP in most cases (when actually used as they were intended and not as a second factor only), although I always set up both in case. Although I will never, ever like how Google does it. I set up my first Google account with them and now Google absolutely refuses to allow me to authenticate to it because it wants a passkey I don't have (and of course there's no way of not using said passkey) or it wants me to use an Android phone I (also) don't have (I traded it in a couple years ago). And, of course, it provides absolutely no way around that problem. So eventually I just gave up and created a new one for the (rare) times I do need a Google account for anything.
> refuses to allow me to authenticate to it because it wants a passkey I don't have... it wants me to use an Android phone I (also) don't have
And yet you love passkeys? How much will you love them when you're locked out of something you can't do without?
Passkeys are somehow 100% seamless for me, except for two services that have somehow screwed up the implementation: Google, and Okta. In Google's case, they have made it so that if you _ever_ add a passkey to their password manager, it somehow refuses to work with a third-party password manager going forward. In Okta's case, the admin policy UI makes it next to impossible to have passkey-only login without their Fastpass app or an oldschool password login.
> And yet you love passkeys?
Yes. The security benefit can't be overstated.
> How much will you love them when you're locked out of something you can't do without?
I certainly wouldn't be happy if this did happen, but it would be my stupidity (or the stupidity of those who implemented it on the service/platform where the problem occurred) which I would blame more than the fault of the tool. I do keep all passkeys in Bitwarden now so that's something at least.
> The security benefit can't be overstated.
Security benefit appears strongly overstated. Compared to using a password manager (including generated secure passwords for each account), there isn't a significant security benefit. passkeys require using a manager as well, so there isn't much point.
> ...but it would be my stupidity...
All people are stupid sometimes. A security flow that doesn't account for this very well isn't a very good security flow.
(Related: everyone tends to be unlucky eventually, and, unfortunately, everyone becomes incapacitated/dies eventually. Security flows need to account for these as well. Not to mention that in my experience, no software company continues to offer a quality service at a reasonable price forever. You're lucky to get 10 years. Having access to my accounts tied to a single piece of software is likely to become a big pain at some point.)
> passkeys require using a manager as well, so there isn't much point.
No they don't. I use hardware passkeys for all my important accounts. It's extremely easy.
I think this is probably one of the reasons people have very different passkey experiences. Hardware passkeys are great and software ones appear to be less great.
Do passkeys improve security posture for the average person, reducing the likelihood of them losing their accounts to fraudulent actors? Absolutely.
But they also introduce single points of failure, as the article points out. I can't even remember how many times I've had to help a family member recover their account or get confused when they can't sign in on a new device. It's incredibly frustrating that this flow is promoted as the default for so many services.
1password is the best solution I've found for the average person. It's not perfect (it's definitely more complex than writing down your passwords on a piece of paper or using the same password everywhere) but it's much easier than juggling yubikeys. I know so many non-technical staff members who prefer the OS or browser keys even if it means another account recovery is lurking around the corner.
I am conflicted with passkeys.
I actually prefer non-resident U2F in some ways. You don't have to store anything on your key, you are just signing requests. This is relevant where U2F/FIDO keys have limited slots for 'resident' keys.
In principle, it's great. You have one good password to remember for the average user, and that's enforced by their device's probably good enough security posture.
They are resistant to being phished and they won't reuse the same one everywhere. They then don't end up going from hunter2 to hunter2! everywhere.
But my experience for users is that they worry they are giving their biometrics to Amazon or whoever and so the UX just confuses them.
The certification aspect was new to me too last time passkeys came up. Sites can require that a given passkey has been certified.
The patchy support for them is also frustrating. MacOS does not support NFC FIDO/U2F. iOS does.
Absolutely! U2F keys are unlimited, but I only have so many slots on my hardware key. And now sites are moving away from supporting U2F towards a passkey-only model. No! I have limited slots!
I don't want to have the security sensitivity of my devices be escalated by the fact that I access a very important service with that device. Currently I have separate passwords and a 2FA on my investing and bank accounts. I don't want to have to treat my cheap travel laptop as a SCIF because it is synced with my cloud services and has passwordless access to my entire financial life.
Two crucial things you can do with a password that you can't do with a passkey:
1. Write it down on a piece of paper and put it in a safe deposit box.
2. Read it on one device (or from a piece of paper!) and enter it manually on another device.
Plain text is the ultimate form of cross-platform portability. Passkeys are the ultimate form of vendor lockdown. The passkey vendors won't even allow you to view the private key, unlike with ssh keys, which you can also write down on a piece of paper. It's vendor cabal to destroy computing freedom in the name of "security", always the excuse. Tech company paternalism at its worst.
This is exactly how I feel about it.
If passkeys were meant to be user friendly then there'd be a secure optical transfer mode to QR code them from device to device with the screen and camera.
Easy to implement (receiver flashes a public key, sender encrypts to that key and flashes the QR code back).
That it doesn't exist for a protocol meant to work with phones tells you exactly where the thinking was headed.
That they have purposely put effort into preventing you from doing that shows you everything you should need to know.
The entire point of passkeys is yanking the control over authentication out of the hands of people. These companies don't want you to be able to let someone else log in as you.
That's the entire point.
The problem they are solving has absolutely nothing to do with security.
Completely agree. I think the root of many of its issues is the inability to add a key that you don't currently hold. This prevents me from storing a backup key in a safe, for example.
I proposed an alternative scheme many years ago: https://www.researchgate.net/publication/343318317_Privacy-a... . By allowing "offline" keys you can also treat them as higher priority, and use them to revoke any lesser keys from attackers if your account is compromised.
It would also be nicer to get rid of usernames, but that's a fight against the data-gathering powers that we're unlikely to win.
From TFA: "Both Apple and Google want your identity anchored to their operating systems. The “happy path” on their devices is to use their synced passkey management tied to your Apple or Google account. If their automated systems decide one day to ban your account, you irreversibly lose access to all your passkeys used across all third-party accounts too."
This is, in my opinion, the most serious problem with passkeys. I'd like to adopt them, but this is a blocker.
If this is your only blocker you could still use passkeys with a different provider, like KeepassXC?
Not while the spec has provisions to allow sites to mandate certain providers.
you can use password managers that support passkeys, or a HW key
They really are bad. Passkeys have turned out to be just another password that you cannot even memorize.
>just another password that you cannot even memorize
there's some issues with passkeys, but not being able to memorize them is a feature
So where do I keep my pass keys is the problem. They are in my password manager just like another password. So what's the point of having them because effectively, the passwords in the password manager and the passkey in the password manager offer the same UX to me? Except that at least I can memorize a password by heart just in case.
>They are in my password manager just like another password. So what's the point of having them because effectively, the passwords in the password manager and the passkey in the password manager offer the same UX to me?
same ux, different security properties.
>Except that at least I can memorize a password by heart just in case.
"just in case" should be a thought out recovery flow, rather than hoping that you remember the password of the account you need to access.
The password is the recovery flow. What do you propose instead that isnt just a variation of having a password and a passkey?
a memorized password is not part of a well thought out recovery flow.
double triple emphasis on "memorized"
Ok, I write my password down. Now what?
the same advice as the last few decades:
place it in a fireproof safe alongside your other important documents, like your passport and birth certificate.
That is the point. They stop you from memorizing it “just in case” and reusing it, and they force you to use a password manager.
For the average user, which doesn’t use a password manager, this is great. It means they can’t get phished. And it’s also great for the average password manager user, who keeps dozens of insecure and reused passwords in their vault because they manually thought of a password when signing up instead of randomly generating one.
If you’re already using a password manager and random passwords, the UX is designed to be the same. It’s just a way to get regular people to do this.
> If you’re already using a password manager and random passwords, the UX is designed to be the same.
In that case, they've completely and utterly failed.
A corportation's feature is a user's bug.
And this is why people bash passkeys, but they hear a buzzword lol
> Since they are bound to the site they are created for, they cannot be phished by a hacker’s fake login screen.
With the app you use to store those keys (a password/key manager) it's the same - you simply wouldn't have an autofill working. Sure, people can and will circumvent this for the benefits of the scammers, just like they can circumvent passkeys using non-passkey login option, indeed:
> weakest recovery method: SMS
> If a site suffers a data breach, passkeys are asymmetric and cannot be recovered from the server-side details.
Similarly, don't other modern password storage methods have the same property?
> lacks the decades of UX polish towards password autofill.
A lot of years in those "decades" have been wasted polish-wise: you still can't log in with a single button, e.g., many popular sites only fill a username first, then require an extra dealy and action before accepting a password
Fake websites pretending to be legitimate websites in order to steal your passwords was considered a HUGE problem. That's why TLS includes website certificates. The implementation is kind of a mess with commercial Certificate Authorities (CAs) being too expensive for small businesses to use, CAs getting hacked, or downright shady CAs that couldn't be trusted. A lot of websites didn't use TLS because of these problems. It took decades to get to the point we are at today where we have Let's Encrypt and all websites using TLS. Yet phishing still works because fake websites can use a URL that looks legit and they can get a certificate for that URL.
We need to get away from shared secrets for authentication. Passkeys are fundamentally a way to do that, but they aren't perfect. Personally I wish TLS and Passkeys both were way less complicated. I think we could use asymmetric encryption for authentication without certificate authorities and secure enclaves and all that and still be more secure in general than we are today. Think ssh keys. But no browser or webserver does that.
I think our best bet is probably to aggressively use passkeys and work (as was done with with TLS) to make them better until it mostly fades into the background like TLS has.
The best solution I've found is yubikeys. I keep them on my keychain with my car's key fob. If I lose that key fob I don't know how I get my car started. It's not like the old days where you could pick the lock or get a few copies of the key made for cheap. Same with yubikeys. I worry about losing my yubikeys about as much as I worry about losing my car keys. A little, but not too much. I use both so often that it's not too hard to keep track of them.
The author talks about the problem with using hardware keys, but they neglect to mention that many websites and apps simply do not allow the use of hardware keys! They will insist you use Apple or Google syncable keys. So after you have spent the money to buy 2 or 3 hardware keys, you find that they are not accepted.
That websites get any say at all about which client-side software or devices you use is already a misfeature makes passkeys a nonoption.
I don’t like how tokens have gradually evolved from a secure 2F device that you carry with you (Yubikey etc) to a single factor “passkey” that’s built in to your computer/phone, or worse, a password manager with export capability.
It should always have remained a second factor device. It’s not impossible to teach people to use these, European banking did it for years. There’s just no will to do it.
If a user doesn’t have a second factor, what should their first and only factor be? The passkey people are trying to posit that a passkey is better than a password as the only factor.
Second factor should be gradually ushered in everywhere over a period of years, starting with banking, until it becomes second nature for users. This would effectively end concerns over strong or reused passwords, and would make phishing incredibly difficult.
Under this scenario, the first factor can be a short password or even a PIN.
It’s because we have effective biometrics now, so the need to carry around an inconvenient limiting physical 2nd factor is obsolete (for the vast majority of regular use cases)
We also have devices with yubikeys built-in now.
I 100% agree with this.
I have physical passkeys, one attached to my keys and another on my desk at home and I absolutely hate software based passkeys. Every single time I'm asked for a passkey it always ask me if I want to use my Apple Keychain first and I wish I could default to physical.
physical 2fa should be an option, but i can never agree that we should force billions of regular people to use a harder to use and more inconvenient system that they have already indicated they dont want to use, for some mild security benefits
Why not? We “forced” everyone to use SMS/email second factor, now we’re moving towards “forcing” passkeys, and European banks used to “force” the use of an electronic HOTP/TOTP token.
Decoupling logins from the big cloud providers is a clear win for freedom and protection against abuse. People are frequently cut off from their cloud accounts for whatever reason, and I expect this problem to increase as global disorder increases.
(To be clear, I don’t think people should be legally forced to use tokens, but I do think that industry should be heavily encouraged in that direction.)
The experience is also junk if you're using a password manager, I have passkeys that I'm not sure if I saved to the OS manager or my password manager... mostly my fault but I enter passwords so many times a day it can be hard to stay on top of which UI I'm clicking yes in to store them.
Password managers are great IMO, I can use some absurdly long password, backup is reliable, I can use them across devices. For extra secure stuff 2FA works the same, I've got an app with codes I can easily back up and use from multiple devices.
Passkeys tend to obscure everything and take away a lot of control.
> Passkeys are a fantastic technology. Since they are bound to the site they are created for, they cannot be phished by a hacker’s fake login screen.
The same is true for passwords with a password manager.
> If a site suffers a data breach, passkeys are asymmetric and cannot be recovered from the server-side details.
Also not really a problem with randomly generated site-specific passwords in a password manager.
Really all the browser vendors had to do was add an API to make automatically generate a password that is then stored in the user's password manager the low friction option.
If you're doing that you might as well use public/private keys. The issues with passkeys are around user experience and education about how they are stored, and a lack of good backup options like enrolling a not-present device as opposed to relying on syncing them through an external service.
The difference is that no password manager I used ever tried to hide my passwords from me.
The huge UX drawback of password managers vs. passkeys is sites that have arbitrary requirements. "Your password must be between 9 and 12 characters long, and include at least two capital letters and a special symbol". Well, my password is randomly generated, and enforcing that there are two capital letters would just reduce entropy.
If sites fixed this issue instead of pestering me for a passkey I'd be happy.
Account lockout as the author mentions is the biggest risk on personal accounts.
Passkeys just make it harder/riskier.
My biggest gripe with passkeys is that the spec seems to force non-interoperability. I use a password manager and I would have no issue storing a private key in a profile there, but I am literally not allowed to be able to copy the private key. If a spec thinks it knows better than me, I won't use it.
And don't you just love the fact that now Apple and Google and Microsoft have MORE control of my identities across the web?
some password managers can pretend to be a passkey. but I don't use them because it requires finicky brittle configuration (and docs lookup whenever you want to redo it).
if passkeys had a simple text challenge response text option it would be fine, you would basically be using something like PGP logins. and would be easy to implement in a password manager interface.
as a result, I have zero interest in passkeys. a pity as it could have been useful (cold storage password manger + physical passkey). you can never trust any service to honor "backup" login options, got burned once for "suspicious activity". that is, if you lose a login option (passkey is lost) they can demand it in the future to "verify".
Multiple sites (e.g. Microsoft) currently ask me to use the passkey to log in after I enter my username, but the passkey doesn't seem to be stored anywhere. I usually will end up scanning the QR code to check if it's on my phone and get a negative answer. Then I have to go through the regular password + 2FA ritual I was already ready to use. After that, I am not given the option to store a passkey on the device I am currently using or on my phone. Process repeats next time. So much fun using passkeys.
I think there are two sites where I can actually log in using them.
I also don't like the way the pop-up is always so automatic and interrupting. Why not a button like other ways to log in?
It's the stupidity of Service Providers to adopt passkeys in the first place.
As a service provider myself, I've evaluated and said "Nah" to passkeys - because it's simply increased Customer Service contacts I have to invest in, whenever a user changes or loses devices, or any of the hundreds of ways Passkeys are not portable.
And guess what, the Tech companies pushing this have zero liability for user login support or security breaches. It's always me. There is no need for me to work hard and spend CS contacts, to wall off my users to the OS or Browser vendor.
I'll simply do passwordless Email or SMS 2FA / Magic Links and own my users without the overhead of Customer contacts, thank you.
I understand many passkey complaints but not this one. Why, for you as a service provider, are passkeys not just better (or at least equivalent to) passwords? You collect and verify an email address at signup and the account can be recovered in the same way as with passwords, or passwordless-email. No CS-verified recovery needed.
> Why, for you as a service provider, are passkeys not just better (or at least equivalent to) passwords?
Why you missed the last line of my answer? How did you get an impression to go back to broken passwords?
All right, my framing was a little too tight. Sure I can see why an email/SMS passwordless loop is easier for you, but it’s a more annoying user experience than your OS/browser/password manager just filling in your credential directly.
Passkeys are great in that its turning login support on websites into simple "autheticate your device to seamlessly login". My biggest gripe is that it seems Apple/Google are using this to consolidate control into their own password ecosystems and don't support password managers as a store for passkeys.
What I dislike about passkeys far more than any of those qualms is that they can implement remote attestation.
A website should not be able to dictate what application I use for passkeys, what hardware the passkey is stored on, or whether I'm allowed to duplicate my own key.
Just yesterday I was showing to a friend how I logged in my self-hosted forge with my own hardware key.
0 intermediary yet proper and convenient authentication. If that friend ate the key (which he didn't) I'd just use my backup key, a cheaper non biometric one.
I think it's not more popular because people don't care enough about security to buy actual keys, rely instead of 3rd parties that they don't actually trust, e.g. Microsoft, Google, etc then... complain it's not good enough.
> By using passkeys, you gain better security against man-in-the-middle attacks but face the higher probability scenario of losing access to your accounts.
> Phishing through the standard login flow is eliminated by passkeys, but it creates a false sense of security. An account’s security is still dictated by the weakest recovery method: SMS, email links, security questions, and so on.
Passkeys are too strong and may cause account loss.
Passkeys are too weak and can be bypassed by account recovery.
> Passkeys are too strong and may cause account loss. Passkeys are too weak and can be bypassed by account recovery.
Turns out, given the variety in the ecosystem, both these things are true depending on where you look.
>This leads to passkeys being the perfect fit for a corporate environment, but a poor fit for personal security.
I 100% agree - almost everything about them screams "this is The Ideal Corporate Solution".
This isn't a bad thing, it's nice to have a standard for corporate uses. And the attestation-DRM stuff makes perfect sense there, you already have MDM and it fits with that perfectly....... though not all that differently than using MDM to set up client-side certificates. But app/OS support is better, for some reason. Why didn't they just improve that flow?
For personal use though, they seem outright hostile to people living in the real world with common failure modes. It's outrageously clear that normal people were a distant afterthought - just look at how hostile it was to syncing at the beginning, and how long it took to get key exporting (and how directly hostile they were to anyone building a stopgap in the meantime).
I agree with all the points this articulates. I understand why for many users they are great. But I would prefer better acceptance and continuance of the simpler, unfishable, u2f simple hardware keys.
The point about Google or apple or your passkey manager banning your account is a reason I'm still using random passwords in Keepassxc. I don't know if there is an open source passkey manager that syncs across devices that is self hostable.
Anyway, companies should be educating users more on passkeys, how they work and where they get stored.
I love passkeys as a tech enthusiast with a password manager that can hang on to them but I don’t love them as a confusing user experience for the average joe.
I also don’t love how many websites and apps use them in stupid ways like using them alongside other 2FA or login methods when the passkey alone should be sufficient.
You’re the first person in these comments to mention 2FA with passkeys.
My gripe with passkeys is they are almost always implemented without a second factor.
You’ve mentioned the rare case of 2FA with a passkey as being a bad thing, but in my opinion those few cases are actually doing it RIGHT.
With passwords and 2FA, if someone manages to copy your primary authenticator (password) they will still be locked out because they don’t have your secondary authenticator. This protects you against malware that steals your password database.
But the way most companies implement passkeys (single auth), if someone steals your passkey database they can use it immediately. For all of the true measurable benefits that passkeys bring (not memorizable, higher entropy, automatic storage and use in a database) they are almost always used in a way that has this huge drawback: no 2FA.
This is not an issue with passkeys directly, it’s an issue with how services implement passkeys.
I think passkeys with single auth are fine because of how they end up being stored and managed.
If you use them via Windows, iOS, Android, or macOS, they are tied to the biometrics on your device. Someone has to steal your device and unlock it to get in. They have to have something you know (phone unlock password) and something you have (biometrics).
In a password manager case, trust is moved from the client device to the password manager itself. It is assumed that the password manager implements these things. For example, my 1Password needs to have both my password (something I know) and secret key or existing logged in device (effectively, something I have, as I don’t regularly type in my secret key as a password and don’t have it stored digitally except for within the password manager itself) to be logged in.
"If you use them via Windows, iOS, Android, or macOS, they are tied to the biometrics on your device."
There are no biometrics on my primary devices, which are desktop computers. No camera or fingerprint reader.
Your client device OS will not allow you to create a passkey without a local unlock PIN/password or biometric, and those local unlock methods do not traverse the Internet (they are handled with TPM/Secure Enclave).
It’s the passkey that should be protected with MFA (biometrics, PIN), not the account with the third party service.
My Yubikey supports passkeys and protects them with a PIN of my choosing. No services need challenge me further.
I LOVE passkeys. That said, I store them in my password manager, which means anywhere I have access to my password manager, I can easily login via passkey. I can understand they would be a pain if I was often using new devices and did not have a password manager. I also admit it can increase the risk of lockout, but the sites I have passkeys for generally have recovery methods.
The only issue I've had is sometimes a website has poor support for my password manager, and I can't find a way to put in my passkey. That is very annoying. The benefits are worth that IMO - can't forget my passkey, can't phish my passkey, can't be hacked serverside. It's a clear upgrade to passwords
I feel if the _website_ needs to have support for your _password manager_, then that technology is way too fragile for me to want to use it.
If you have to use passkeys, try KeePassXC and KeePassXC-Browser. I used them to set one up for Amazon a few days ago, as Amazon now forces passkeys as of this month, at least for my account. It was relatively painless.
That said, I don't like passkeys either.
This is the direction I'm looking, but it sounds like we might have a little farther to go before it works well across all devices.
Yes, thank you. Maybe I am getting old but password+yubikey/webauthn was really top UX.
> Maybe I am getting old but password+yubikey/webauthn was really top UX.
It most definitely isn't. Any 2nd factor that is not the device I am currently using (either a yubikey or my phone) has a non-zero chance of not being near me when I need it, leading to the constant question of "where the fuck did I put that darn thing", only to find out that the cat has decided to believe the yubikey is a mouse and tried to devour it, the phone's battery went dead...
What prevents passkey being used alongside password (+ email 2fa)?
Email 2fa otoh is the worst UX I have experienced. I curse every time Claude sends me a magic link. Absolutely hate them.
Not sure this is what I meant. Password is still stored, along will all the keypass stuff. If you have the option to login with the keypass... or the password - possibly sending you a link (or code) to the email, in case the device/browser has not been seen, yet.
You don't like not having to worry that they don't store your creds so they can't lose it?
The creds they store hold no value. These creds only give access to their system anyway. They store the email address either way so the situation is no better but less convenient.
They hold no value precisely because they don't store them and send you a magic link! If they stored a recycled password or its hash, then it would be valuable.
Yes but I use separate passwords and webauthn is per domain as well.
I really wish I could block the repeated "Set up a passkey" nag by preventing my browser from advertising passkey capabilities. I don't understand why we can't have a Off switch on the client side.
You're not the first commenting on this and I wonder what's the trigger because I haven't seen a single suggestion for setting up a passkey anywhere.
I’m convinced that a lot of the passkey hate ultimately stems from the inconsistent and confusing flows that websites have implemented in the name of backwards compatibility with passwords. I have made some apps where passkeys are the only way to log in and it is such a lovely experience. It can be as simple as a single log in button by itself, with no intermediate pages or other UX. There doesn’t even have to be a form to fill out at all.
The problem of losing physical access to your passkeys is only really a problem if the site chooses to be strict. There can easily be a “Send a magic link” button where you type in your email. It’s the equivalent of “forgot password”. For most systems, it’s already accepted that your security is only as good as your email provider’s is. Passkeys make it straightforward to have an email-less model, but you always could have done the same thing with passwords. No one forced you to implement “forgot password”, it was simply a practical approach that was worth the security tradeoff.
People seem to assume that we should leave that functionality behind in the transition to passkeys but I’m not so sure. It certainly seems more practical than trying to get users to maintain physical backup keys.
The concern about exporting passkeys is valid but you can share via AirDrop. Doesn’t that work on Android now?
Try to give passkeys a chance. I really think the growing pains are worth it.
Nah, it's the transmission of the keys to Apple or Microsoft. We flatly rejected key escrow during the Clinton Administration, and I continue to reject it. And no, I absolutely do not trust their implementation of E2EE to mean there are no backdoors.
Are you aware that none of that is required when signing up for a site that supports passkeys?
I think there is some confusion here caused by sloppy use of terminology among FAANG and the standards groups. You’re right that, strictly speaking, Apple defined “passkeys” as synced credentials. And you’re also right to point out that, as a result, in order to consider them secure, you must trust Apple’s key storage and E2EE iCloud syncing, or the equivalent from other vendors. I wouldn’t blame you for being skeptical about synced credentials. The convenience may not be worth it for you.
However, crucially, synced credentials are just one type of FIDO2 credential. The other is a hardware-bound key from a “roaming” authenticator (aka a “security key”). These are never transmitted, never synced, and you can buy the security key hardware that generates and stores them from many different vendors, all of which are designed to be interoperable.
In other words, all passkeys are FIDO2, but not all FIDO2 are passkeys. Yet, when a website says it supports passkeys, it probably means it supports all FIDO2. And that’s because WebAuthn, the browser standard used to implement passkey registration and authentication on the web, supports all FIDO2 credentials, not just passkeys.
With WebAuthn (and most other systems), by default both platform authenticators (which would typically be synced, like you’re talking about, but not necessarily) and roaming authenticates (which would be typically be a USB security key, not synced) are allowed. I’ve occasionally stumbled upon sites that don’t allow platform authenticators, but I’ve never come across one that doesn’t allow roaming authenticators. It sounds like you want is the latter.
Apple could have avoided this mess by simply deciding that “passkeys” are the new name for “FIDO2 credentials” and then we could have synced passkeys and non-synced passkeys. But they apparently thought that was too confusing.
Ok, thanks for the explanation covering everything except the topic of my comment. And yes, I was aware. The point is, nobody (except those with a condescending PhD tone of voice) is aware of the loophole inherent in synchronizing passkeys.
I agree 100% i learned that my old school with whom I had linked to my windows computer and finished my degree with one day required passkeys rather than passwords on all devices. This force locked my windows PC back to passkey mode luckily I remember recovery account and got a passkey to work. But it took months to figure out why I had to use it. All the help board were said just click this button which was grayed out. Or set this register key which auto repopulated. It was an awful experience. I like my password as default
Ah yeah, Microsoft has this awful habit of just hiding the buttons for actions you don't have permission to do, which makes me feel like I'm being gaslit sometimes when a guide says 'there's a button right here' and there's not, and I've no idea if the button was just moved or if not, why it's not available (sometimes it's because I don't have permission, but sometimes it's because it's a different product with the same name and branding as a completely different product).
They’re bad and I wish places would stop being so aggressive about them (I’m looking at you Amazon and PayPal)
Asking Amazon and Paypal to not do something bad is a big ask.
Passkeys match a very unique situation where I don't want to store anyone's email address, don't want them to type anything, generally want to store as little information as possible. Also don't want it to be easy for people to share/steal passwords/accounts, and prefer storing on the local device.
Windows still required entering a local PIN, sometimes 2-3 times. I think the account recovery didn't scale, though haven't really tested/explored with any real users :)
I like passkeys. I dislike how websites vary the implementation of passkeys.
One thing Ethan misses: you don’t necessarily need one passkey per site. A single passkey protecting Google, Apple, Microsoft, GitHub, etc. can indirectly authenticate you to hundreds of sites via OAuth/OIDC (Sign in with…), while consuming only one resident credential on the hardware key per identity provider.
That makes the “hardware keys can’t store enough passkeys” argument much weaker in practice.
But that's another thing to avoid because now Google can lock you out of 100s of services at once if they ban your account.
We really need Firefox Persona back...
Passkeys lock you into a third-party provider ecosystem that you really should be trying hard to avoid getting locked into. They also add a quantum safety risk. Stay away.
I've resisted passkeys for some of the reasons listed. I use third-party password managers, they're device/system independent, and I can export the data when I want to. I don't see passkeys as a big advantage, or perhaps I should say the bigger advantage isn't really for the _user_.
Of course, at the rate we see security failures everywhere, I'm not entirely convinced writing your passwords on post-it notes wasn't such a bad idea after all.
Keepass2Android without network permissions saving the file to a folder monitored by Syncthing is pretty good though - it keeps responsibilities nicely separated.
I use passkeys, hardware ones, and I am very happy with it.
I don't understand why people dislike passkeys, they are the most secure system we could possibly do and I am also very happy that the major companies are accepting them.
It seems to me that people would prefer to be insecure and use something that is familiar and easy to understand, than be secure and have to do something different.
I find Passkeys are amazing once you accept they are not your only path in, just a much more convenient one. Have your accounts and totp with an authenticator set up, but add on every device you like a passkey to create a fast path.
Removes the need for syncing any passkeys, the risk of getting locked out, and the terrible support of 3rd party password managers providing passkeys
I have not and will not use them. There have been a few times a site has required one and I’ve just moved on to something else.
This blog post and also comment section are a tire fire of misunderstanding. Passkeys solve a couple crucial problems 99.99% of users face, including smart, technical ones who use password managers. They have great ergonomics. They do not obviate having some kind of recovery flow and are not intended to.
I'm was tempted to come in here and say "you're holding it wrong." But then I quickly realized that I had to spend weeks changing my behaviors and messing around with devices in order to get it to work correctly.
As someone who's OpSec puts swiss cheese to shame Passkey has been a godsend. My passwords are actually much better because of it.
I will say it. They are all holding it wrong. But it's not their fault. Its how the platforms designed their implementation of it.
This article touches on something I've been ruminating about the past few months - the lack of control users have over their own security posture.
Like many people, I use dozens of online applications a day, from banking through to childcare booking platforms to online shopping. With data breaches becoming ubiquitous and a common occurrence, providers are under pressure to secure their platforms.
This means they're all attempting to implement "best practice", with various degrees of maturity and efficacy.
The consequence of this is a huge degree of friction on a daily basis. Myriad authentication apps and schemes. Some using TOTP. Some using SMS 2FA. Some using push notifications through their own app. Some using magic links via email. Some with passwords, some without. Maintaining all these has become a significant administrative burden.
But the enforcement, and inability to opt out, means I have limited say in choosing NY security posture for each service. Some accounts I have are throwaways that I couldn't care less if they were compromised. Even with strong and secure passwords, I still need 2FA. Worse, those that I do want a strong security posture with often have a backup recovery scheme, such as magic links via SMS, that I deem inherently insecure. Yet I am expected to trust that the platform provider knows what is best for me.
As mentioned in the article, losing access to platforms has been a bigger issue for me than account compromise. For example, I had an old Twitter account I wanted to access once X took over. Although I had the password, they had implemented 2FA since the last time I logged in. Since In didn't have a current email on file with them, I couldn't receive the verification link and have now permanently lost access to that account. Providing that I had the (strong) password, that I was using the same static IP address I originally signed up with, and providing government identification was insufficient to regain control.
I'm a fan of passkeys. I now also use a Yubikey. But simple passwords still have their place and can be useful and secure I'd handled well on both sides.
My thinking is that Passkey is an extremely good and, in theory, extremely easy solution to security, authorization, and login issues. The problem is that Google, Apple, and Microsoft have done a just horrendous job, and made it suck as much as possible.
They didn't want to cooperate, and they wanted to make passkeys transferable within you cloud account, while not cooperating with anyone or anything else. The result was that you have no predictable and stable pattern/protocol/interface, or even general description, for how, for instance, a website connects to the passkey or even a hardware key, if you wanted it.
We basically have all the browsers, the operating systems, and the password managers, all fighting over who gets to store and present the passkey. And everybody assumes that they are the only one that exists and actively tries to fight the others is they can.
The basic technology is really good and could work well, but the large asshole tech firms focused on self-interest and walled gardens and made it insufferable.
I’m still terrified how normal people are going to navigate being locked out of their email account because their device that was their passkey is no longer accessible and there’s no backup solution to restore access.
I’ve similar issues even in a lower level with LastPass where it won’t even let you enter your two factor if it doesn’t recognize where you’re coming from but then you have to be connected to your email, but your email password is stored in LastPass. There is a real possibility of being locked out at all devices at the same time and not being able to get in to the first one.
I just had a very annoying interaction with the tailscale Android app:
It wanted me to log in for some reason even though it had worked fine for months. Login uses my Google log in.
When I try that, Google asks me for a hardware key to complete the login, even though it's my phone and I'm already logged in.
Eventually I figured out that if you select "log in using another device" and then click cancel when it brings up the qr code, you can select a push notification on "another device", which actually pops up on the same device. Do that once and it fails. Do it a second time and it succeeds.
All to use the tailscale app on my own phone.
> When storing passkeys in a password manager like Bitwardenor KeePassXC, you end up fighting the platform
Very odd. I use passkeys extensively with BitWarden and I love it to the point where it's my preferred way of securing things at this point.
The fact that the website presents the question to BitWarden in a structured way (what website, what username) means that I never fight with selecting the right account to get the password for (because I commonly have multiple accounts for a single site) and it generally makes the login flow much smoother.
Environment is MacOS with Brave/Firefox + iOS.
My only issue is the ... unclarity... with them.
The option pops up in the middle of a normal log-in flow. I'm guessing most non-techies don't know how it's implemented.
Oddly, some login flows display a normal user/pwd form, but you get the in-browser "use a passkey?" option/popup which further confuses matters.
Thankfully, me, wife, and all our parents are tech-savvy enough to use password managers, so the fallout from lost passkeys hasn't be an issue. But I certainly see how it would be an issue for anybody entering passwords from memory or similar.
> By design, you cannot create a backup of passkeys on a hardware key
In fact, I think it's technically possible. But it's true, as of today I don't think anybody supports it.
I was experimenting on solokeys with ios, in principle we could backup Passwords (the ios/mac app) into a solo key, space permitting, including passkeys, regular passwords and totp (not wifi passwords). I believe the same is for Android, but haven't tested yet. This is all experiments I've been doing on my own, there's nothing ready to be released.
That quote is referring to the mechanism for backing up passkeys that only exist on a hardware security key, which deliberately does not exist. Moving keys onto a security key is possible for some devices, but that is a deliberate compromise, as these devices are designed to generate their own keypairs and never leak secret key material (thus preventing backups).
Ops, I may have misinterpreted. I read it as take a passkey and copy/store it inside a hw sec key. Thanks for clarifying!
I like the idea of passkeys. And ive been seeing better support for them. I use Bitwarden as a passkey manager and it mostly works across devices. What's irritating is when the provider messes up passkey integration.
As an example, recently Sony asked me to setup passkey. I did. But it skipped bitwarden somehow and went on my phone.
I tried to login to my Playstation account on the computer and it directed me to continue logging in on my phone. I did so and then the web client just said an error occurred.
I turned passkey off on Sony.
In a corp environment, it is the business's problem when a user's passkey devices fails. In a personal environment, it is the user's problem. Specialized knowledge and preventive processes in the corp environment aren't present in the personal context, and saying "pretty please" to Google or Apple when something goes wrong is usually a waste of time. I 100% agree with TFA -- "damage expectation" is probably higher with passkeys.
Why doesn't Chromium let me turn this 'feature' off?
They exist for sole purpose companies can just shoot the "we have been hacked, but worry not your 'passwords' have not been leaked" email.
It's entirely one sided solution.
But they could always do that with regular passwords.
Like, no company should be storing anything but a salted hash of their users' passwords.
That's why I just implanted my NFC passkeys. I've got one in my left hand and one in my right forearm. If I lose access to them, I have other, much larger problems.
I have passkeys on literally everything that will support them and store them in 1Password. I can access them on my laptop, phone, desktop without issue.
Linux support seems really bad, so not very useful for me
Relevant side project of mine: https://monjuik.github.io/shellty-passkey-server/
It’s basically server side of passkeys as boring as possible: self-hosted Go binary, Postgres, REST API, and no requirement to move users into another IAM system.
Would be interested in criticism from the passkey skeptics here.
I've not yet encountered a site which has even suggested I use something like a passkey. Under the assumption that you're doing the Right Thing, and avoid using Apple, Alphabet and Microsoft's services - this is a non-issue. In fact, even if you use their non-login-requiring services (e.g. YouTube, Bing, Google search) - again no passkeys in your life.
I hated them at first, but since I am already dependent on iCloud Keychain to manage my passwords, I just figured there is not really any additional risk. I just make sure I will always have multiple, healthy devices, which are always patched, charged, and sync'ed. And don't put them all in the same physical location at one time.
Multiple authentic Apple(TM) devices? What a coincidence, that the solution to security should be so beneficial to a giant corporation.
I use passkeys, but the UI seems less user-friendly than SSH which is conceptually similar. When I SSH into a machine that has me in authorized_keys, it just logs me in. Passkeys are like 8 clicks telling the site and browser repeatedly that I want to use the damn passkey. Can't it be "remember me forever"?
The page forces a jump to top when in reader mode in Safari on my iPhone. Hostile. Wanted to read the article, but left out of annoyance.
Yeah, but I agree with the headline. I don’t want to be tricked into enabling this “feature” that I find burdensome, but some sites try hard to coerce enabling it. The modern web is a bummer.
heya! sorry about that, I don't usually have an iPhone on me to test updates to my site so I must've broken something in its reader mode. I'll be borrowing one tomorrow and try figure out what's causing this :)
Passkeys in bitwarden have been working pretty well for me overall. Website support is still spotty. Sometimes passkey logins won’t work, or other times the website will still ask for a “third” factor code.
For less tech savvy folks, passkeys are a godsend since they don’t have to remember passwords or fish around for codes
One point that Google wants to own all your data but have the power to ban you with a faulty ML algorithm with no recourse. False banning that affects someone's normal life must be punished if the service provider tries to lock you in. You and lock people in or have power to arbitrarily ban them, not both
> When storing passkeys in a password manager like Bitwardenor KeePassXC, you end up fighting the platform
I must say it's pretty amazing how well-integrated is Bitwarden with iOS now, passkeys, password generation, everything. I have disabled Apple passwords manager, and Bitwarden feels like the native solution.
Passkeys suck because only the wealthiest 5% of the world is all-in on one ecosystem (such as Apple) while the remaining 95% uses a Windows laptop, an Android phone and (for the top 5-35%ish) maybe an iPad. All of these OSes push hard to get you to store your passkeys with THEM so it ends up a shitshow with everything scattered everywhere.
And why do the OSes push for this so hard? Because the goal of the execs is lock-in and control. And their lackeys here on HN who implement this stuff and their families are the 1% who are all-in on one ecosystem so they arrogantly believe "this all works great and the masses are just too stupid to get it".
Just a small clarification, attackers can definitely steal a passkey from your key store and use it if your corporate settings are incorrect IE. device attestation is turned off.
My company has already responded to multiple breaches where this has been what quickly follows an initial intrusion.
We added passkey support to devices for convenience, but I feel like it is a big part of what has made them so confusing. The mental model of a hardware security key is _so much_ more familiar and intuitive.
(But you still can’t “copy” a key, which is unfortunate).
I feel like we're solving one security problem while creating another. Passkeys make phishing much harder, but putting so much trust in Apple, Google or a password manager for account recovery creates a pretty significant single point of failure.
What happens with the Fifth Amendment when a platform imposes passkeys and you don't have a device with a pin (if that even possible to combine them) ?. Given you don't see the password, then you can't memorize it.
every single website i use that supports passkeys prompts me to save a passkey in pw manager every single time i login. not specific to the password manager or browser really, and existing do not matter. every chrome based browser cant keep track. makes it look like a totally garbage, amateur implementation getting prompts for saving a new passkey constantly
The future of authentication is....CertFP. Basically the same as passkeys, but a based on certificates that you can backup somewhere.
If the browser supports them and stores them securely you're safe as houses even after a breach.
I wouldn't mind it if all the services stop working properly when you use a Passkey but still want to use your other stuff like password and 2fa through app...
GitHub breaks with this, PayPal breaks with this...
password managers that allow to export OUR passkeys: Bitwarden, Enpass
it's all backwards, I agree, even worse that we trust "sync to the cloud" but don't allow users to own their credentials.
I absolutely hate them and avoid them everywhere I can. I'm not bound to a single device or I don't want to get bound to some, and some pages quit your option with a normal password login after setting up a passkey. Absolutely frustrating.
Passkeys are really an abdication of cyber security responsibility by the vendor. Offload everything onto the consumer, and you have plausible deniability for anything that happens.
I belive that passwords with TOTP are far better than passkeys.
Surprised to see so much hate towards passkeys. I absolutely love them when I can use them with Bitwarden and my own SSO. Sucks when I am limited to hardware tokens like yubikeys.
I am even more surprised about the multiple down-votes for this comment just because I like some feature. Must be a bunch of grumpy old keyboard warriors on this thread. 0__o
Personally I love passkeys and think it’s not deployed enough. It works great (for me anyways!) and it is SO MUCH better than “login with email” that is everywhere now.
Well I like them, as an option. I offer using passkeys and email interchangeably; if you lose one you can recover with the other. Passwords, SMS, TOTP are out for me.
Very much in agreement with this post. They are secure, they also cause me great fear of getting locked out of my own accounts if my hard drive crashes.
I didn't like the passkeys that were handled by Google and only worked on my phone. But now that most of them support bitwarden they are really convenient.
Ecosystem is not mature yet for individuals?
Probably hundreds of millions or even billion people have devices that support biometric auth. How is that not mature?
Devices that break or get lost, and then either the user had password authentication activated all the time anyway in addition to the passkey, or they have the classic "mother's maiden name" recovery path, or they get locked out of their account.
Brilliant security: a highly secure high-tech shiny front door that can randomly fail to open, so you still need the low-tech back door, which is the one potential thieves will use.
Mind you, it can work if the back door is old but sturdy (basically, for a bank that will ask for KYC authentication, or in the worst case you can set foot in the brick-and-mortar branch showing your face and ID and ask for access) but for pretty much every other service it introduces risks for very little or no gain.
They're great when you don't own a phone - when you can't use random 2FA "Apps".
As many USB-security keys can be used passkeys.
> when you can't use random 2FA "Apps".
You don't need a phone to do 2FA :
https://github.com/pcarrier/gauth
Not all 2FA is TOTP or a similarly-open scheme.
I like using passkeys in bitwarden from Firefox, I just wish it didn't popup a dialog that's usually behind the browser.
> Although operating systems have recently introduced APIs [...] for third-party tools to hook into, the experience remains fragmented and lacks the decades of UX polish towards password autofill. Autofill outside the browser and inside native applications remains especially inconsistent.
I disagree. It is just a wrong statement. Passkeys actually eliminate the flaky autofill part where password managers have to parse input fields. Ever since I learnt about KeePassXC and KeePassDx, I've tried to migrate as much of my accounts to passkeys. The experience is wonderful and KeePass allows me to see the private key behind the passkey - yes, yes, yes!
The risks mentioned are not equal. I’d prefer getting locked out of my account to having all my money stolen.
Passkeys are a great way for attackers to have a secondary login into your account (e.g. Outlook, Gmail, etc.)
Is there a reason why passkeys couldn't be used in "expire-periodically" mode?
Then how do you log in? Not all sites let you keep password logins after.
Then passkeys are a guarantee of account loss, if there is no reasonable way of recovery.
Yes, that is what everyone keeps complaining about and the people who insist passkeys are the best continue to loudly and totally ignore.
The repeated response to "I lost the passkey, what now?" is apathy. It is your fault, you should have done better, eat it loser.
Because companies built passkeys for their own needs, not for users. In a managed device setting, there is a response: You go to IT and get provisioned new credentials. These companies don't care that you get fucked because they just don't care about your needs at all.
Your passkeys should go in your password manager.
What benefit does that give you? Passkeys cannot be moved, by design. So for the website, recieving the same one means you're talking to the same device, always.
The purpose of rotating passwords is to cycle out potentially compromised ones, due to phishing attacks, keyloggers, shoulder snoops, etc. But those cannot exist with a passkey.
Doesn’t this mean that a compromised device with passkeys on it is worse than a compromised password since the passkeys can’t be rotated? I feel like the answer is obvious so there must be another angle I’m missing
Passkeys can be rotated, of course. The question was whether they should be rotated on a regular basis.
What kind of compromise are we talking about? Was the device stolen? Then yeah, you need to rotate passkeys (and all your passwords, and remotely cancel all your live sessions, none of which is new).
Was the device hacked from afar and the data read off of it? The passkey is probably fine. You can rotate it if you want to, it's not a bad idea, I probably would to be certain, but you're not pwnd even if a bad guy got a shell for a while, heck even if they got a root shell.
I understood the question to be "should passkeys be rotated regularly" to which the answer is probably no because there's not really a compromise mechanism that periodic rotation defends against as far as I know.
Rotation defends against secrets that leak through normal use and without your knowledge, like a password entered into a phishing page or snooped over your shoulder or cracked from a breached hash. Passkeys aren't vulnerable to those things because they never travel over a network, are never seen by the server, are never seen by their own users.
You change the locks on your house when a key goes missing, or is known to be in the hands of somebody you don't want getting in, it's not something you do every three months just in case. Same with passkeys.
using them with 1password has been pretty effortless. 'want to add the passkey' sure why not. 'want to use the passkey?' sure why not. for me it works across devices/os/platform so not sure what the big gripe is tbh.
To guard against lockout, you need to be able to log in from multiple devices. But you don’t need to copy passkeys around to do that! Instead, generate a new one for each device. This is similar to setting up ssh by copying public keys, not private keys.
(Or since syncing passkeys usually works within ecosystems, you might just need a passkey per OS.)
I don't like attestation. That is dangerous to user freedom. I don't mind other parts of this technology.
Attestation already destroyed user freedom in mobile app ecosystem. You can't just implement your version of some mobile banking app or whatever just by using original app's API, because dark overlords of gated app comunities allowed app authors to prevent this on OS level by giving them attestation tools.
I just don’t get how passkeys are supposed to be an improvement.
On any site where I create them the login experience gets worse. Sometimes I get a QR code to scan (terrible, almost never works too). Sometimes I am offered to login with passkey which I have and it doesn’t work. Almost always I need to fallback to password and it just sucks.
I hate passkeys. I wish there was a checkbox somewhere to tell all websites that I never want to use them.
I don’t get the hate for passkeys. It feels like a state sponsored attack at a reasonable (not perfect) tech.
Locked out of device? You should use a password manager which you can still log into again on a new device.
Want to log into a service on a device you don’t own? Log into by scanning a QR code with your passkey (windows offers this standard when you keep a passkey on a different device for example).
It ultimately comes down to this: it is utterly dangerous and stupid to depend your accounts on third parties (including your phone).
I personally love not having to type in a password
I don't like passkeys either (I use a password manager anyway, and long secure unique passwords), but I understand the need. But yeah it really annoys me when every website wants to give me a passkey, or wants me to use a passkey, instead of just taking me to a page where I can enter my novel-length password.
I hate them, mostly because I am forced to use them.
They provide crappy usability, they're expensive, they're easy to lose, you can't use the physical keys when doing remote desktop access.
My job requires me to use them. I use only for the job and nothing else. For sites requiring 2FA, I use TOTP (time-based one time passwords) from KeePassXC.
the only thing I don't get is why a 4 number PIN on Windows Hello counts as a passkey. Obviously it can be as long as you want but
the pin is not the passkey, the pin is security to access the module which holds your passkey.
This is generally the same experience I've had.
Microsoft is especially poorly prepared for this - Often if you have a passkey, it will CONTINUE To ask you to create a passkey (a new and different one), and it may save it in a different place, which is infuriating.
Strong password + MFA is the way, and I don't see that changing.
I also despise that in between OSes, browsers and certain sites I am having to close/cancel/skip sometimes three or even four dialogs to say "No, I'm not interested in changing my login method to passkey" (PayPal is one example).
I had to setup a Passkey recently and wanted to store it in 1Password and the experience was quite absurd.
I don't know who designed this or who thinks these are acceptable affordances, but it seem to be part of the same disingenuous push that's behind passkeys in general.
What is the point? As long as you (the service) hash passwords securely, and the users use random passwords with a password manager, you are fine. A password is far easier to type onto another computer or a diffrent web browser.
I take passkeys over the unbearable cargo cult that follows LLM companies, namely companies' newly found obsession to "sign in via email".
Ideally optionally followed by a 2FA (naturally, via text, delivered straight to my Mac, even further diluting the questionable security of the whole exercise) and naturally, to be repeated every 2 days or so, since "stay logged in" is the biggest lie after "I've read and accepted the ToS".
Your phone (which is probably what, 80% of relevant traffic these days?) likely has a perfectly fine password manager built in. This "sign in via email" trend must be every scammer and phishers biggest dream come true...
Almost everything has supported email-based password reset since 90's for all the problems it entails.
I am looking at a new project that uses magic links sent by texts. I have been there and done that with authentication systems and that's good enough for a low stakes ludic activity.
Honestly I like passkeys much more when the majority of my usage is through my mooltipass rather than using those software keys
Really just wish there was a newer gen of the hardware
I'm not going to suggest it's a perfect system though, but I do much prefer it to SMS/email "2fa".
Passkeys have made my life very easy. Especially using Proton Vault.
If you think passkeys aren't ready yet, blame the people implementing it on their platforms.
If the concept isn't easily understood nor well implemented by the majority of platforms, it's not a good concept.
We've been using SSH keys which behave the same for years. At this point it's mostly clowning by old farts in these articles.
SSH keys are much easier to use and understand. Heck, passkeys could have just been a ZIP file holding a key-pair instead of whatever hostile design by committee we ended up with.
If they actually worked like SSH keys that would solve some of the problems with them. (like keeping a backup that you can still enroll into new accounts without it being present).
There's plenty of password managers available that keep the backup for you in multiple ways.
At some substantial risk to the important key material, yeah. You also don't get an offline backup.
Related: the UX is currently terrible. Every time I go to a website that has passkey flow, I'm presented with: - MacOS native UI; which I cancel; then I see - Bitwarden UI; which I cancel; then I see - Chrome UI; which I cancel;
Like, seriously?
Great writing and points Ethan!
I absolutely hate that so many sites are begging me to use them.
I find it annoying that so many apps and websites push passkeys onto users without informing them the basics of passkeys, including how it's associated with those specific devices/password managers or how to prepare in case a device is lost. Meanwhile as a user who uses a password manager to generate a different password for every site and has autofill enabled everywhere, passkeys barely improve my life if not making things more confusing.
I hate that there's no accepted definition whether passkeys should be considered MFA or not. As a result, some sites treat it as MFA and you just provide passkey and you're in, which I like. Other sites still ask for a second factor after I provide a passkey which I think is stupid. At that point, it's simply another password I can't remember. I should not be prompted for a second factor after I log in with a passkey.
Eh. Not worth complaining about.
Passkeys work nicely, and I'll use them, in cases where I want decent security, but I don't consider them the "Philosopher's Stone" of regular end-user security. I think they are still a bit too "fiddly" for your average Joe[line].
I mean, they're basically just client SSL certs, but used for auth instead of transport
It's entirely possible for server side app to tie a client certificate to a user account and offer one click login and it has been since the 90s.
Username and password was a predictable flow. Passkeys are just a small component in the modern obstacle race of logging in. Every few months a new credential or ritual to access your own resources .
These are the four flaws with Passkeys I've found after implementing them on our website. I actually like them now. But, It made me discover why people dislike them. The vast majority of problems are _the way websites implement them_ and _the way password managers today_ work.
Website problems:
* First big problem: you try to kludge them as an "add-on" to a password or SMS "2fa". Just rip the band aide off and let people go 100% passkey by default. It's actually really easy for users. We do a push at the end of their onboarding flow and have a 95% conversion. Users love it and its seamless.
* Don't make people enter a username. Just have a "login with passkey" button first, and thats it. If the HIPPO in your organizations insists a username-password still be available, make the user navigate to a secondary page first to do so. Make the passkey the first-class citizen.
Password Manager problems:
* Google, Apple, Microsoft are trying to lock people in to proprietary password managers. Microsoft's password manager, plus their "microsoft account" experience is a steaming pile of shit. The key here would be portability. An export format exists for the public key (thats how enrollment works): It's a but of digits in ANSI X9.62 format. Not hard. The private key would be an unbelievably simple export.
Protocol problems, and I'm happy to be wrong here:
* The client does not sign the server issued nonce (aka the 'challenge') during the authentication flow. This is kinda weird IMHO. Technically, yes it is secure, but it relies solely on the TLS channel heuristics. It'd be much better to have the client prove the signature on enrollment as layered security.
To address the author fears on attestation: This is a real threat to users... imagine a website "only accepting passkeys from OUR password manager". Luckily, Apple has done us all a favor and outright killed that part of the protocol by refusing to send this required fields there, protecting all users.
Overall, you should use them. We need one tiny change to the protocol and better password managers.
I don't know much about passkeys, I have never implemented them. I once tried to find out more about them but all I could see is "you're going to regret using this one day".
I have said before, I'm personally not interested using "Something I have"/"device bound" as an authentication factor. I'm also not interested in the sync "workarounds" that store keys in the cloud.
People have replied it's possible to extract the private key, but it's not clear to me that that's usable (maybe it is I don't know). It's certainly not in line with what passkey devs want people to do and not do, so I'm not interested in "fighting" against the "flow" so to speak.
I'm happy with TOTP, as I can manage and use the codes where I want, under my control.
> Both Apple and Google want your identity anchored to their operating systems. The “happy path” on their devices is to use their synced passkey management tied to your Apple or Google account.
<sarcasm>On the plus side, this way passkeys can also be tied to age/identity verification.</sarcasm>
passkeys are excellent for security and horrible for usability. We did a students' project on that and decided to not invest on them, yet.
But, hey, here is the new startup idea for you: make passkeys great!
I went in expecting yet another screed about how passkeys were not issued by RMS in a FOSS encyclical, and therefore not only were they insecure, but they were also a morally bankrupt abomination. I was pleasantly surprised to read an actual thoughtful critique, albeit one I largely disagree with.
The author's assertion that the greatest risk to an individual is account lockout versus phishing or password harvesting is just not grounded in reality. I get phishing emails and SMSs daily. The criminal ecosystem running these campaigns is extremely active already and set to become even more so with LLMs. These campaigns are by far the biggest threat to normies.
Whereas account lockout happens most often with multiple failed password entries, which passkeys completely eliminate. I just don't know where this risk evaluation comes from.
The author also points out that even with passkeys, if you're able to also log in with e.g. security questions, you still have a much weaker security footprint for that account. This is true, but it's also true of a TOTP second factor. So I'm not sure what the criticism is here.
The exportability argument is a real weakness and something I'd like to see addressed. Passkeys don't have an equivalent for backup TOTP codes that you can just write down somewhere or trivially store yourself. But it probably wasn't in v1 because the people who designed passkeys figured that websites would not go all in on them immediately and would preserve other authentication methods, which is exactly what's happened.
am i the only one on HN who really likes passkeys?
so much better than fumbling around with a password managers
Lots of people like them, but it's clear from the complaints there's another large group for whom they are problematic. Enthusiasts are going to have to actually address those issues if they want adoption.
[dead]
[dead]
[dead]
[dead]
[flagged]
I've seen it. Websites are pretty inconsistent about the flow but I've had a few just try to install a passkey when I log in (amazon does it. Paypal seems to do it but only try to use it on the same browser it was installed on, even if it's synced through a password manager, just to be different. The more reasonably ones have a 'log in with passkey' button but this isn't universal. Microsoft seems to just nag the user on login periodically in their classic 'Yes/Ask me again later' style of 'consent'). You can, if you're paying attention, avoid it actually happening, but the average user isn't going to notice until they suddenly can't log in because they're on a different device. You can see some advocates are pretty vocal about making them mandatory as well.
I feel like dozens of sites constantly nag me about this. The best ones at least save a cookie to note I'm not interested, such as GitHub.
Every time I login to certain sites (like my health insurance, for one) I get a passkey prompt (system dialog) with no way to keyboard-dismiss, so I'm forced to move my hand over to the mouse and figure out which of three poorly-named buttons to press to get on with the login and ignore the passkey.
It's a minor inconvenience, but happens so regularly I hate it. It also stops the login flow until I dismiss the prompt, which is also annoying as I could've already gotten to the page I wanted to get to in the time it took to dismiss the dialog.
You must not use Outlook
[flagged]
Passkeys work great with Bitwarden too. With it being set up on all of my devices I actually often prefer the passkey experience. Too many people depend on OS password managers or even the ones built into their browsers.
For me passkeys work wonderfully synced in Bitwarden on Windows, Linux, and Android. I have no idea what this article trying to say, except some negative opinion that should IMO be ignored.
The article was clear and reflects my own opinions:
If you use an untrusted machine, you either revert to the least secure backup method (your master password in Bitwarden) or don't log in.
If your phone is your trusted device and becomes lost/stolen and then replaced, you revert to the least secure backup method e.g. password, security questions, or even waiting to be manually verified. This can be problematic if your online bank requires 2FA so you can purchase the replacement phone.
The QR + Bluetooth thing sounds dumb as hell.
Kiwi Browser doesn't support passkeys even with Bitwarden on my device. I have to choose between an inferior (for my needs) browser or passkeys.
-----
Rather than passkeys, which always rely on a trusted device, my preference is, "I use a password manager and site-specific generated passwords, and when I try to log in with only a password on your site, send me an email (whether pass or fail), plus never require 2FA except for banking and perhaps to change email/password"
It's unlikely I'll lose access to email notifications at the same time someone tries logging in with a phished password (except, obviously, my email password, which should only be changeable with 2FA) unless I am specifically physically targeted or astonishingly unlucky.
If someone uses a fake website or other MITM method to grab my credentials, I'll be fine because I'll get the "hey PennRobotics you logged in to crabcakes.com just now from a iPhone" message and then immediately triage that unexpected situation.
If I need to log in to a website in private mode or on a different device, it takes an extra 30 seconds to log in to my password manager plus no device dependency.
-----
The passkey problem for me? You need some hardware or else it's glorified 2FA or even (in the case of the Paypal app) 1FA applied twice, and as soon as you lose EITHER the hardware or the "what you are/what you have" part of 2FA you enter a world of trouble.
Also, ToS lockouts happen. When Google terminates your account (for any variety of imaginative or realistic reasons) there isn't really any method to use or export your passkeys anymore.
As someone who uses a single password manager on my computer and phone, I don't see the problem with passkeys. I use Safari on both and I never even had to "set up" anything.
I can see why they would be problematic for people who otherwise live life with a single love2025 password though.
Imagine you lose your computer and phone. How do you recover your digital accounts? This happens every day to someone. The most common scenario being a house fire or robbery.
If only smart people didn't already have a solution to this https://support.apple.com/en-us/102641
The same way you recover your account when you lose a password.
I don't get it. I recover an account at ticketmaster by receiving an email. I recover an account at google by???
Receiving an email at your backup email address? Getting a text message? It’s whatever you have decided to set up in your account, the same as with a password.
I think the point with a passkey is that those very loose backup methods are required, since just knowing the password is not a thing. Everyone gets a new phone and is at risk of the previous one being unavailable. So passkeys mean that there's no way to deal with that reality, and also be truly secure.
I don’t know any of my passwords and haven’t for a decade, so passkeys are no different in that respect.
If the worry is your phone getting lost then use a password manager that syncs to the cloud and log in with the same passkey using another device. I just got a new iPhone and logged into a bunch of things on-device using synced passkeys. It worked just fine.
Every conversation about this seems to involve someone asserting that improving upon passwords in any way at all is unacceptable unless the solution is perfect in every possible way, with the goalposts constantly moving.
What benefit does your 128-bits authentication schema gain when anybody can just clone a phone number?
Or do you demand that the user has an email with that 128-bits authn too, with a key on the same phone that was lost?
[flagged]
The article asserts with little proof that lockout risk is a big problem. But consumer sites themselves basically 100% of the time have a recovery path that amounts to a SMS code or emailed code.
The only part that is very persuasive is the part about storing your passkeys with Google or Apple integrations, and what happens if they ban your account. But the same argument would apply if you’re only storing your passwords in a Google or Apple password manager.
I use passkeys and I always store them in a password manager I control - but usually I also store another one in the OS on Windows, Apple, and Google. Best of all worlds. Also, I appreciate that idiots aren’t forcing me to “change my passkeys” every 90 months like they STILL do with passwords!
Passkeys are mostly useless because of that.
Their security is nearly universally undermined by reset mechanisms.
There are virtually no sites where passkeys cannot be bypassed.
I know I can't speak for everyone, but I at least don't see the passkey as even pretending to solve that.
There frankly is no solution for the problem you are talking about, because the 'average person' is extremely disorganized and barely understands anything about security or authentication, let alone how to manage their passwords/secrets effectively. And it appears consumers "don't want" that... arguably for good reason. We accept a tiny chance of being hacked in exchange for knowing that if our house burns down with all our devices in it, we won't be locked out of an Apple/Google account for life, even if we weren't wise enough to keep a DVD full of exported passkeys or lists of recovery codes in a safe remote location.
Passkeys are in practice for one thing and one thing only (and they're very good at it!): Replacing passwords with something that unlike passwords:
1. The secret doesn't need to travel anywhere so it can't be stolen at authentication time
2. Uniform and large entropy not bounded by memorability, creativity, or misguided dumbass website owners ("Please use THESE AND ONLY THESE 'special' characters: ! @ $ % _ ")
3. Impossible to be improperly reused
4. Each device's secret is independently revocable.
5. Extremely difficult to 'phish' on a fake website.
Even if we don't fix the "analog hole" so to speak where you can either SMS-reset or socially-engineer someone into resetting it, if we could kill passwords globally and replace with Passkeys, it would be probably the biggest win for security. I'd challenge anyone to name a better single thing we could do.
> A combination of randomly generated passwords stored inside a third-party password manager, paired with an independent TOTP app, gives control to the user without giving up the flexibility of plain text.
No grandma, don’t use the unphishable one-click passkey setup that syncs across all your devices. Instead, install a third-party password manager (no, no, not the one built in to your device or browser), then another TOTP app on your phone. It’s slower and more susceptible to phishing, but uhhh, what if you’re among the one in a million people that has their Google or Apple account wrongly banned?
Infosec for 15 years, and I do not want passkeys either. Anything that attaches itself to hardware is susceptible to loss. Anything that attaches itself to hardware makes it harder to use services from a new device.
At some layer you have be able to access your services with password/totp if only for recovery. Passkeys add a layer for minimum benefit, in my opinion.
Yes, push based totp and passkeys are more phish proof but for non techies, managing them is its own job.
> syncs across all your devices
My Macbook can sync passkeys from my Android phone?
Yes, there are several ways. You can use Google password manager on your MacBook. I believe 1Password and Bitwarden support this too. You can also use the Android phone itself as a passkey device with the QR code flow.
The UX is obviously a lot smoother if you have an iPhone and use iCloud keychain for everything, but that’s not an uncommon setup.