Passkeys are a terrible idea. They are security theater and a disaster for users waiting to happen.
Imagine you're on vacation and have lost your phone. You want to go to a cafe and log into a chat app, an email service, whatever to contact your family. In the world that passkey advocates want this is impossible via the passkey flow. If you can't authenticate via a primary device that contains your private key, you're f-ed. Service providers know this so of course they will provide recovery mechanisms. (Not consistent recovery mechanisms of course, each will have their own convoluted and likely to be broken ones). If the recovery mechanism allows for knowledge based recovery (challenge questions) then you're basically telling people that they need N passwords rather than one password. Maybe that challenge question is just a long password (recovery key). Maybe it requires access to another system, which you likely don't have in this circumstance. So you're either back to having passwords, or you're f-ed. Security theater or a disaster.
A service only has value if I can access it. I should be able to sit down at any computer in the world with the knowledge in my head and get access to any online service to which I subscribe.
You made a case for Passkeys having a flawed UX, but not one for them being security theater. Words mean things; "security theater" is a term of art for things people do for enhanced security that add no security, and Passkeys are not that.
Downthread, you claim that Passkeys (if stored in a password manager) are no more secure than a random password stored in that password manager. That seems obviously to be false; Passkeys are phishing-resistant, and stored passwords are not. So that might be where your misconception comes from.
I don't understand what is meant by phishing-resistant. There always need to be systems to authorize new devices or allow users to re-prove themselves if they loose the primary proof. Is the idea that scammers would have difficulty adapting phishes to access these resources? If "hello this is Jeff Bezos what is your password" works why wouldn't "hello this is Jeff Bezos please click authorise a new device so I can transfer you 1000$"
>I don't understand what is meant by phishing-resistant
By far the most common phish is "click this link or your account will be shut down" which brings you to a fake Microsoft/Google sign-in page, where they say "please enter your credentials" (or some variant of this). This flavor of phishing is eliminated by passkeys.
Phishing schemes will try to adapt, and some may still be successful. That is why it is not called "phishing-proof".
That's a particular scheme that might be fooled, but what's stopping someone from making a version of the same scheme that redirects to a prompt on the real site which authorizes them as a new user? I'll admit web technologies aren't my area of expertise but I have little doubt it's possible based on my interactions so far. E.g. discord allowing me to log in to a new device by scanning a QR code with my phone and clicking OK.
Ultimately the point of phishing is to attack the user instead of the technology. If the user has any control over access to their account, phishing is largely unaffected.
Often they allow picking an entry for arbitrary domain names, made necessary by firms (such as Microsoft) randomizing their login domains to look like phishing domains.*
* Not what they are doing, but to the casual user, logging into xbox.com, office.com, or even microsoft.com through something like microsoftonline.com may as well be phishing.
I wouldn't assume a 3-character .com is a phishing domain, they're hardly cheap and disposable. But I get your point, I've seen some suspicious (legitimate) alternate domains. Stuff like (not a real example) amazon-fulfillment.com.
You’re loosely describing a CSRF vulnerability, which do occur but people try to design against them and mitigate them. For example, actions that mutate often require POST (which won’t be triggered by a link), cookies may be marked strict (and not sent from frames or following links), etc.
No it isn't, because people will manually fill things in when autofill doesn't work. People will go out of their way to feed credentials to sites that look authentic; it's a genuinely hard problem. (I've had the displeasure of having to work on it for financial industry clients.)
Ironically, just about the only sites where it makes sense to do this as a user are... those from the financial industry, who in their infinite wisdom frequently decide to prevent autofill. There's otherwise basically no reason to ever open the password manager or to know any of your passwords.
In any case, if you have a KBA recovery mechanism, then anyone who would go dig through their saved passwords to put into a phishing site will also just enter the recovery info into a phishing site and enroll an attacker's passkey.
Can you elaborate (or provide a source that does) on how passkeys prevent a phisher from just MITMing the initial passkey setup with some nonsense claim about your session expiring? I'm probably mistaken here, but my interactions with passkeys always make them seem to be trust-on-first-use, which is a very phishable strategy.
A lot of people mentioned the DNS aspect to it, and that's still true. It prevents someone from just proxying the request.
But also, in the end the attacker site isn't really getting anything that would let them then turn around and authorize as you.
Think of it like SSH keys. A public key and a private key. The site holds the public key, you have the private key. When you create a new passkey with the new site, they're holding your public key. They can't go turn around and start logging into to other places with your public key, they can't sign the challenges. So if you make a passkey for bank.com and an attacker at baank.com had you enroll a key there, they can't take the public key at baank.com and use it anywhere to act as you. They only have a public key, and one tied to baank.com at that.
In the end you never actually transmit your actual credential even in the original setup. You're just signing things, the private key stays on your device. And its a different key for every service.
Authenticating yourself with a passkey cryptographically signs a challenge issued by the site you're trying to log in at, and your WebAuthN client (usually your browser) only signs challenges it knows about.
The important point here is that there is no way for you to have your browser sign an arbitrary (e.g. an attacker's) challenge, since you can't input the challenge at all.
This makes WebAuthN strictly better than static passwords, TOTPs (which are "unidirectional" in nature), and even "enter code 123456 into your authentication device and provide the code it displays"-like flows (which is a bidirectional challenge-response, but a MITMable one).
The passkey on the MITM site could not be used with the original site if they were on different domains. If the MITM site is on the same domain as the original site, then either you've compromised the original site or you've got in-roads with a trusted CA to fool the browser into accepting your cert, and passkeys don't protect against those.
Passkeys are tied to a DNS name, so unless they were able to take over the DNS of a site, they wouldn't ever even be offered to authenticate the password. Additionally the private key never leaves the device regardless, so if you were tricked to setup a new passkey on a fake site, you'd just end up creating a new Passkey for it and the site would get some new unique public key.
More than DNS name though--while DNS is susceptible to MITM and cache poisoning, afaik passkeys requires HTTPS so the domain's certificate is validated. Authentication not assertion and all that
See the comment from 'nailed downthread. I think some people on this thread are trying to axiomatically re-derive what Passkeys and FIDO2 are. Phishing resistance is literally the point of FIDO2.
There is no "authorize a new device" for passkeys. You'd need to actually run the "register new passkey" or "authenticate using passkey" flows on the attacker's device.
That's why they are so much more secure than passwords and even TOTP or "click approve to authenticate" flows!
There are now synchronizing authenticators that solve this problem pretty well (including open source and platform agnostic ones!), but as a result obviously also exist on a different point on the security-availability/convenience line.
Because in the former case the attacker now has your password and can post it for everyone else to abuse. In the latter, which is still a problem, there is no transitivity. You're screwed with this one attack, but if you revoke their access that's it. They cannot re-use the credentials.
Being able to revoke individual credentials is definitely a benefit. I'm not convinced about the transitivity, what's stopping one access from authorizing more? I suppose that would be asy to flag in an audit? Either way it's not really resisting the phishing, that's moreso resisting abuse once the credentials are gathered in any way.
To summarize this comment chain, the initial argument is 'passkeys are not impervious to all attacks therefore they are security theater' vs 'passkeys help significantly in the most common attacks, therefore they are worthwhile.'
Statistics are hard. People have a bad habit of seeing 'not 100% fullproof' and thinking that said something is therefore worthless. Same senseless argument people made in the 80s against wearing seatbelts, and 4 years ago thinking it was a legitimate argument against wearing masks in the middle of a pandemic.
I believe that the crux of it is that password managers with autocomplete already have about the same level of protection and are both more flexible and have less lock-in
passkeys imho are being pushed because:
1) a lot of people will not use a (good) password manager
2) it allows more lock-in for the providers (ios/android/1password/etc.)
To a first approximation no normal person uses a password manager (people find them extraordinarily hard to use; source: did trainings with a bunch of different cohorts), and the two solutions do not have "about the same level of protection". I watched a fintech company try to get people to stop relaying credentials through SMS with scammers, and that problem was practically insurmountable. I do not believe "autofill" is the fool-proof defense you think it is.
I have physical security tokens from multiple vendors which support passkeys. I have Windows machines with passkeys. I have Android devices with passkeys. Tell me again how it is a vendor lock-in? I'm not seeing it.
> All the big implementations are locked into some big player
Often repeated. Doesn't make it true. As mentioned, I've got passkeys for services registered on multiple brands of physical authenticators and several platforms.
About the only site I've come across that still only limits a single authenticator is the only one you've already mentioned. If I pointed out a site that only allowed five character upper case passwords with no lockout policy and really fast responses is that also proof passwords are completely untenable? Or just one actor with poor policy decisions
And in the end one can just choose to not use passkeys with sites like PayPal. But the extreme majority I've used allowed multiple, as that's what the specifications recommended.
In the end you can use passkeys without involving Google or Microsoft or Apple at all. Any argument that passkeys lock you into their platforms isn't based in reality and are repeating untruths. You don't need to use them to use passkeys.
Correct, AWS was one of a small handful of services I was thinking about which did have this restriction but now haven't had that restriction for multiple years.
Well for me it's 50% as the only two sites that I use and do passkeys are Microsoft and PayPal.
Adoption is really slow. But yeah ok, if multiple are allowed then yes it's no longer a problem. I'm sure I read of more sites that had this problem but it is indeed possible they're fixed now.
Generally people who assert that Passkeys are "lockin" also object to the notion of using a Google account as your primary online identity. Of course, you don't have to, but that's the concern: a world where they will have to.
(You should use a Google account as your primary online identity, unless you have religious reasons not to. Back up your authenticators, set up back up accounts, all that stuff; Google doesn't want you locked out any more than you do, because that requires them to attempt customer service, so they have a bunch of tools here.)
It's not an assertion. It's a fact. You need to be in control of the auth method or you can be controlled through it, plain and simple.
People that by into systems they don't control are shooting themselves in the foot because, when push comes to shove, a for-profit company will always chose profit over individually choice. It's short sighted to think otherwise.
Yeah that's great, I don't subscribe to that particular religion but respect your beliefs. I think most people are best served having their primary online identity be a Google account, for multiple reasons. I'm aware that a vocal contingent of technologists on HN find that take appalling, but I assure you, my take is a normie take, and also the modal take among security people.
Either way: Passkeys themselves don't require you to use Google, or any particular big tech firm. It's an open protocol.
This was more than two years ago. Despite the title, many parents are victims to this. To this very day, Google continues to defame them and deny access to their accounts. Long after the police cleared these victims' names. Long after the NYT confronted Google about this.
So is this what "normies" should be subject to? A digital totalitarian hellscape in which a trillion dollar advertising giant rummages through people's digital lives, randomly takes away their entire digital identity every time their flawed cyber-oracle tells them to, and uses their vast corporate resources to harass and defame?
That's not a world I want to live in. I don't want anyone to be subject to that kind of tyranny. It's not about any "religious belief," but rather basic human decency.
Are you responding to the right comment? My argument has nothing to do with how passkeys work. I was responding to this:
> Yeah that's great, I don't subscribe to that particular religion but respect your beliefs. I think most people are best served having their primary online identity be a Google account, for multiple reasons. I'm aware that a vocal contingent of technologists on HN find that take appalling, but I assure you, my take is a normie take, and also the modal take among security people.
Do you have an argument that would be persuasive for someone who does not find Richard Stallman rhetoric compelling? It's OK if you don't, but then there isn't much for us to talk about.
It's compelling to everyone who doesn't randomly want to lose access to all of their online accounts. Everyone who doesn't want the police turned on them when they haven't done anything wrong. Everyone who doesn't want to be wrongly labeled a criminal for the whole world to see. That's basically everyone. If you want these things to happen to you, just like they did to the parents in the NYT article, I guess you'll be the sole exception. But why?
Also, Richard Stallman? Where did that come from? This has nothing to do with free software at all. I'm also capable of drawing my own conclusions without someone else whispering in my ear, if that's what you're suggesting.
He's attempting to discredit you because your belief is strongly held. His comments about 'religious' beliefs are similar... trying to suggest you shouldn't be listened to because you're driven by irrationality.
Yeah I agree. I'm not interested in being locked into an ecosystem I don't control. I want my authentications to be reliablely tied to my choices and actions. Not some system that has a for-profit motive to tie me into a system that does not work to my benefit.
Phishing is resisted because the URL of the site is used in the key generation algorithm. So a site with a similar looking but different URL won't yield a workable token, even if the user is tricked into authenticating to the fake site.
You'd really have to be a state actor to be able to generate a phishing site on the original url with a valid certificate as well.
Let's say I end up on acccounts.totallygoogle.xyz. I press "login with passkey" and my password manager says "you have no passkeys for this site". I press "login with a password" and the password manager says "you have no saved passwords for this site". What exactly is the difference?
There is no passkey password. If there are, it is entered into the dialog box not a site. And wouldn't do any good cause the passkey is saved on the device and does a key exchange.
If you mean the password manager password, then it is entered in a different place and really hard to confuse it with a website. Also, 1Password requires extra info to login account and that is only used, usually copying from another device, when setting up device.
The parent of your post outlines a phishing attack vector. The only known way to close the vector is nuking the user account.
If you can explain how, in a phishing resistant way, passkeys can grant access to a user’s account in the absence of any devices they own, I’d like to hear it.
This is missing the forest for the trees. Phishing attacks won't ask you to reset your passkey - or if they do, they'll have to be much more complicated and targeted. This will dramatically reduce the attack surface threatening the vast majority of users.
Shouldn't the app storing the private key be protected by a 4-digit PIN, or a fingerprint, both of which are less secure than a plain old password? What have we achieved?
If it requires physical access to the device to enter the four-digit PIN or scan a fingerprint, that would be a substantial step up from passwords which could be used from anywhere in the world.
Reducing your attack surface to the people who can/are willing to gain physical access to your device to use a passkey is orders of magnitude smaller than a password that can be taken and used from anywhere in the world, without having to get up from their computer.
If someone really wanted to gain access to something of yours, they could take you and your family hostage and force you, but that is an incredibly small attack surface. "What we have accomplished" is shrinking the attack surface, not perfect security.
The use of biometrics as a password sounds like a bad idea.
Angela Merkel and Ursula von der Leyen are examples of this, fingerprints and iris scans lifted from mere photos.
In some countries even it is mandatory to store the fingerprints and photo from citizens, or at airports, what makes biometrics almost public.
Besides having all the logins under a single pin on a device that can be lost or stolen sounds just as bad, soon the people will be aimed to store them online to avoid it (trick-or-treat).
It's a 6 digit pin but it's safer because it's backed by a hardware token or secure element which limits the attempts to 5 or 10 tries before locking itself.
I think you’re letting your emotions distract from the larger picture where millions of people are compromised on a regular basis because they use systems designed the way you want.
Knowledge-based access is inherently problematic: if you don’t police passwords, most people will be compromised because they use weak and/or shared passwords. If you use strong passwords, you’re also screwed if you lose your phone so you’re in the same reset game with trivia questions which are increasingly weak because they can be answered from information on Facebook/LinkedIn or from breaches from other companies which used the same question. New logins from previously unused devices in a new part of the world shouldn’t work anyway because that’s indistinguishable from a successful attack.
Passkeys avoid all of that, but you need backups either in the form of a Yubikey or a recovery code in your wallet. Yes, that’s annoying but there is no world where nobody is annoyed, so it should be a question of whether more people are inconvenienced by their accounts being breached versus traveling and losing all of their devices but still being able to remember their strong passwords.
> Passkeys avoid all of that, but you need backups either in the form of a Yubikey or a recovery code in your wallet. Yes, that’s annoying but there is no world where nobody is annoyed...
We're not talking about annoyance here, we're talking about data breaches on the one hand and permanent account lockouts on the other. There is no world where the majority of people remember distinct passwords for each service, and there's likewise no world where the majority of users carry a Yubikey or even download their recovery codes at all, much less carry them with them.
So we're left really with two choices at the extremes: do we go for the failure mode where people reuse passwords and lose money and data that way, or the failure mode where a company is physically incapable of restoring a customer's account? Given the choice between these extremes, companies will always choose the former.
Now, these extremes aren't the only choices, but then you get to the crux of OP's argument: passkeys stored in a password manager aren't any more secure in practical terms than random passwords stored in a password manager. Your auth system is only as secure as its recovery mechanism (which is the observation that led Slack to initially not bother with passwords at all).
There's one way in which I disagree with op, which is that passkeys prevent users from typing in a password and storing it in the password manager, which many users do—they effectively enforce random passwords rather than it being just a best practice that needs to be taught.
> passkeys stored in a password manager aren't any more secure in practical terms than random passwords stored in a password manager.
This isn’t true, and that’s where your confusion comes in. Passkeys cannot be phished because the protocol includes the server name and does not expose the key to the remote server. The past decade of U2F/FIDO/WebAuth deployment has used that as the marquee selling point because it’s a very common exploit which cannot easily be prevented with traditional passwords and MFA.
> This ignores that most password managers check domains/origins the same way browsers do.
No, it doesn’t. Most password managers allow you to fill passwords for other domains and all of them allow copy-paste. The people who support those users know that phishers can convince people to do that which is why they’re encouraging adoption of WebAuthn.
That assumes the recovery mechanism is definitely going to be a greater risk than phishing. In a corporate setting recovery could require intervention from IT support if alternative methods don't exist. That adds obscurity and natural rate limiting. Where as phishing could be as simple as a fake login page.
Another factor here is the number of logins that a user is required to perform. Anecdotally this seems much higher in a corporate setting than personal. I might login to Microsoft SSO 15+ times per day for different services. Signing in to apps on my phone is rare.
Random passwords in a password manager are also phishing-resistant. My password manager remembers the URL that I used the password in and will refuse to fill it in on other pages unless I deliberately work around that protection. They may be less phishing-resistant than passkeys (in which case add it to the list of small disagreements I have with the original poster), but it's not a wide open field for phishing attacks.
And this is an important distinction to make—if passkeys have a terrible UX (which right now they absolutely do) and are only marginally better at phishing protection than a password manager, they could actually be a less secure solution overall by encouraging lazy workarounds.
Passkeys are cryptographically phishing-resistant, and password managers just disable a convenience feature when a heuristic check fails. It's not the same thing. I don't care if you feel like the latter protection is sufficient for you or should be for others; they simply aren't the same, and that was what the comment upthread suggested.
Whether or not they're the same as a bit of a red herring, the question is whether the marginal added benefit of cryptographic phishing resistance is worth the trade-off in UX which introduces new kinds of vulnerabilities due to undesirable user behavior and/or implementation workarounds. And to answer that question you can't just dismiss the security offered by password managers—it's a very real protection that needs to be factored in to your assessment of the strengths and weaknesses of each system.
Which user/comment are you referring to? The top-level comment? I'm the person you replied to initially, and that's not what I said, so I'm assuming you're referring to something else.
I have no idea who you are, am comfortable with who does and does not believe me here, and think you should do you. But no: the two approaches do not offer comparable practical security.
From the questions and comments across the rest of this thread, the misunderstanding here seems clear: the person I'm responding to did not realize that FIDO2 cryptographically binds credentials to sites.
Not at all. One phishing vector is: (On a phone call) "Hi, this is $your_bank, please go to your password manager, open the entry for $your_bank and read your password out loud to me on the phone, thank you!"
You can't read out a passkey, nor can you read out a challenge to somebody that they are to sign with their passkey, because it's not possible by design.
One big selling point of passkeys is that almost every workaround is impossible, whether that is good security or bad UX or both seems to be under discussion
If that's one of the big selling points then that's a problem, because workarounds are totally possible and actively implemented in the real world. As an obvious example: syncing passkeys is a workaround for their terrible UX that takes them further from the original design in ways that compromise some of the original security guarantees.
If my password manager running on my desktop can provision and access the passkey for use on another device like my phone, then so can malicious code running on my desktop, and exfiltrate it to hackers. The original design, where the private key only exists on a TPM and the private key never leaves the TPM doesn't have that flaw.
Passkeys were always designed as being synchronizable and not necessarily be secure hardware backed.
I think there’s a place for both of them in WebAuthN based on the security/availability/convenience tradeoff which will be different for every application.
If you care about your users only using the trusted hardware, non-synchronizing kind, you have to use attestation anyway (or malware running on their device could create credentials that only appear to be backed by secure hardware).
Unfortunately both Apple and Google seem to have unshipped their attestation support without replacement (they used to support hardware backed credentials in their devices too for a while) in the interest of not confusing users about what is and isn’t synchronized – now everything is.
How so? Not the type of attestation we're talking about here (i.e. not the early 2000s trope of "zomg Microsoft is locking down our PCs", which ironically is what Apple is now doing instead, all without any evil TPMs).
Apple and Google very intentionally threw FIDO attestation out of the windows without replacement, and Microsoft frankly doesn't matter enough for non-corporate contexts at this point. (Imagine your bank only allowing passkeys on Windows, but not iOS, Android, or macOS.)
All Apple and Google hardware have TPMs/secure enclaves.
Android calls it the Play Integrity API now. Hardware-backed enforcement isn't reported from the attestation servers to 3rd-parties yet because there are still a few old devices with broken implementations, but that switch can be flipped at any time.
I'm sure Microsoft would have done that in the 2000s if they could have gotten away with it. All the big players did exactly that when they got the chance with mobiles that didn't have any precedent. And no I don't think it's ok even there. But I'm aware I'm a minority.
And yeah I moved away from Mac for this reason among others. My devices should answer to me and me alone.
But I think the upheaval in the 2000s helped to make the TPM not the horror scenario it could have been. I don't think the ruckus was overblown at all. Don't forget Microsoft still wanted to kill Linux back then.
And yes Apple has tpm. It's just built into the cpu and called differently.
> And yes Apple has tpm. It's just built into the cpu and called differently.
Yeah, so does Google. But as mentioned before, even though they were both using it for WebAuthN in the past, they both stopped doing so.
What stronger proof for attestation being dead in the context of WebAuthN can you possibly get than the two largest implementers actively discontinuing it?
There are many good reasons to be cautious of how attestation is used and critically examine who it serves – a company you're doing business with, you, or both – but in this specific context, it's arguably no longer relevant.
I just love that @wkat4242 (the parent comment you're replying to) lists attestation as the reason they moved away from Apple/macOS and you're (rightly) pointing out that both Apple and Google stopped supporting hardware attestation for WebAuthn/passkeys.
This really embodies what's wrong with the world in 2024 — people believing in their world views so strongly that they ignore actual real world evidence that is directly contrary to their very strongly held but incorrect world view.
It's not attestation per se that got me to move away from Apple. More the lock-in in general when it comes to Apple. And the opinionated design (use it as-is, few configuration options).
Every release macOS got more closed and removing features I cared about. At the same time introducing stuff that only works if you're all-in on Apple. Half the new features of every release didn't apply to me because I use so many different systems. I use every OS under the sun. So that didn't work for me. Because all Apple's cloud stuff works on Apple alone (with a handful of exceptions on windows).
The lock-in of passkeys was just one of the things that bothered me. Not really the attestation per se, I'm aware it doesn't currently have it though I wouldn't be surprised if they introduce it if passkeys actually take off.
But like I said, Apple does have hardware control over other features. They do have a secure element which is just like a TPM which blocks you from changing certain files on the system and if you disable system integrity protection they turn off some of the features of the OS, like the ability to use iOS apps on macOS. It's basically DRM. That was the other thing that bothered me. For example, I used to simply boot into recovery and make a 'dd' image of my laptop. I can't do that anymore on an Apple Silicon mac. I used to change my sshd_config to block password auth but since SIP the file got reverted back with every system updated and dumped on the desktop in a passive-agressive move. I just don't want Apple to have more control over my system than me.
This was really what got me to hate macOS, it's just not fit for purpose for me anymore. I have never liked opinionated design but in the beginning of macOS X my opinion was much more aligned with that of its developers.
Yeah, as a user, I'm mostly happy about the lack of attestation. In an ideal world, only relying parties that really need it would request it, but views on who really does might obviously differ a lot between users and service providers.
> PayPal does this already by only allowing safari or chrome. With bitwarden on Firefox I'm locked out.
It works for me! However I do vaguely remember having to set them up on Chrome initially, but after that, they now work well even in Firefox. (Only on my computer; on my phone, I get an absurd non sequitur of "security keys only work on desktops").
> It works for me! However I do vaguely remember having to set them up on Chrome initially, but after that, they now work well even in Firefox. (Only on my computer; on my phone, I get an absurd non sequitur of "security keys only work on desktops").
Oh ok, I haven't tried that. I don't even have Chrome installed anymore.
And yeah I get that message too on my phone, even with standard FIDO2 MFA (not full passwordless Webauthn). Stupid because it does work just fine with other sites.
> [D]o we go for the failure mode where people reuse passwords and lose money and data that way, or the failure mode where a company is physically incapable of restoring a customer's account?
Are you sure that Microsoft’s solution means that they are “physically incapable of restoring a customer’s account?” Apple’s system keeps copies of recovery keys in their cloud [1], unless you explicitly tell them not to do this. It seems like a reasonable compromise for most people’s security needs.
I get to that, but as I said above you've now compromised the security of the passkey system, which means your passkeys are actually only as secure as your recovery mechanism, and for convenience sake that recovery mechanism is usually quite insecure.
Knowledge-based access (something only stored in your head) has Constitutional protection in the United States. The same is probably not true for physical things such as phones and YubiKeys stored in your pocket.
Not that I worry about that, but it is worth pointing out that you may lose some legal protections when you use physical things rather than your knowledge.
Do you have a source for this? As far as I know, it's at best a legal gray area. I believe in most cases you'll still be held in contempt of court for not producing secrets needed to access information which the authorities have a warrant for.
Additionally, it's a bit silly in the context of email since the authorities will obtain it from the service provider anyway.
That said, you can still add an encryption key to your phone and you're back to "knowledge based" with the additional caveat a thief would also need the hardware as well.
That's heavily dependent on which country you're in. In France[1] it can go up to 5 years in jail for refusing to provide a password. In the US[2], it seems that passcode are protected since you may be self-incriminating but FaceID, passkeys and fingerprints are not. UK seems to allow police to require you to give your password under their anti-terror laws.
The real answer is you shouldn't tell law enforcement anything without an attorney present, and the best advice would be to heed your attorney's advice on the matter for whether you personally should give up your passwords or not.
According to the manufacturers, those forensic devices also don’t work on my iPhone unless it’s unlocked with a password, but this is also irrelevant because they can get the stored passwords from the same phone in any scenario where they can access the passkey.
More to the point, this is also not what the average computer user is worried about. It assumes that they’re targeted by police, have something they need to keep secret, and that those police can compel physical access but scrupulously obey civil rights protections.
On the other hand, passkeys are almost exclusively used to authenticate to some service that can just as well be subpoenaed directly.
Exceptions do exist; two I can think of are passkey-based cryptocurrency wallets and the so-called "PRF extension" that allows using a passkey as a source of entropy for e.g. locally encrypting a password manager's database.
Locking people out of their accounts is pretty much a worst case scenario. It's so bad that services with passkeys generally don't want to risk it, hence the knowledge-based recovery options. Which makes passkeys mere convenience rather than extra security.
So passwords are bad because users can't be trusted to chose strong passwords but for passkeys they suddenly are trusted to keep secure, comprehensive, backups?
Passwords are bad because normal people can’t remember strong passwords AND because they can be phished or leaked. Phishing is the most commonly-mentioned benefit for passkeys because it’s widespread and cannot be eliminated from a password-based system.
“Secure, comprehensive backups” sounds scary until you remember that it’s only ever meant not disabling a checkbox for iCloud, Google, or Microsoft users.
The glee with which people say "and it's on your phone!" is what gets me.
Right: it's on the small device I take everywhere and use for everything. The one most likely to get lost, stolen or completely destroyed, and absolutely has to be replaced in about 5 years.
That device. You want to permanently lock data to that thing?
(My phone is basically disposable in terms of my expectations for it's future survival, and man do I not like the Android recovery options still)
> That device. You want to permanently lock data to that thing?
This is why no passkey implementations do this: the mainstream implementations all require synchronization and if you read e.g. Apple’s iCloud documentation note that the offline recovery mode is designed for the case where all of your devices are lost:
Passkey synchronization provides convenience and redundancy in case of loss of a single device. However, it's also important that passkeys be recoverable even in the event that all associated devices are lost. [...]
To recover a keychain, a user must authenticate with their iCloud account and password and respond to an SMS sent to their registered phone number. After they authenticate and respond, the user must enter their device passcode.[...]"
And we get back to knowledge based auth in the end.
Yes, but that’s like saying there’s no difference between a bicycle and a dump truck because they both have wheels and can go off road. Passkeys make an immediate, significant improvement for security and ease of use, and the disaster scenario is no worse, often better.
Recovery flows being based on knowledge based auth that requires multiple pieces of knowledge does not in any way reduce the extremely meaningful security improvements that passkeys bring for both users and Relying Parties on a daily basis.
> Right: it's on the small device I take everywhere and use for everything.
So don't put it on only your phone, put it on your phone, your laptop, your desktop, and maybe a physical hardware token. Lose all but one and you're still fine.
I lost my phone. I don't bother with the cloud sync'd passkeys. I didn't lose any of my identities, because I had access through other devices.
I don't know how other providers deal with recovery, but if you use iCloud Keychain for storing/syncing your passkeys, Apple has a very impressive amount of recovery options, including an option for recovery even if you lose 100% of your devices.
See the section titled "Recovery security" in this support article:
If the giant meteor comes crashing down to destroy everything around me, I don't think I'll be that concerned about getting locked out of a video streaming site.
Even if I have a house fire. Small chance it'll actually destroy all my devices and paper recovery codes. And the odds of having that house fire is also pretty low.
If a tornado destroys my house, chances are my hardware tokens will survive. More of a question of where they ended up. A tornado destroyed my brother's house, his iPad ended up just fine.
I don't really live in an area where landslides are possible. If I did I'd probably want to plan around that with the passkeys. But that's true for a number of things at that point though.
What if every device hosting a password safe breaks?
Most people do not have a surplus of devices. They might only have a single phone which carries their life. A phone which at any moment could be lost, stolen, or destroyed.
A password safe, I can trivially backup however I wish. The cloud, a USB I keep at mom’s house, print it out, whatever (in fact, I do maintain encrypted offsite backups in a couple of locations).
> A password safe, I can trivially backup however I wish
Boy do I have good news for you then. Passkeys can often be stored in many available password safes. Bitwarden, KeepassXC, LastPass, 1Password, Dashlane, and more all support passkeys. Make one on whatever device, one in your password safe, and you'll have redundancy.
And I'm not talking about people needing to carry two $1,000 phones or a $1,000 phone and a $1,000 laptop. You could have your second key be a small, cheap (<$40), durable authenticator. Another thing on a keychain, another card in a wallet. Really that big of a deal?
And if that's truly impossible for you, then sure I'll agree passkeys might not be for you. I agree, some people like those who are homeless have a hard time keeping any material goods safe. I'm not arguing every account for every person needs to be only passkeys. But people here are acting like it's something impossible for nearly anyone to use safely. And I don't think that's based in reality. I think a lot of people could use them safely if they wanted to, but there's a massive amount of FUD about them.
Why should everything be dumbed down and idiotproofed these days? Why not educate people instead? Blame people not passwords.
Passwords managers are good and free and every new phone has one built in. There is no excuse for using weak passwords anymore.
Over years of trials security teams at places like Google have managed to successfully phish even people on those security teams. The verdict is in on whether this UX provides acceptable security.
>Why should everything be dumbed down and idiotproofed these days? Why not educate people instead? Blame people not passwords.
Because taking a holistic look at an entire system and attempting to improve it is better than relying on each and every individual. Take aviation for example. If there is a plane crash and it is found that the pilots ignored a warning indicator, they look and see if the warning was prominent enough, if it is properly prioritized, and if it is something that can be corrected at the system level. Pilot training is only one of many factors they look at, and human error is taken as an inevitability.
In aviation, pilots are highly trained and highly regulated. With accessing services online, it is basically universal access by all people of all skill and intelligence levels. Making a system more inherently secure is the only reasonable solution.
Because even I, somebody that cares about all of this a ton, sometimes copy paste passwords out of my password manager because nothing else works. Because temporary read-only backend compromises shouldn't lead to catastrophic and persistent security breaches (because passwords are provided in plaintext inside TLS, and TLS is often terminated at the edge). Because educating people for a complex and moving target like the details of authentication seems like a losing proposition at best, and like victim blaming at worst.
So no, please don't blame people, blame bad authentication mechanisms (including passwords) and those that hang on to them despite better alternatives.
> There is no excuse for using weak passwords anymore.
Weak passwords are only a small part of the problem. You can get phished with even a 256-bit equivalent random string.
I agree that enabling stupid people to keep being stupid is just kicking the can down the road. However I think we should blame identity providers, not passwords and not users. Passwords work when the identity provider doesn't have ALL of them, and users shouldn't be expected to be trustworthy.
We just consolidated everybody's login into one platform. One monolithic database that contains the PII of EVERYONE.... What could present a bigger, better target than that? It's literally too good to pass up. Previously an attacker would have to compromise half a dozen vendors in order to completely pwn someone. Now they just need access to one.
Additionally, password managers are dangerous. Not a single one or them has been able to go more than 12 months without reporting a significant hack. Just another consolidated attack vector.
Like VPN providers. Why would I scourge the internet to gather browsing history of a target when the user has already consolidated that information into once place for me?
I helped a family member set up an account on a state website which involved also creating an account on id.me. The amount of text message codes and email codes and usernames and passwords was ridiculous and incredibly difficult for them to follow. Passkeys would make it impossible
Have you actually tried passkeys there? I find the implementation pretty straightforward to use: I enter a username, password (unfortunately no passwordless passkey support yet), and then click "ok" when prompted to use my passkey by my browser.
This is so incredibly wrong that it makes me think you've never actually experienced signing in with a passkey.
Passkeys would eliminate all the text message codes, email codes, and passwords. The flow is literally just: Face ID or Touch ID (or equivalent on Android/Windows), and you're done. It's both a faster/easier user experience than what you're describing and it's way more secure than any of the things you described, because the resulting credential is domain-bound and therefore can't be phished.
The much bigger problem is that you also need to enroll a second Yubikey into every service you use, but also safely store that backup key somewhere, ideally outside your own house. That's just not realistic.
Yubico had some ideas around "paired Yubikeys" which shared the same root secret, but I believe that model won't work anymore with FIDO/CTAP2 due to some counter value that was added there over U2F. (It might be possible for them to just not have a security counter; I'm not sure.)
I'm curious if that's really true. I've had a Yubikey in my keyring for years and it's pretty convenient. It's smaller than my car key and isn't very noticeable.
I have the NFC enabled variant so it can be used with a mobile phone
I also have a Yubikey for work, so I know how they work and how small they are.
I still stand by the idea that most users wouldn't be happy having to cary it around. We can't even get most users to use password managers which are built into their phones (1 in 3) and there was a collective meltdown when Apple removed the headphone jack which required people to cary a dongle for wired headphones. Telling people they need to cary around a yubikey for anything they want to log into just isn't going to fly.
I’m trying to get people at my workplace to use yubikeys. I would have thought it’d be easy, since “touch the blinking green circle on your yubikey” is a way less obnoxious form of 2FA than “pull out your phone, wait for a text, type in the number” or “pull out your phone, open up the 2FA app, scroll to the service, type in the number”. I was wrong though, it’s like pulling teeth and I’m not sure why!
I think you’re right, any change has to fight against the “this is how I do it already” inertia.
For me, the problem with YubiKeys is not the normal usage. That works great.
The problems are the "corner" cases: enrolling new keys, removing old keys, handling unintentional destruction of the key. The last one, in particular, is really problematic.
Some of the security mechanisms that a YubiKey provides are an extreme inconvenience. For example, I want to be able to clone my key via some mechanism in case it gets destroyed. I don't want to have to enroll 3 separate keys in every service on the planet just in case I put one in the wash accidentally. That's not possible with a YubiKey--for good reason--but it's a significant annoyance.
We consider "duplicating a physical key" such a common need that we have automated machines to do it at 7 Eleven. The fact that we don't have the same consideration of digital ones is problematic.
Yubikey was even planning working on a FIDO extension that would allow that for a while, but I don't think it went anywhere.
It's a real shame, as I'd also love "Yubikey twins" of which I can put one in a safe deposit box and have the other one always with me, without needing to periodically synchronize them to all services I'm using them on.
How is a Yubikey any different than other physical keys people have been carrying for hundreds of years? It seems much more intuitive to carry a digital key for your digital accounts.
Password managers have the added complexity of still needing a password themselves and all the quirks that come with auto filling and programmatically reading forms.
I'm not sure Apple head phones are quite a fair comparison. Outrage was also due to proprietary connectors that were patent encumbered.
I lost my yubikey once. There are always ways to recover your accounts, and it's especially easy for ones you're already signed into on multiple devices.
They're completely different! The similarity is at the physical/surface level only.
Physical keys work in one (or rarely in several, but basically unchanging set of) locks, and I carry around about 2-3 of them.
Hardware security keys, by contrast, work in many different places/accounts, potentially even for multiple accounts on the same service, but only after registering them there.
That's not how people experience physical keys: You don't, for example, move apartments or visit a friend, and the landlord/friend "registers/adds your key for their lock". If you lose your physical key, you can't "quickly revoke it from all doors" that it locks (without kicking everybody else out).
> How is a Yubikey any different than other physical keys people have been carrying for hundreds of years?
1. Not everyone caries keys (I don't and haven't for years)
2. Because every other existing alternative doesn't require you to cary something extra. Asking people to cary something with them to be able to sign into accounts will feel like a step backwards to most people.
3. Because most people only need to pull out their keys a few times a day. Requiring a Yubikey for every sign in means you'd now need to constantly be pulling your Yubikey out to sign into things.
> Password managers have the added complexity of still needing a password themselves and all the quirks that come with auto filling and programmatically reading forms.
I don't buy this. I use Lastpass which is arguably the most widely used password manager. I sign in using the master password maybe once a month and it works seamlessly on my phone. Apple and Google both have their own native solutions as well and still only 1/3 of people use them.
> Outrage was also due to proprietary connectors that were patent encumbered.
I think you're living in a bubble. Just go look back at the headlines from when that was announced. Almost no one gave a shit about it being a proprietary connector. People were upset because they were being forced to buy and cary a bunch of dongles. Just look at the comments on these reddit posts:
> 3. Because most people only need to pull out their keys a few times a day. Requiring a Yubikey for every sign in means you'd now need to constantly be pulling your Yubikey out to sign into things.
I just leave it connected to my computer. It requires a physical touch for every interaction so it can't be 'milked' for tokens like old fashioned smart cards.
I used to do that for a while, and it got annoying very quickly. It still requires grabbing my keychain when e.g. sitting on the couch or lying in bed, NFC doesn't always read (there's very little UX feedback on whether I'm holding it in the right place and there is possibly an application layer problem or I'm not even close), and most of all it doesn't work on my computer, where I need to plug it in to the USB-C port (much less seamless than tapping).
Now I only have the Yubikey as a backup authenticator for my most valuable accounts and use a software solution for most low-value things.
The technically savvy do. The others don't but not because they don't want to--they don't know they exist. Everyone I know carries around NFC devices--either work badges or credit cards. I don't see how having an extra NFC device in addition to the multiple ones you already have is a burden.
I'm an EM at a large tech company. Spent a decade as a developer. I have a Yubikey for work and I hate it. I understand why I need it and the value it provides, but I hate having to cary around one more thing.
The fact that this user thinks the average person would be happy to have to cary one around is wildly out of touch.
It's actually a LOT easier to explain to your grandma than a recent MFA app like Microsoft authenticator that requires a smartphone, the user to unlock it, choose the notification, to enter a code from a list and confirm with fingerprint.
With passkeys via yubikey it's insert key, enter pincode (just like at the atm), touch and go. You don't even have to enter your account name or email because that's derived automatically.
Anyone who can get cash out can use a yubikey. Very different for MFA apps.
My mother will not learn to use a Yubikey, or remember to carry one. You may not believe that (or simply dismiss anyone who won't/can't as unworthy to join in on modern life), but I can assure you it's true.
Have you actually tried this? I’ve found yhe Yubikey model is much easier for normal people because they’re used to using physical keys or cards. What’s hard is a) the cost and b) the hassle of having to pair multiple keys, which is where the biometric phone/laptop based solutions are better since it’s one tap for a familiar prompt.
Yes, as a matter of fact I am painfully aware of my mothers limitations with respect to technology and gadgets, as well as her extensive peer group who I somehow get roped into supporting. Your condescension is noted.
I have mine on my keyring. Not sure what the big problem is there.
The bigger issue with yubikeys is that you need more than one in case you lose one. And most sites only allow one passkey per account because all the mobile implementations can sync the private key. Yubikeys can't and that's actually a good thing because it makes them unique and eliminates the whole sync mechanism as an attack plane.
> And most sites only allow one passkey per account because all the mobile implementations can sync the private key.
Even when/if sites do allow multipe passkeys per account, the fundamental contradiction remains: Your backup key(s) are supposed to be kept somewhere secure where they won't get lost, stolen or destroyed, which ideally means some sort of off-site backup (at your bank or whereever), but at the same time every time you register for a new service you do need to register all your backup keys, too.
True. That is a problem. Especially because with Webauthn you can't just enrol a public key. It's one of the reasons I like openpgp for authentication e.g. over SSH. I can just give it a list of public keys to accept without having all those keys actually to hand.
> Knowledge-based access is inherently problematic: if you don’t police passwords, most people will be compromised because they use weak and/or shared passwords.
I don't like it that the solution is to usurp control from the user and gate authentication through what will, in my opinion, ultimately be a small number of big tech companies. We'll eventually be dependent on having an Android phone, an iPhone, a Microsoft account, or similar. It'll be a world of "trust me bro" credential managers and you'll have to hope you never get banned by the big tech companies because it'll have a life altering impact if that means losing access to all of your accounts.
The reality is that big tech has proven we can trust them because we're nothing more than 1 of a billion customers as far as they're concerned.
> Passkeys avoid all of that, but you need backups either in the form of a Yubikey or a recovery code in your wallet.
Passkeys create a huge burden in the context of managing devices and recovery codes.
To start with, I'm not a fan of recovery codes. I have so many accounts that it's almost impossible to keep track of all the recovery codes. I have to organize them well enough that anyone who would happen to get access to my file cabinet would own my life.
To mitigate that, I need a system for tracking which recovery codes I have in my file cabinet and I need a plan for rotating / revoking them if anyone gains access to them. Even worse, printed recovery codes are observable without altering the owner (aka me). Someone could photocopy all my recovery codes and I wouldn't know I've lost control of them.
As for devices, I use Yubikeys for my high-value accounts and managing them is a huge pain in the ass. I have 5 sitting beside me. One is old, two are v4, two are v5. I didn't keep a list of all the accounts I used them for from day 1, so now I have to keep all of them. Forever. Just in case.
The only way Passkeys will solve those problems is by taking complete control of authentication and treating it like a managed service. You'll be giving up control of your ability to prove your identity and, eventually, you're going to be paying a subscription fee for it.
In my opinion it's almost a guarantee that Passkeys are going to be used as leverage against users, not to benefit them. The sad thing is that once 99% of oblivious users are fooled, the rest of us are going to get the choice of using them or being shut out of everything.
Ive also seen some pretty terrible implementations that don’t even allow end users to manage enrolled devices; so if someone steals your authenticator they have access to your account indefinitely.
Personally I like the benefits passkeys offer but some work still needs to be done around management of enrolled devices
>so if someone steals your authenticator they have access to your account indefinitely.
If a user's device is compromised, an attacker can also install a keylogger and steal all their passwords, or better yet steal all their cookies/sessions.
Once a device is compromised, it doesn't really matter what type of credential you're using to authenticate/login with.
But also, if device compromise is what it takes to steal a user's credential, then that would be amazing becuse it would mean that the goal posts have been moved dramatically in terms of attacker effort. Today, attackers only have to focus on either hacking/attacking 1 service or spin up a single phishing page, and they can mount attacks targeting hundreds of thousands of users with minimal effort.
If passkeys mean that all of a sudden the attackers need to try to compromise hundreds of thousands of unique endpoints/devices, then the amount of resources and effort they need to expend to compromise the same number of users will be raised astronomically. That's a win.
Fair enough on the device compromise point, that said the implementation is still terrible and illustrates what I would be worried about-
Maybe more succinctly put, how a credential is initially enrolled, managed and finally removed is an implementation detail which leaves room for funky implementations like the above.
I do agree that it is an improvement over passwords though. Furthermore I guess the same applies to password based logins where everybody just kind of wings it anyway.
Or, maybe they won't. Are Google and other free-as-in-facebook services going to suddenly open customer service departments?
I got permanently locked out of Facebook because during a phone OS update, the 2FA app somehow lost my Facebook information. I can't log in to Facebook because the 2FA app can't authorize it. I can't add my Facebook account to the 2FA app without first logging in to Facebook. I've sent my photo ID to Facebook a number of times, but it just goes into a black hole and I never get a response.
On the plus side, I have a lot more time to do meaningful things, and not scrolling my life away like a drug addict.
It sounds like you're arguing against passkeys, two-factor authentication, and password managers.
Do you use single, easy-to-remember plain-text passwords for all of your accounts and services? If not, you need to understand what the recovery process is when your passkey/2FA/pw-manager is unavailable or lost.
GP doesn't seem to mention password managers. The nice thing about password managers vs passkeys is they need not be locked to a particular device or platform. I can sync the same database of credentials between my phone, pc, and laptop without worrying if they are from the same vendor. I can export backups. I can access it through my personal website on any device (assuming I also remember my personal website login too) if desperate.
The problem with passkeys isn't the concept, it's the lack of flexibility in implementation.
This prompted me to read more about it as I was quite certain this was the reason I had stopped using them. It seems the initial wave of complaints fed into some change about a year after the initial launch. Android 14 (Oct 2023) via the new Credential Manager API and iOS 17 (September 2023) when 3rd parties could actually be a registered passkey provider.
I've been using them with my BitWarden/VaultWarden setup now for a while. I was also extremely crabby about the idea of tying my accounts to hardware to the point of being unwilling to use them, but this problem is resolved. The resulting user experience is now the best of any login methodology and I remain in full control of my passkeys, up to and including the ability to back them up. I think it sometimes takes a "Never Offer Me Passkeys" from the browser sometime, just like they default to trying to get me to save my passwords into their vaults (and I always have to look up the magic setting to tell them to stop doing that on a new install), but it hasn't been that hard to make work.
I think I've heard that the passkeys providers have an option to force it to be hardware, but I've yet to encounter that, and it would also make me quite cross without a very good reason. I, personally, do not want my accounts tied to any particular bit of hardware, I want it tied to the single (very!) strong password I use for everything.
Edit: Browsing through the rest of this HN conversation it seems the password managers have some PR to do. Many HNers are not aware that password managers, even perhaps the one they are already using, have the ability to store passkeys in them. If HNers don't know, certainly outside of the HN bubble it must be even less well known.
The passkey pitch needs to incorporate this. Last time I paid attention, which was a long time ago, passkeys were non-portable. This is a deal breaker for me, so I wrote the whole thing off. I guess they fixed it.
> I think I've heard that the passkeys providers have an option to force it to be hardware, but I've yet to encounter that, and it would also make me quite cross without a very good reason. I, personally, do not want my accounts tied to any particular bit of hardware, I want it tied to the single (very!) strong password I use for everything.
If the functionality is built in, don't be surprised when they alter the deal and force it on you. What are you going to do if no one lets you use or migrate back to a username / password at that point?
We've seen the same thing thousands of times from big tech. They give us a system that's tolerable, but designed to leverage us into a bad position in the future. Once there's a critical mass, they'll flip the switch and we'll all get screwed.
I'm not sure that the big players have a motivation to force us to hardware. If anything, a lot of these entities will be happy to not have you forced to hardware because it's a support headache when people lose hardware.
(Also, be sure to understand that being forced to hardware is not "you must use a phone"... it is specifically "this passkey is locked to this Yubikey and can not by any means be moved to any other device". I don't think we're going to be stuck on that. Plus I haven't dug into the protocol but I'm not sure anything stops BitWarden from just claiming to be hardware.)
That said, my eyes are peeled, and at the moment the momentum is in the other direction, in that they actually headed away from that.
It surprised me too since I thought the whole point of passkeys is that you're using a thing-you-own to authenticate, but really the whole point is that the security credential is never transmitted to the service doing the auth.
That’s not the (entire) point of passkeys/WebAuthN at all!
It’s a pretty powerful/complex spec allowing various use cases, from a modern way to store SSH keys on hardware credentials to a more usable and less phishable password replacement backed entirely by software.
I use them for a bunch of things on a bunch of different devices/OSes and one light frustration I've had is I've accidentally stored a few of them in different apps because I'll be on a different device and either not have access to an app that I usually put the key in (1pass) or I'll mistakingly hit a "save passkey" that Windows, or Chrome, or whatever pops up. I've had to go in a few times and change my devices.
I think this is because it's so new with these apps. 1password acts really strange with them sometimes and my chrome extension will lock up or not actually push the passkey through or whatever it does. Sometimes I just get annoyed and throw it wherever worked.
When they're flawless they're awesome. I don't mind the quirks right now.
Various password managers. They're just private keys. Optionally you can use a private key that is kept in a secure enclave on-device, these would not be synchronizable.
And how do you protect the password manager, with a passkey that needs to be stored in another password manager, or with a password with all the security risks that come with it?
I use easy to remember plain text passwords for services that are low risk. It's a spectrum. I'm not concerned about someone hacking into my Hacker News account for example but I am very concerned about someone breaching my bank.
> I should be able to sit down at any computer in the world with the knowledge in my head and get access to any online service to which I subscribe.
The problem with that is you have no way to be sure that the knowledge in your head won't somehow make its way into someone else's head. There's a reason that phishing is a thing.
You’re not wrong, but I think you’re presenting this as a dichotomy when there’s a lot of value to be had between the two extremes (passkeys all the way or passwords all the way).
The big benefit to a passkey for a service provider is that when you see a user using one, you can assert things about that session—that this is the users device, that the session isn’t likely to be spoofed, etc. These are useful things to know if you want to implement any kind of context-aware access!
Passkeys certainly aren’t a silver bullet, and I don’t think they’re really marketed or implemented well a lot of the time, but I’d caution against writing off the tech as a whole .
Microsoft has made it very, very clear that they are building toward a future with the expectation that you are always on-line, and if you aren't, they are going to make life painful in large and small ways.
> Imagine you're on vacation and have lost your phone.
A few years ago when SMS tokens and Authenticator apps where less common, I was able to do work without having my phone on the same room as my computer. Now I need to have it on my desk most of the time for logging in.
There are authenticator apps that will run on your computer, and apps that will let you read SMSs on your phone from you computer. You phone might need to be on for the latter, and maybe even connected to the same local network, but it does not have to be literally on your desk.
Isn't the difference that with passkeys you'd have 1 password for all passkeys where when using passwords directly you'd have a different one for each site. The benefit of passkeys here being that you shouldn't need that password most of the time so you don't expose it. You get the benefits of unique passwords per-site with only 1 actual password. The same benefits of a password manager but with better unique passwords.
The main downside to passkeys currently is that I cannot be my own service provider. Having that I don't see a big downside.
Passkeys are in 1Password. I'm authenticated into 1Password on my phone, ipad, browser extension on multiple computers. As long as I don't lose access to all devices at the same time I'm fine...
Passkeys are arguably slightly more convenient and not risky for those of us who are technically aware enough to use password managers, sure. But that's not what most people will do. Most people will see their phone ask them to add fingerprint/face unlock, so they do that, and now their passkey is stored only on their phone (or in iCloud if they're lucky).
> In the world that passkey advocates want this is impossible via the passkey flow.
That's incorrect. I use passkeys to login automagically with many services, but nothing precludes me from logging in with my (20 character) passwords.
> If you can't authenticate via a primary device that contains your private key, you're f-ed.
That's also incorrect, for multiple reasons — accounts support multiple passkeys, those passkeys are securely sync'd across multiple devices, recovery and backup mechanisms exist, etc.
> That's incorrect. I use passkeys to login automagically with many services, but nothing precludes me from logging in with my (20 character) passwords.
That is not the world which passkey advocates envision. In the case of those services you mention, passkeys are nothing but convenience; they provide no extra security. In the world passkey advocates envision, passkeys improve security, meaning the removal of password authentication options.
I've already been temporarily locked out by one such service, because a Firefox update made the passkeys I store in Bitwarden inaccessible (Firefox would pop up a macOS Touch ID modal rather than the Bitwarden passkey). That is the world which passkey advocates want, because it "improves security".
The phishing site will just ask you for a password, maaaaybe with some text explaining some BS reason why you can't use your passkeys but if it's a website which the user knows they have a password to, the kind of person who's prone to non-targeted phishing attacks likely won't even think to question why the passkey thing didn't trigger.
Honestly don’t care to spend time on looking up the various states of 2fa proxies. But I’ve learnt so far that attackers don’t build/use the most advanced tooling you can think of at all times. They often use the simplest thing that gets the job done. If it’s not targeted, it’s fine to not get the credentials of people with a passkey. Up until a significant portion of targets use passkeys, which I highly doubt to be the case as of now.
Additionally, “the kind of person who's prone to non-targeted phishing attacks” is actually everyone — including infosec professionals spending lots of time on phishing campaigns for red team engagements. You just need to be lucky enough to reach them at the right (emotional, stressful, …) moment. Getting grammar and spelling correct and even potentially even slightly customising each email is made much easier by AI. Knowledgeable users might, however, stop once their passkey doesn’t work and try to understand why.
Okay? What relevance is this, if the phishing site just asks for a password then some users will enter their passwords even if they also have a passkey for that service. They aren't "not getting the credentials of people with a passkey", they are "not getting the credentials of some of the people who remember that they have a passkey and get extra suspicious because the passkey thing doesn't pop up".
I’m saying most people who do phishing likely don’t care to implement passkey detection to display a relevant error message to the user, as it’s not worth the effort, as of now
I'm saying that the world which passkey advocates want is a world where if, for any reason, you can't log in with your passkey (due to a lost/broken device, a software bug, whatever), you'll be locked out of your account. I'm saying that to contrast with my parent comment, which claims that the world passkey advocates want is one in which passkeys offer some slight convenience advantages but no security advantages because they'll be an alternative to passwords. Obviously they don't want the software bugs, but we know bugs happen.
> I'm saying that the world which passkey advocates want is a world where if, for any reason, you can't log in with your passkey (due to a lost/broken device, a software bug, whatever), you'll be locked out of your account.
And a world where people only use passwords has the same problem if you can't log in with your password.
Moving from one single point of failure to another isn't great, but it's not a downgrade.
(And just like it's possible to back up a password, it's possible to back up a passkey. And I know passwords can be memorized, but in practice it's bad passwords that get memorized.)
I use Bitwarden for critical passkeys. Most people do not. Passkeys, as currently implemented, for the vast majority of people, do not allow for effective back-ups in ways the user controls. You can't back up the keys from your iCloud and then use them on your friend's Windows PC to access something when you lost your iPhone. You can do that with passwords.
> You can't back up the keys from your iCloud and then use them on your friend's Windows PC to access something when you lost your iPhone.
Just enroll a second device like a hardware token. Then plug your hardware token into your friend's computer and you can log in to sites on your friend's PC without having to copy over and unlock your entire password safe.
I am. I'm not convinced that this will allow me to back up passkeys in any way. I wouldn't be surprised if Apple were to allow you to transfer passkeys out in such a way that they don't work on the original device anymore, which would make this standard irrelevant for what we're talking about.
No group is unanimous and completely homogeneous. But judging by how often the security benefits gets brought up by those in favor of passkeys in these kinds of discussions (including this thread), my impression is that most of its advocates view it as a security benefit. Which means they need to replace passwords, not be an optional extra.
For important sites like your email you'll add multiple passkeys. On less important ones you can just reset which passkey you use to login, using your email, if you lose one of your passkeys.
> I'm saying that the world which passkey advocates want is a world where if, for any reason, you can't log in with your passkey (due to a lost/broken device, a software bug, whatever), you'll be locked out of your account.
Can you point me to a citation or two where passkeys advocates claim that passwords must go away and/or account recovery mechanisms must be abolished?
Elsewhere in this thread [0], passkey advocates go on for quite a bit about how vulnerable passwords are to phishing. Really, any account recovery mechanism not linked to hardware would seem to be vulnerable to phishing in the way they don't want it to be.
Passkeys provide better security regardless of whether passwords continue to be supported. Two reasons off the top of my head:
• Passkeys stop phishing. Using your passkey instead of a password (when both are available) ensures you're actually signing in to the site/service you expect.
• Passkeys have zero value when leaked. Users' private keys remains secret and safe even when public keys are stolen and distributed.
That said, passwords aren't going extinct anytime soon. It will likely become more popular to require 2FA for password users in the meantime, as it should.
Passkeys don't stop phishing. If the user has both a password and a passkey to a service, a phishing site needs to just ask for a password and not mention passkeys and people will just enter their password.
>It will likely become more popular to require 2FA for password users in the meantime, as it should.
A lot of folks/services/engineers mistakenly think that layering 2FA on top of passwords will help defend against phishing attacks.
But attackers have been phishing 2FA codes since at least 2012 and it's gone from an advanced attack to bog-standard. The only way to defend against phishing attacks in 2024 is to use phishing-resistant credentials like passkeys.
Laypersons probably don't see ATOs at scale. I worked at a fintech and it was a relentless uphill battle to protect our users. We saw massive distributed login attempts daily and constantly bought compromised passwords on the gray market to run against our users' accounts. We tried to encourage better password hygiene, 2FA, Fido, etc.
You have to protect users from their own misunderstanding. When it comes to their bank accounts, improper security can be life-changing.
The term "security theater" itself is often thrown around to criticize when it's completely undeserved. Lots of people use it to poke fun at the TSA, but the term totally dismisses the fact that hijackings have plummeted [1,2]. The TSA does its job.
>The term "security theater" itself is often thrown around to criticize when it's completely undeserved. Lots of people use it to poke fun at the TSA, but the term totally dismisses the fact that hijackings have plummeted [1,2]. The TSA does its job.
Your graphic shows 'worldwide' data rather than US data. How would the TSA be involved in reducing hijackings on flights outside of the US? The connection seems spurious at best.
We could just as easily argue that hijackings correlate with other violent crime and the reduction in violent crime worldwide has led to their decline. Or that increased prosperity worldwide mitigates hijackings. There's very little basis to believe that TSA has anything to do with it.
> The term "security theater" itself is often thrown around to criticize when it's completely undeserved. Lots of people use it to poke fun at the TSA, but the term totally dismisses the fact that hijackings have plummeted [1,2]. The TSA does its job.
Would you be interested in buying my rock that wards off tigers? Ever since the great Tiger apocalypse where the premier military power in the world went on decades long quest to kill all of the tigers and everyone learned of the dangers of tigers, my rock has been extremely effective at warding off tiger attacks. For just 12 billion dollars a year (adj for inflation annually) (https://www.tsa.gov/news/press/testimony/2024/04/16/fiscal-y...), you could have this extremely effective rock.
edit: I'm pretty sure I clicked reply on GP's comment. Weird.
> Maybe that challenge question is just a long password (recovery key).
Specifically, recovery keys are designed to be so long and complex that no human could possibly memorize them, ensuring that they’re written down / printed instead of memorized — thus making them a “something you have” credential rather than a “something you know” credential.
> but I can't access a passkey-protected service from a friend's phone either.
You can use passkeys across devices. I've logged into sites for people using passkeys on other devices several times. I just tap or plug in my device to theirs when it asks for the passkey and it logs in.
Nor can you access a modern site from their phone unless you have a Yubikey, access to SMS, or a recovery code.
If you need to do this, it works the same for a passkey: if it’s a very close friend, you can share the passkey with them. If not, you can use the same login you’re now with the same MFA. Passkeys don’t need 100% adoption to be effective: the big win is blocking phishing attacks and that works as long as you’re not using passwords by default.
Crazy idea, but maybe passkeys can allow users to log in more easily and with greater security 90% of the time while not significantly worsening the attack surface. It’s almost as if, security against a determined actor isn’t the sole way in which decisions around authentication are made!
The argument is that service providers will not accept the reduced availability and so will deviate from the pure passkey way into some patchwork of security theater.
Microsoft Authenticator push notifications are even worse. It's super easy to lose accounts if you lose your device because they are not included in backups and there's no warning that you should have two devices registered when setting it up.
Normal users aren't going to keep a backup device, let alone keep track of which accounts are associated with which devices they own. Normal users need something in a portable format that can be backed up. Anything that can be backed up can be stolen and anything that can be stolen shouldn't be used for single factor auth like Passkeys are promising.
I forgot to enroll a new phone before wiping my old one this year and was looking at a 30 day wait to update my login info. That’s not technically losing the account, but it’s pretty rough.
Thankfully I was logged in on a PC and was able to get past it.
>Imagine you're on vacation and have lost your phone
This is a solved problem.
a) you can make a phone call
b) you can print important travel documents ahead of time
c) you can bring a backup device on your travels. I leave a Yubikey with my house keys in the hotel or sleeping accommodations and carry my phone
> b) you can print important travel documents ahead of time c) you can bring a backup device on your travels.
While I remain on the fence about passkeys, I often see this argument from advocates when things go wrong along the lines of: "why didn't you securely store your backups and keep them with you at all times"
Firstly, it's annoying when a user is already in that situation, it does not help them solve the problem right now.
Secondly, it clearly faces a scalability issue, a significant proportion of passkey users right now tend to be well informed on the authentication model and threats, but when it scales to billions of users many of them will not be well informed and will not think about how to be prepared for when things go wrong, potentially locking them out of everything they would need to fix the situation.
While I appreciate the advantage this model gives, I struggle to imagine it will work well on the unsuspecting public.
> I struggle to imagine it will work well on the unsuspecting public.
Right, that's because there's a 0% chance we end up in a world where everyone who uses the internet reliably carries a Yubikey or similar backup on their person. It's wild to me how many people here are seriously proposing this as a solution. That might work fine for a typical HN poster, but expecting it to scale to the general public is some insane tech bubble myopia.
In reality companies will either provide enough workarounds to negate any security benefits or a whole bunch of people are going to lose access to accounts they own. If passkeys ever get widespread I'm guessing we'll see more of the former option, leading to a lot of unnecessary confusion and very little practical benefit.
> If the recovery mechanism allows for knowledge based recovery
Basically almost every single auth method is flawed by that because it gives way to social engineering attacks. Also once your email is taken over everything else is.
You can't actually log in with passkeys using iCloud Keychain or 1Password when borrowing a friend's phone. Bitwarden has the same flaw, you need the software to help you do the negotiation in a way that can't be copy-pasted.
Garbage standard, terrible implementations everywhere, my favorite is when logging in with a passkey they still demand SMS 2FA.
Imagine you're on vacation and have lost your phone. You want to go to a cafe and log into a chat app, an email service, whatever to contact your family. In the world that passkey advocates want this is impossible via the passkey flow. If you can't authenticate via a primary device that contains your private key, you're f-ed. Service providers know this so of course they will provide recovery mechanisms. (Not consistent recovery mechanisms of course, each will have their own convoluted and likely to be broken ones). If the recovery mechanism allows for knowledge based recovery (challenge questions) then you're basically telling people that they need N passwords rather than one password. Maybe that challenge question is just a long password (recovery key). Maybe it requires access to another system, which you likely don't have in this circumstance. So you're either back to having passwords, or you're f-ed. Security theater or a disaster.
A service only has value if I can access it. I should be able to sit down at any computer in the world with the knowledge in my head and get access to any online service to which I subscribe.