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.
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.
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.
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
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.
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.
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.
The software industry has zero concept of how much pain and suffering passkeys are going to cause the average person, almost entirely because the average American has an iPhone and a Windows laptop and there's literally nothing built-in to iOS or Windows that will sync passkeys between these two devices. The world's most popular password managers are Excel and Apple Notes, in that order; these apps do not support Passkeys.
Passkeys are not going to happen, and its the industry's fault. Its a bad standard that solves some problems the industry itself has, by creating more problems for consumers. If you force consumers to move to only-passkeys, you're going to lose customers, and it might not even be their choice, you're just making the decision to lock people out.
It's not quite as bad, your average user with an iPhone or Android phone will be fine. Just scan a QR code on the Windows machine and log in with the phone.
The problem is that the UX for this is extra super confusing, and people will end up with passkeys that aren't backed up anywhere and get locked out of their accounts.
I don't have many things against passkeys for corporate accounts, but I don't think we're going to fully destroy passwords in the personal space. To the hardline Passkey-for-everything advocates, I pose the following situation:
In your sleep, your house has burned down. You have zero devices, and your backup keys are stuck in a building you do not have access to for another several hours. You have made it out of your home with: Your wallet, containing $20 cash, a handful of slightly melty credit cards, an ID that is almost readable, and your keys. The credit cards are fucked and will need to be replaced. Your ID is mostly readable.
This is the situation that I pose for most people to try and get undone from. I then amp it up another notch:
you have no job and are unemployed currently. You cannot make use of any insurance system as you have been deemed "impossible to insure" due to your status. You currently live in a cardboard box behind a restaurant in downtown.
And before you go "why would a homeless person need email", it's required for lots of services, as is a phone number that can at least have voicemail at it (this is a service that Futel^1 provides in some places). You can't assume that physical artifacts will continue being in the possession of a dishomed person. One of the common reasons for losing all your personal effects in this situation is the state literally taking everything down to your clothes away^2.
You're traveling in a foreign country without your laptop when your wallet and phone are stolen. You can probably get to a public computer, but how do you get into your email?
This situation strikes me as much more likely than getting hacked. Hence I will never use passkeys unless forced, and if forced I will do everything in my power to switch to another service. Same for forced 2FA as far as I'm concerned.
All of this makes me realize that availability is my biggest risk. My passwords are all 30 character random alphanumerics and I have none of them memorized.
This is, ironically, why I ended up with 1password over bitwarden: Their recovery process is down to "You can recover with paper, or another member of your family with access can break you into jail to get your account back up."
I have tested this process with my partner. the only thing that I cannot replace is the TOTP token to add new devices (however this is bypassed when recovering from paper). I have legitimately considered etching the recovery data into a small glass (borosilicate) dish using selective laser etching.
Durability to cost ratio. I can get 90mm borosilicate petri dishes for $10 that I can be pretty certain won't melt into a glop, plus having a "contained" object allows me to have tamper seals that are much harder to violate (nail polish).
Thus, "password recovery material, TOTP QR code, and an SD card with essential documentation" can be passed to next of kin easily.
For mainstream people uninterested in such things, this isn't a solution, but since the question was posed to "me", one way back into digital life that is not passkey specific is https://dangerousthings.com/product/apex-flex/
Ah, so no worries then. I've still got a passkey for all the services I really care about.
If I'm not supposed to have cloud-synced credentials like so many here dislike with those implementations of passkeys, chances are the copies of my password safes and my SSH keys to the VPS are all cooked as well.
You do it once the first time you log in, then add another passkey for the service to the laptop. Now you don't need your phone to log in. Also, if you lose your phone, you can log back into the service on your new phone with your laptop.
The time investment could even be worth it, since "Signing in with a passkey is three times faster than using a traditional password and eight times faster than a password and traditional MFA", according to the article.
-> My back-camera lens is shattered. Using the front is dodgy at best. I don't feel like I need fork out for an to upgrade as I use a digital camera if I want to take pictures.
Register a passkey on a different device or get a hardware key or whatever. Or call Microsoft support and complain to them. This doesn’t feeling like an honest discussion anymore.
There are syncable and hardware-bound passkeys and you are free to use a password manager that syncs your passkeys. iPhones don’t even let you create a passkey with the built in password manager if you have synchronisation disabled. I don’t know for sure if Google does the same but I expect them to.
If you’re remembering all your passwords there’s a good chance they’re terrible, you frequently re-use them or both. That really helps attackers e.g. when they use leaked passwords to run credential stuffing attacks on your employer.
You just wrote two comments bashing a technology you admit you didn’t properly educate yourself about.
Except, you can't sync the iphone's passkey with non apple products. And it's still tied to your apple ID, which uses a password. This in theory, defeats part of the point. (It's definitely better than the alternative though)
For android, the passkey is clone-able iirc, but again, it's an expensive smart device.
So now I am expected to have at a minimum, two use-able smart phones, per family member.
Iphone? Frankly, fuck that shit. Too expensive.
Android, I can manage it. But doing that for all family members is not financially viable.
Also I do use a password manager and an encrypted text file. (Not smart, I know. The file is basically a backup)
But I really cannot expect people like my mother to understand how to set up a passkey. Much less, how to setup multiple for the off chance one is lost. Add onto the fact that Yubikey does not support twins, and many services do not support multiple passkeys.
In terms of computer literacy, using my mother as a baseline (Age:Mid50s) the current passkey system is non-viable.
The "how do you recover from zero devices" problem is a real one. It's not a problem at work because you have a root of identity and access to a human (your IT dept) who can reset you. For public services like Google, if you lose your recovery methods then go fuck yourself.
Something I know is the only authentication method that can't be physically destroyed. When your customers are the masses every failure mode that can happen will happen, usually at the most inconvenient time.
What sucks about passkeys in abstract is that you want at least two failure modes that are uncorrelated— you're unlikely to forget your password and have your house burn down at the same time. Passkeys consolidate everything into to physical possessions which can be and are destroyed all at once.
>and people will end up with passkeys that aren't backed up anywhere and get locked out of their accounts.
I don't know why this is such a common misconception about passkeys.
Account recovery flows are generally entirely unaffected by moving from passwords to passkeys. If a user forgets their password or passkey, they generally go through an email recovery flow and generate a new one.
Why do we even have passkeys at this point? Just store a cookie and use email verification for adding new devices.
...this is sort of a rhetorical question, but also maybe not? Slack does it, as do some other services I can't think of off the top of my head. I feel like a lot of normal people who don't use password managers basically always use email resets when logging in from a new computer.
The thing is, email was never designed for this purpose. Password managers are. I stay logged into my email client on my computer, but I have to retype my password to open my Bitwarden vault.
"Hello, IT, my toddler accidentally dropped my phone in the ocean. I can't log into anything now. No, I can't restore my iCloud keys onto my Windows laptop. Please help."
I suppose corporate gets to overnight you a yubikey in 2-3 days?
That's why I very specifically said: Passkeys solve problems that corporations have, by moving the problems on to consumers.
Our industry was done writing reliable, quality software years ago, so it shouldn't come as any surprise that we want to keep going in that direction. Passwords have such an obvious, fantastic, beautiful quality in how when all else fails you can verbally say out loud "my password is X C J 5 4..." Its the ultimate form of reliability: non-digital, spoken or written language.
Passkeys throw that away. I don't care about any of the other arguments. Our industry wants to build less reliable software, so we built passkeys. I don't know why we're obsessed with building things that are less reliable instead of more reliable, but we are. Its sad, its insane, and frankly I'm getting so damn tired of trying to push for reliability every day and instead seeing Microsoft just throw weight around, get hacked, throw weight around again, get hacked again, and somehow still reap respect for their position in matters of security.
> The software industry has zero concept of how much pain and suffering passkeys are going to cause the average person, almost entirely because the average American has an iPhone and a Windows laptop and there's literally nothing built-in to iOS or Windows that will sync passkeys between these two devices
Then you register multiple passkeys for the website, just like you would register several Yubikeys.
It’s a 1-click process, and no HW-token required. Most people will be fine.
Many services which support passkeys do not support multiple passkeys. The big ones have figured out that we need support for multiple, but sadly just like with Yubikeys not everyone got the message on that.
But, its like I said: You have zero concept of the struggle that is already happening and will continue to get worse. That's what I mean when I say that the software industry has zero concept: You think you have the solutions, but you actually haven't even grasped the full scope of the problem.
This. Almost no-one's even realised that maybe being able to enroll multiple TOTP tokens would be a good idea. I spent some time recently trying to figure out a good, properly secure, robust authentication method would be for various important accounts both personally and at work, and I've more or less concluded that there isn't one, the best compromise that mostly works is TOTP but manually copying the secret across two hardware keys, which is wayyyyy outside the average user's capabilities, and I'm not even sure I'll be able to make it work in practice.
passkeys are not serious until they actually address backups in a way that isn't just "we'll copy the secrets around in our cloud services just like passwords lol"
(And it's not like there's no solution here: firstly make it mandatory in the spec to allow enrolling multiple keys, then standardise a means to enroll a device from another device, automatically, across all devices that other device is enrolled in, and then also it would probably be a good idea if that also offered a way to revoke the other keys)
The only site that uses passkeys I regularly use that doesn't support multiple is PayPal. Pretty much every other site that at one time only supported one now supports multiple. Which common sites still only allow one, other than PayPal?
this assumes majority of population has the means and discipline to purchase, register and maintain multiple pass keys and/or devices.
There's a world outside the developed countries where a typical yubikey can cost 10-20% of a family's monthly income.
A family where phones are the only tech devices in the household and the phone is typically in a 100-150 USD price range and costs about half of monthly income.
By making passkeys mandatory we are asking them to get multiple of yubikeys/phones per person in the family ?!
They cannot afford to and will not maintain multiple passkeys or backups.
Orgs will have to build a way to help them recover their accounts easily without further costs or just ignore them as "edge cases".
> Then you register multiple passkeys for the website, just like you would register several Yubikeys.
So just like Yubikeys, when you lose one of those keys you'll need to go to the 100's of sites where you registered that key and change it. This is not a good plan.
Then you use the "lost my passkey" process, which should be the same as the "forgot my password" process. Most services should treat passkeys like unphishable passwords.
Passkeys do not (and are not intended to) solve the problem of lost credentials.
Yes, its called "hybrid transport", and its a flow where a laptop presents a QR code to a mobile phone, who then sets up a BLE connection for one time use of the passkey.
So a Yubikey is not an electronic device that you need to carry?
iCloud Passwords don't run on an iPhone that is an electronic device that you need to carry?
Those electronic devices that you mention don't each store the keys in a proprietary format and you can't access them without the vendor's cooperation - i.e. vendor lock in?
>Those electronic devices that you mention don't each store the keys in a proprietary format and you can't access them without the vendor's cooperation - i.e. vendor lock in?
Passkey portability is being worked on. Here is the draft of the open standard:
iCloud Passwords is not built-in to Windows, so users have to know to install it. Most don't. Most iPhone users don't know they're using iCloud Passwords. In fact, many aren't (because it is oftentimes toggled off in settings because their grandson told them to do it or some other b.s. like that).
And, also, it barely works, if the wind is blowing in the right direction; was clearly built by a long forgotten team to check a box.
They've also released a Chrome extension, but no Firefox extension (actually, they did release a Firefox extension, but it only works on MacOS). Again, you have to know to install this.
The Windows Hello bluetooth system for passkeys has never worked for anyone I've seen try to use it. The display & scanning of the QR code works better. But, that only works if the passkey was generated on iOS and is being used on Windows; if the passkey was generated on Windows and needs to be used on iOS, you're probably screwed (I've never seen Windows try to pop open its webcam, if the device even has a webcam, to scan a QR code on another device.)
Apple has had a password manager baked into iOS for 11 years now. It was initially called iCloud Keychain and buried in the system settings, now it's been broken out into the "Passwwords" app as of iOS 18. There are extensions for Chrome to use the app on Windows PCs as well.
What is a browser extension? Do I need to take a class on that? Where do I buy one?
Really, not being snarky here. If I asked my dad to install a browser extension he would drive his laptop to my house and ask me to install it for him. If I wasn't available - then it just wouldn't happen.
The title is inaccurate. Microsoft doesn't actually "confirm password deletion for 1B users". They confirm it for millions. They have a concept of a plan for getting >billion people on passkeys as an auth factor, and will be able to get some of them to go passkey-only.
I don't mind passkeys and Bitwarden will take care of them for me. I enrolled most important stuff with hardware tokens and it's the same services now offering passkeys so I haven't migrated but probably eventually will.
Microsoft only started supporting webauthn in the last couple years so it's surprising they're actually rolling out passkeys. Maybe they finally gave up on smart cards
One counterargument is that nobody forces you to use their services.
I think the root problem is that nobody produces personal hardware over which the average person could conveivably assume full control. I'm not even sure it's possible, given how advanced the computer technology is.
> One counterargument is that nobody forces you to use their services.
Not specifically Microsoft, but more and more government services are accessible only through apps that are only offered through Apple's App Store or Google's Play Store. (Either directly, or because a generically eID app is used.) So in this case, I am absolutely forced to agree to either Apple's or Google's ToS to interact with my government.
I'm assuming those applications are hardcoded to use either Apple or Google (respectively) as the passkey service provider? IE. that the problem is that they don't allow you to configure your own 3rd party passkey service?
no you are seeing the easy ramp access pushed on you.. government is unique (in the USA) that it is required by law to be accessible to citizens including disability etc.. you can do almost anything using some (terrible,slow,error filled) paper process IMHO .. and there is a systemic reason why this will remain true, even as they push "one phone,one person" dystopia
No one is holding a gun to your head, no. But ij a lot of ways, you are required to use these services to participate in society.
My job forces me to use Google and Microsoft because that's what the entire industry is built on. Should I uproot my entire family's lives so I can move across state to find a new job? Is that a reasonable compromise to make so I don't have to complain about windows?
Indeed. My biggest bugbear with this is google's "location accuracy" service, which implicitly sends them not only your location, but a detailed map of any networks around you. It takes active effort to keep it turned off (and doing so actually breaks quite a few UI flows in google maps!), and still I've accidentally turned it on a few times and only noticed because I actively check for it. There is no reasonable definition of 'consent' which can be derived from that setting.
I never took that phrase to be reserved for sexual situations - in fact my mom used to use it with me all the time over toys, ice cream, etc. "Come ON, PLEEEASE?!" "No means no..."
I think it's a phrase that is often applied in sexual situations, but not intended to be exclusive to them.
I just had a great, novel business idea. I'm going to start writing brief, ad-laden, content-free articles all about someone else's blog post. Glad I thought of that before anyone else did. Please don't steal my idea.
The problem with passkey is that it's obscure for the common folk.
I'm a developer, yet for some odd reason I'm having a hard time understanding passkeys. Are they synced between devices? Do I need to set up a passkey per device? What happens if I have a single passkey on my phone and it gets lost? Do I lose access to that service?
So many questions that need a clear and concise answer.
One issue I found recently was changing my GPU clearly changed the definition of my "device" in Windows and invalidated all my passkeys. But the passkeys are still there, the sites I access still try to request them, but Windows can't provide them, so it basically just errors out. Not found out how to clear this all out yet.
30+ years of software dev, but I rarely had to worry about security. I've grown up with passwords (from 1980s BBS logins on up), but just like you, I still don't fully "grok" passkeys, in the sense of how I understand passwords, their threat model, how they can be cracked, etc.
I think I understand it's a bit like a "my public SSH key + website's public SSH key merged together", so that each website can verify the passkey we created together using their private key. The basic mechanism is more or less straightforward.
What I do not understand well is the "how to store and manage 100s of passkeys", and how to migrate my family (including my parents in their 80s, who are far away and I am the main tech guy when the closer "basic tech literate" family members who live closer can't figure things out) to them. We use Linux and Windows boxes at home, and Android phones (for now).
I can easily log into any accounts from any of these, even from my work laptop if needed, some requiring SMS 2FA (let's leave that for another discussion). If I created a passkey on a linux desktop and stored it in a yubikey, can I re-use it on someone else's windows laptop? Would I need the bluetooth version of the Yubi to sync with my phone? Or would I have to create a unique passkey from each device to each website, using my existing password?
Basically: I don't have "one phone" and "one computer", both running the same OS. What are some usage models, including some that don't require yubikeys, because no way could I get my parents in their 80s to understand those.
This is sounding more and more complicated. I don't want a Yubikey. How does a password manager help my cloud account? What does enrolling multiple credentials even mean?
> How does a password manager help my cloud account?
It's an alternative place to store webauthn credentials, if you're worried about being locked out.
> What does enrolling multiple credentials even mean?
You register multiple passskeys for your account on a service. So if you lose access to one (because you yoinked your phone into orbit), you can use the other one.
Anything that depends on a cloud service where your account can be destroyed any time without any recourse because support is managed by bots is a no go.
Personally, I'm comfortable with cloud services, but only if I have some sort of backup strategy.
I store all my passwords in Bitwarden. One reason I use Bitwarden (as opposed to e.g. Keypass) is because it has cloud syncing. All of my passwords are synced between all of my devices.
Critically, however, if Bitwarden's server was to disappear tomorrow, it wouldn't destroy my life. My passwords would still be stored locally, so I could open Bitwarden and export them, then import them into another service.
Passkey by design have no solution this! That means I can't trust them! I need to be able to export all of my credentials to some type of local file, which can be transferred to a new machine or service without the cloud, as a failsafe. I don't care if this is less secure, because my Bitwarden setup is already very secure, and I am much more scared of being locked out of my own accounts than of someone else getting in.
> Most implementations sync passkeys to the respective clouds.
So, in the end, the old Microsoft mantra: "Your security is very important for us".
Besides Microsoft, NSA, CIA, the five eyes and friends, no one has access to your passkey, this means is secure.
It depends on who is running your keys for you. Most of the vendors (Apple, Google, Microsoft) are using device-specific (hardware) keys to unlock the passkeys, which generally means that transitively you've first logged in with Face ID, Touch ID, Android Gesture, Windows Hello, PIN or one of the other names or brand names for "device-specific pass code or biometric" that unlocks your device's hardware security enclave.
In your analogy terms it is akin to an SSH key stored on a hardware device like a Yubikey that you have to "push the button" to unlock. It is more secure than just an SSH key without a password, but depending on a lot of factors, including your personal threat model, may be more or less secure than an SSH key with a strong password. (You'd assume the Yubikey's unexportable hardware key is a lot stronger to break than any password, so it is potentially far more secure from brute force attacks, especially remote attacks with no physical access to try to export an unexportable key. It's reliant on physical device security so it is far more weak to "in the room"/"over the shoulder" attacks. At the end of the day most people's threat model is somewhere in the middle of the two extremes.)
Of course if you decide to use a password manager like 1Password or BitWarden those passkeys are going to be locked behind your "master vault password" in a similar way to your other passwords.
I think technical people understand the mechanics of using Passkeys, having them backed up to multiple devices etc, but there's no way my 70 year old father is going to be able to understand that. He barely knows the difference between the computer login and his gmail login. My parents are also not wealthy-enough to have Apple take care of all of this for them. He has a hand-me-down Linux laptop because all he needs is Google Chrome. Thankfully I've been able to teach my parents to write down their passwords in a password book.
I can't tell you how many times I've ask my father "what's your google password" and he says "I don't have a google password". I like the idea of eliminating passwords, but inevitably his phone is going to break or his computer is going to crash and he needs a way to recover.
The password book of every person around me become awful over time. They don’t distinguish between uppercase and lowercase, they write bad notes, most of the content is outdated, sometimes there duplicates and overall cause me more headache than anything.
I hate password books. I don’t have a better solution though.
For now, I teach them to use chrome password manager for now and log in their chrome account when they need help. It sucks too. But at least I don’t get angry with their notes.
If I install all my private-passkeys onto my phone, then I have a new problem of Lost, Stolen, Broken to deal with. I’m device agnostic, I want to get to my account from my phone, tablet, laptop, desktop, all I’m doing is spreading the exposure out by needing to install passkeys everywhere.
Microsoft will probably tell you that the Microsoft Authenticator supports syncing, so you should set it up on a backup device.
This has several problems though, one of them being that they assume you have at least two mobile devices (let's say a phone and a tablet) and another that they assume the OS you run on both your devices is the same. They do not support migrating you passwords between Android and iOS for example!
I love that the "big guys" get to support syncing passkeys between devices... but others don't (wasn't it KeePas who had issues where they were threatened by being blocked from supporting that - https://github.com/keepassxreboot/keepassxc/issues/10407#iss... )
Microsoft's interesting approach here with Authenticator is that they don't expect you to trust one cloud with all your credentials, they are hoping that you can trust two clouds with partial information. They've (allegedly) got some variant of Shamir's Sharing where some of the data is encrypted in OneDrive and some of it is encrypted in iCloud or Google Drive depending on which phone you use. That's (supposed to be) why there is that "phone-type lock-in" on the automatic backups/transfers because the cloud with the most phone-native/device-specific encryption is phone-vendor dependent today.
Do you trust VPNs? Because they are the same idea with a slight twist. VPNs encrypt data before it leaves your computer and decrypts it when it arrives at the destination.
1Password and the like encrypt data before it leaves your computer, stores it for however long you want, and then decrypts it when it the data is copied to your computer.
Another option is to use a password manager that supports passkeys, such as BitWarden. You can even host it locally, behind a VPN, if you don't trust the threat modelling of their hosted version.
Then, it's a case of installing BitWarden on any devices you want to use to login, protected with a strong password and 2FA.
With a password manager storing unique passwords, your password is still being sent over the network to that website each time you log in.
With a password manager storing passkeys, your private passkey is not transmitted as part of the website request. It can't be intercepted or accidentally/negligently stored in plaintext in a database or server logs.
You still have to trust the secure syncing of your passkeys, just like you do with passwords, but there are still fewer threat vectors than with passwords.
It’s more than you think: if I can convince you to type in your Google password at g00gl3.com I can turn around and use that password for the real server. Passkeys block that attack.
So they couldn't convince everyone to give up their privacy and use Facebook or Google to track our logins to other websites via "Login With", and this is a new way?
If by new you mean a completely different mechanism which does not share the privacy considerations of a single sign on service, yes. If you care about privacy, passkeys are a much better option.
1. Passkeys are unique, so no more password stuffing attacks.
2. Passkeys can't be to short, in contrast to passwords
Passkeys essentially remove almost all risks for websites and moves them to the user (lost passkey, attacks on their password managers). It is not perfect, but it removes a lot of problems that we have right now (like more than a billion leaked passwords in the wild)
So it adds no value over the long, randomly generated passwords from a password manager besides making a new standard and giving Microsoft a reason to push a new dark pattern on users to force higher uptake rates of this new, bespoke standard with limited support?
When you log into a site with a password, you're needing to transmit your actual password over the wire. Sure, you'll hopefully have encryption when sending that credential over, but in the end you'll be exchanging your actual password with some remote service. That remote service might be misconfigured, it might be misdesigned, it might be under attacker control. Now they have your whole credential.
A passkey doesn't transmit your actual, full, repeatable credential over the wire. It's a challenge-response protocol, so only that one authenticated session would be intercepted. Kill all questionable sessions and you're good, they're not reusing it.
> randomly generated passwords from a password manager
are impossible to enforce. If you present users with password field, a sizable percentage of them will just manually type in the same weak, compromised password that they've used on every other site they've ever created an account on in their life. Passkeys are much harder to misuse. That's where 99% of their value is.
Yes there are also other advantages, like the fact that passkeys use public key cryptography, but those are tiny compared to the human factors improvements.
Passkeys include a key that the website you're logging in to holds, if a site can't present that key then the passkey doesn't work, meaning phishing attacks no longer work because 0utlook.com doesn't have the key that outlook.com holds.
It's a standard supported by multiple parties, not just Microsoft, including multiple open source password managers.
And it does provide some benefits: phishing protection (no shared secret that can be intercepted or given to the wrong party) and the service does not need to store as much sensitive information (don't need password hashes that could be leaked and cracked, just a public key).
Device attestation to allow blocking "undesirable" devices from authenticating and lock in purposes.
*keypass was working on an export feature and there were already threats to use the attestation club to ban them from the landscape for not falling in line
I found this out in October when trying to figure out this complaint.
timcappalli from FIDO Alliance mentioned in that above thread that plain text exports shouldn't be allowed, and that password managers/providers should be blocked if they implement plain text export.
Since that thread, there's a new spec that allows users to securely migrate passkeys from one provider to another, but no way to export to plain text (for debug purposes, or if there's a bug in the export/import and you need to troubleshoot, etc).
For me, threatening to block providers for implementing a feature that I desire is a great way for me to lose all interest in passkeys completely. I don't trust FIDO Alliance to make the right call nor do I trust big tech companies to produce bug-free software.
This very much falls into the same box as “not your keys, not your crypto”: if you’re forced to trust someone else to manage the keys for you then they have them - necessarily, in order to permit “transfer” (under this scheme, not everything) to another party - in plaintext, while you’re not allowed to “for your own good”, then you’ve lost it all.
They can:
1. Impersonate you, gaining access to anything your keys unlock
1.a. Impersonate you, claiming to be you in a violation of “key use enables non-repudiation”
2. Deny you the ability to use your keys
2.a. Change any of your keys, locking you out of things
3. Deny you the ability to transfer your keys to anyone they “don’t like”
3. Provide your keys to anyone else, e.g. “with a court order”
3.a. Anyone “benefitting” under (3) can then do (1(a))
…and surely more Bad Things.
Every single time “passkeys” seems to like “okay, maybe”… some fucktards pull another one of these.
Then I go, “okay, ssh keys, PIV, or whatever else is Just Fine, and these people who are either state agents, idiots, or power hungry idiots working to advance total control over humans with lack of freedom and no way back can go die, or as an alternative be sentenced to serious computer-things-reeducation”. …and I kinda mean it. There are certain things you just don’t come back from, as a society, etc. and I just won’t support it. You only get one chance not to.
Passwords are also a standard supported by pretty much everyone, and password managers (including those built into browsers) already generate long, unique, phishing resistant (it only prompts on the matching domain) passwords.
The main difference I see with passkeys from a usability standpoint is that Firefox doesn't have built-in support for a software implementation, making them literally unusable for me.
Firefox does support passkeys but their native implementation is behind a feature flag. Beyond that Firefox add-ons (such as those for password managers) can enable support for their own purposes.
For example 1Password can be used for passkeys in Firefox.
I can't find that option's documentation. Do you have a link? The only documentation I've seen indicates that they only support hardware devices, and I don't own one.
~90% of people who are presented with a password input field are not and never will be "password manager users". 100% of people presented with a passkey prompt are, because the very nature of passkeys is that they're stored in what is effectively a password manager.
Ah, I think I misunderstood that comment. From a global perspective "the benefit" compared to using passwords in a password manager is indeed exactly what I said, but I guess that user was asking more about the personal benefit on an individual level.
From that perspective it just makes the UX slightly smoother and makes it impossible for the site to screw up and leak your plaintext creds. Other than that yeah there's not a big difference compared to using an autofilled, unique, randomly generated password. Which is good, because eventually sites are going to start phasing out that latter option for the exact reasons I outlined in my previous comment.
>> Passkeys are unique, so no more password stuffing attacks.
> Just like passwords. What is the difference ?
>> Passkeys can't be to short, in contrast to passwords
> So a "long password" is a "passkey" ?
Of course not.
Passkeys are effectively just key pairs defined by a FIDO standard. It’s much more productive to think of passkeys as mutual certificate authentication designed for use by the masses.
If you’ve ever used a Yubikey for primary authentication, you’ve already used a passkey.
I really don't know how you're able to come up with the idea, that passwords are unique. They are in no aspect whatsoever unique. You as a user can try to use passwords, that are unique to you. That doesn't (can't and shouldn't) mean, that those passwords are unique against the database of a website, or other services.
Yes, the problem exists in multiple "places" and all schemes are
different balances.
There are many different kinds of "security". Each suits different
needs, or addresses different threats. Not all are based upon
"identity" as a central concept. Not all are based on secrets. For
those that are, changing your secret from something you know to
something you own merely shifts a locus of trust and mode of use.
Passkeys (and ssh keys with passphrase) are a good solution in some
cases, where you use multiple end points which may be compromised. But
they are no better (and less flexible) than challenge response and one
time passwords and other elaborate password schemes that are a
superior access control secret in other situations [0].
The problem is that most people don't understand the quite subtle
interplay of factors. This is one area of cybersecurity education I'm
spending more time on because regulations are going to place more
emphasis on making good security choices (and not just accepting
vendor defaults).
Microsoft unilaterally deciding it thinks it knows what is "best " for
you accords with its clumsy patrician over-reach, and cover for a
pitiful security record in its products.
Perhaps one of the most important meta-security factors is that you be
able to select products that allow you to choose your security
parameters and how they interact as your situation and access habits
change. But that responsibility requires understanding.
I mean, same with passwords, right? If you enter your password on a compromised device or you forget it, you are screwed. Which is what password managers (or passkey managers, or perhaps we could use a new term like "credential managers") help you with. Syncing, preventing unauthorised access (for example requiring your biometrics, main password or similar), backing up...
You can write down your password anywhere and copy it to any other piece of paper at any time. You don’t need certain brands of paper blessed by a consortium, or have restrictions even when copying to a blessed brand of paper.
The only reason you care about copying your password is because it's usually (always?) the only credentials you have for a service.
This isn't true of webauthn/passkeys. The number of use cases where you need to "make a copy of " or "backup" your passkeys is zero. I get that some providers let you do this for some level of convenience, but you can opt out of this and just enrol multiple distinct credentials with each service.
Unless you want to re-log into and re-enroll every service you ever signed up for when you get a new device (which is when lots of people get rid of their old device, it’s even what device manufacturers recommend, see trade-in prompts when you buy a new phone), you do need to migrate credentials.
> The number of use cases where you need to "make a copy of " or "backup" your passkeys is zero.
That just tells me you haven’t thought about the problem at all.
I haven’t dug into this but I must be missing something with passkeys.
It’s the same issue I had with getting a Yubikey.
The odds that I lose a piece of hardware that I’m carrying on me seems orders of magnitude greater than the odds of having my password cracked.
How does one recover from a lost device (other then backing up to Apple’s private cloud in which case you’re beholden to them forever to be able to access your own accounts).
> The odds that I lose a piece of hardware that I’m carrying on me seems orders of magnitude greater than the odds of having my password cracked.
I 100% agree with you, but the counter argument I've heard is that "it's worse if someone else gets into your account than if you get locked out."
This does make sense to me in some scenarios. Like, if the author of some core Javascript package gets locked out of their Github, they can't push updates to the package; if a hacker gets into that person's Github account, they can push malicious updates to said package. Better to be locked out!
If this describes you, I think a Yubikey makes sense. Personally, I am not in this category!!!
The "have a backup token" workflow seems like tedious make-work. I have to remove it from its "safe place" and keep it proximate to my primary token while I enroll it in everything my primary token is enrolled in.
The workflow to enroll a new backup token (when the primary is lost and the backup becomes the primary) also seems like tedious and error-prone make-work.
It would great if I could load my backup token's public key into my primary token and export a copy of the primary token's secrets, encrypted with the backup token's public key. When I lose my primary token I would only need to restore my backup token and be back in business. That eliminates the make-work of enrolling on the backup token.
Of course, this scheme allows for "cloning" of a token so it'll never be allowed by the "security" nannies who know better than us.
> It would great if I could load my backup token's public key into my primary token and export a copy of the primary token's secrets, encrypted with the backup token's public key. When I lose my primary token I would only need to restore my backup token and be back in business. That eliminates the make-work of enrolling on the backup token.
Yes, exactly this. At one point I had a list of services that I utilize along with a list of the yubikeys I had enrolled on each. My plan was to enroll my backup key periodically (retrieving it from its safe place to do so). This ended up being a giant pita, and despite my best efforts, the list became out of date. In the end I just use Google Authenticator for everything since I can back it up.
My Yubikey is only used as a factor to enable access to my password manager from a new computer. I only need it when I reinstall my computer or buy a new one.
The things you use only once every so many years is typically the kind of things you can't find the day you need it. Unless it is stored in a safe in a bank.
I'd have to lose BOTH to lose access to my password manager: the one that's attached to my keychain in my pocket, AND the one that's at home in a drawer. That'd be quite the bad luck.
I have a second one but its pointless, I'm bad about registering it as a backup token in the few places that even have UIs for doing it, most places don't even let you register more than one.
So do I, but this is annoying because I need to have physical access to both of the keys when setting up 2FA on an account, or hope that I remember to add the backup yubikey when I get back home.
I have 3, yet having two pretty important systems where only one (a single 1!) yubikey allowed to be registered or only support phone app based MFA. (having the misfortune being made to work with about two dozens of web services, it is soooo twentyfirst century putting everything into the clouds regardless if it is a good idea or not)
I ended up disabling MFA in one case - with the most terrible flavour of implementing MFA - because f you!, they ask me to re-login on my stationary main home computer repeatedly for 'security reasons' (idiots) and I too many times end up the particular MFA gadget being somewhere else than at the reach of my hand, obstructing my efforts and workflow too often. Using computer systems are wasting efforts nowadays rather than helping, with the forcing through of cutting edge advanced 'solutions' without thinking about the broad picture (the curse of single-mindednes).
And then we did not even talk about my bank, completely different animal giving no shit about third party physical keys, yet another different way to get blocked if not done exactly as those particular fellas dreamed of in cheerful company meetings not caring collaborating on generic approaches.
MS is particularly bad and not to be trusted with their "insightful design" (it is told this way in the article, HAHAHA, funny guy) solutions f-ing up two things while pushing a marginal one through. With important ones the ratio is higher.
> Passkeys not only offer an improved user experience by letting you sign in faster with your ... PIN, but they also aren’t susceptible to the same kinds of attacks as passwords.
I don't know about you, but a PIN is pretty much a password in my book.
Once I figured out that I can use a password with Windows, I stopped using my PIN. (I didn't use Windows for about a decade.) It's much easier to remember.
Even worse, on Windows, I'll only use passkeys on sites where I can use a Yubikey. If the passkey requires a PIN, I don't bother. I just can't be bothered to remember it.
Otherwise, on Mac, my passkey supports my fingerprint sensor. Much easier.
The Windows PIN is just a local password that isn't tied to a cloud account or ever sent across the network. Mine is a full text password, it doesn't have to be numeric.
I haven't tried it but it should also work with "Windows Hello" supported face or fingerprint recognition.
The PIN is also for the card itself. The smartcard chip inside the card can validate it for offline transactions (although that's not as common in the US).
It can't have letters / symbols in it. If they're calling a password a PIN, that's the wrong word and will confuse the ^%$^#% out of people who expect PIN to mean numbers only.
>> I don't know about you, but a PIN is pretty much a password in my book.
> Then your book is filled with misunderstandings of what the PIN function in Windows is actually doing.
The "PIN function in Windows" doesn't define what a PIN is. If Microsoft really meant the "PIN function in Windows" specifically, they should have said so in their blog post. Otherwise, in this context, PIN means this: https://en.wikipedia.org/wiki/Personal_identification_number.
> but a PIN is pretty much ___a password___ in my book.
> Once I figured out that I can use ___a password with Windows___, I stopped using __my PIN__.
Context clues. Read the whole comment. Pretty much immediately after they start talking about PINs and how they're pretty much just passwords, they go to talk about using passwords instead of PINs in Windows. Each sentence isn't its own entirely separate universe devoid of any context of the previous words and sentences.
What PIN do you think they stopped using immediately after referencing their Windows password? Think they stopped using their bank card PIN because they figured out how to go back to full Windows passwords?
So no, they're not speaking generally about all PINs, they're specifically referencing it in the context of Windows accounts.
the way a PIN works in other contexts is the same concept as what microsoft means.
Your PIN for your bank card doesn't give anybody access to your bankaccount. that would be terrible. your pin acts as a secondary level of authentication to secure the bank card that is your primary authenticator. just like a PIN in windows hello acts to secure your primary auth method - the computer that's already signed in to your microsoft account.
What's the difference between the two? I can log into my laptop with a password or a PIN; I assume anyone that steals or hacks my laptop can _also_ log in with a password or a PIN. PINs are inherently shorter and more simpler than passwords; why would anyone use a PIN over a password?
If you change your motherboard, your windows PIN won't work anymore, and you'll have to login to the underlying microsoft online account.
A regular local account with a password would still work after a motherboard change.
This is assuming no bitlocker. If you have bitlocker, I don't know if bitlocker key recovery will also fix the pin (hopefully you printed the recovery key and can find it)
AMD CPUs have fTPM built in so the passkeys are actually stored in the CPU. This is more secure because separate TPM chips on the mobo have been attacked by listening to the traces from the TPM to the CPU.
Maybe the PIN doesn't change if you swap the motherboard and keep the CPU, maybe. But if you swap the motherboard and the CPU your PIN doesn't work anymore.
The PIN on a Windows machine is a secondary credential to unlock the primary local credential, with the primary being your actual password.
Also, as mentioned in the sibling comment, PINs are just device-local credentials. They don't necessarily have to be numeric-only and can also be very long.
You can have your computer re-challenge you for a full password on some interval. So have it force you to use your password on your first login of the day, then you can use your PIN to hop back in during the day and then have the PIN option time out after so many hours. Same with any of the Hello credential options.
After too many failures with a PIN, it will disallow the PIN authentication entirely. So, its length isn't really a problem, it'll start to disallow PIN attempts after only a few wrong guesses. Once again, also configurable. Meanwhile, it'll always still allow a password although it'll start trying to slow you down on password attempts.
PINs are supposed to be stored on the TPM or similar secure platform module, they're not stored on the local computer storage. So, there's not some easily accessible file to do brute-forcing outside of the computer.
While consumer Windows isn't really Windows Hello for Business, the same basic ideas of PIN security are the same. Here's the FAQs on that which also go into some depth of why PINs over passwords:
I don't understand the purpose of this at all then. That sounds like I now need to remember two passwords, one with all the problems passwords always had and a second one that requires my device to be useful. I hardly think two different attack vectors is better than one attack vector security wise, especially if one of the two former vectors is also the single later.
I guess the idea is that it is easier to use. I just setup a PIN for Windows Hello. The PIN requirements were more strict than the password requirements, so that is hardly more convenient. Maybe this is punishment for not wanting to use a fingerprint or face scan which remain optional. For now anyway, it feels like all I did was get my goose half cooked and end up with two passwords whereas before I had one. Even if I did give my face scan or whatever, I still need to use my password to login to things so my original point about two attack vectors seems to still stand.
No, because the PIN is tied to the device and becomes invalid much more quickly. A Windows password is potentially used in far more places and potentially across many devices.
> I guess the idea is that it is easier to use
For many, it really is. On some of my devices which lack biometrics my pin is just a few numeric digits easily input with a small numberpad. The PIN is backed by the TPM which wipes it after too many failures. This is far faster and easier to type in than my full Microsoft account password which uses most of the normal complexity concepts such as length, mixed-case, letters+numbers+symbols, etc. Far easier to just type 4-6 digits (or however long you want it to be) instead of dozens of mixed-case alphanumerics and symbols.
For instance, I recently got a gaming handheld which runs Windows. I want to use my Microsoft account, but as mentioned its a long and complex password. It seems this device doesn't have any biometrics, so its either type in my very long password every time the screen locks on a software touch keyboard or just type in a short PIN backed by the TPM. Which seems like the better process?
> it feels like
You may feel that way, but a Windows Hello PIN is not a password. They're different things in many ways. I could continue throwing more documentation at you, but somehow I feel like continued facts aren't going to change your feelings about this.
> No, because the PIN is tied to the device and becomes invalid much more quickly. A Windows password is potentially used in far more places and potentially across many devices.
I'm talking about the password classic here. It didn't go away. It remains one of the now two methods for signing in. Now there is also a second one while the original still exists, is it more secure? I don't see how two doors is stronger than one.
All else being equal, two access methods are strictly less secure than a single access method. But is all else equal? I suspect that there are quite a few people who are willing to use a long, complicated password occasionally but who won't put up with that for passwords that are used frequently. If those people use better passwords when they can use a PIN to make routine access easy, that's a win.
You could have a strong account password which is needed for remotely accessing the PC, and a simple PIN for convenience but which only works when authenticating locally.
(I'm assuming this is a personal PC and not a corporate device, in which case this model is the same but the strong password is also used for many internal single sign on resources).
Usually you pair this with a Windows Hello camera for face sign-in so you skip the logon hassle when in front of your PC.
There are settings in the group policy editor to change the Windows Hello PIN settings, but it could depend on your Windows edition and whether you have admin rights.
For example, if I use gpedit.msc > Computer Configuration > Administrative Templates > PIN Complexity, I see:
Require digits, Require lowercase letters, Max PIN length, Min PIN length, etc
> You can have your computer re-challenge you for a full password on some interval. So have it force you to use your password on your first login of the day, then you can use your PIN to hop back in during the day and then have the PIN option time out after so many hours. Same with any of the Hello credential options.
That still requires making up and memorizing a PIN.
Sure, but a short numeric PIN you probably type in several times in a day is probably pretty easy to remember. And once again also far easier to type in many situations than a long complex password.
Or even better yet use biometrics instead of the PIN.
The difference is that I can't login to your account using a pin. I need to use your master password or passkey, then once I have I can use a pin. Basically the pin is only local to your machine, so yes if someone steals your laptop it's the same, but there's a lot less people than can steal your laptop then can try to guess your Gmail password
My definition of a PIN is a password that can safely be short (i.e. low entropy), which means you can only use it against a system capable of enforcing a rate limit.
That can be local trusted hardware (such as a secure enclave, a Yubikey etc.) or a remote backend via something like SRP.
> If the passkey requires a PIN, I don't bother. I just can't be bothered to remember it.
Then use your password! A PIN can, but does not have to, be short :) FIDO-compliant authenticators have to accept up to 255 UTF-8 characters; you're by no means limited to a numeric 4-digit code.
Also probably includes all the times my company has made me change my password. It always takes a good week before I remember that my old password isn't the one anymore.
It’s because it’s easier. Here’s what an Apple user experiences for creating an account or signing in:
1. Tap the login with Face ID button
2. Tap to approve it
It’s even faster than using a password manager without MFA but safer than password+MFA, and you aren’t spending any time goofing around with some poser’s password complexity policy or rotating your password when their servers are breached.
for real, it's so much better i've started using it everywhere, to the point where if a service asks me for a password i get really annoyed.
no i don't remember this random string i typed in months ago and no i don't want to have to type in the password to unlock my password manager for the 82349th time
this whole thread is perplexing, a forum full of tech people bitching about something that's more secure and more convenient
> a forum full of tech people bitching about something that's more secure and more convenient
I don't trust a cloud vendor to own my entire digital life, and I don't want to have to stand up and maintain my own super complex self-hosted passkey service. Passwords are easy, just stuff them in an encrypted text file. I have no idea how to self-manage passkeys.
Hmm, let me try to put this another way: how can I use passkeys such that at no point does my login go through a third party in between me and the service I'm trying to use?
That’s what happens if you need to login from a device which doesn’t have your passkey on it: that device displays the QR code and you scan it with your phone and approve the request.
Still no third parties between you and the remote server.
Oh nice, thanks!! That Bitwarden link is exactly what I wanted to see. Open source software, no services to run, no cloud providers or phones involved. That's a much better process than all the weird phone stuff people are talking about all over this thread.
Yeah, the phone stuff is really an edge case for people using something like a work device to access a person account. I’ve tested it but almost never use it.
The public comms around this capability has been terrible, at least towards a technical audience. It all focuses on the "key stored on phones with proprietary OS" model, completely hiding how it actually works. I'm sure that's fine for a general audience, but as someone who doesn't trust these big companies with my whole life, it's an extremely repelling message.
Like the very first sentence on the official passkeys website is, "A passkey allows a user to sign in to apps and websites with the same process that they use to unlock their device (biometrics, PIN, or pattern)." I don't use any of those methods to unlock my Linux laptop! What does unlocking my personal device have to do with logging in to websites? Is it reading my /etc/shadow? What's going on here?? Just terrible.
Oh, it's just a keypairing system. Okay. Why don't they just say that?? How you unlock the private keystore is just an implementation detail, not an inherent property of passkeys.
Thanks again for the Bitwarden link, I'm going to play around with it this weekend and see if I can figure out how it actually works without all the offputting, misleading marketing speak.
I recently had a phone with a bunch of passkeys on it die unexpectedly. I didn't spend weeks resetting passkeys. I just logged into things with my hardware token on my keyring until all the sites I cared to use on my phone had fresh passkeys.
Or if my keyring was in the other room, I'd use the passkey on my laptop or desktop.
Most phones are waterproof and if your toilet holds your phone, laptops/desktops, and recovery keys it’ll also take your password vault because it’s an actually a black hole.
I currently have moat passwords synced with firerox. If I lose or break a device currently, I can restore from another, synced, device. If while using passkeys I lose or break my device, then what?
How would that work without a homogenious setup? Won't all devices need to be with Apple or Microsoft (etc)? Or is there a standard/cross platform solution?
Passkeys are already standard, enabled by default in all the popular web browsers, and thus already widely used by non-technical people (path of least resistance).
If Microsoft really wants to push passkeys, why do they require Microsoft Authenticator for passwordless accounts? I already have a passkey set up and I'd be perfectly happy to delete my password, but I can't because I don't want yet another authenticator app exclusively for an account I barely use.
I was tempted to set this up, as I’ve been using passkeys everywhere that I can. But yeah, I’m not going to use Microsoft Authenticator for this one single account. I even already have a passkey for my Microsoft account.
In some scenarios that’s really a difference without distinction though.
If I have a key to my house attached to a chain so it can be used to open the door but not leave the property and then secure it in a lockbox. If someone steals the key to the lockbox they technically don’t have access to the house key but they can still rob my house
Your scenario makes it so the house key doesn't matter in the end though; if they're able to get to the lockbox to use the lockbox key they're already in the house and thus already able to rob it regardless of whether they got the lockbox key. In the end your door lock did nothing for you at all. I don't get how that relates to using a PIN stored in the TPM to protect your actual password, other than suggesting "well your account can be hacked without even touching your device" which I mean yeah sure.
But in the end that PIN is still different from that Windows/Microsoft password. The PIN only works on that one device and gets totally invalidated after only a few failures. This is untrue of passwords which usually never get fully invalidated and are then used across multiple devices.
If you manage to find out my PIN to log into device A with my Microsoft account is 1234, you don't have access to my Microsoft Account in general or on device B. If you see I log in to my device A with hunter42 (my Microsoft account password), you can now log in to my Microsoft account and every other device I'm using my Microsoft account.
Is that a difference without distinction? I'd say that's quite a bit of distinction! And that's only one of the many differences!
Which is why I was careful to say that it was a difference without distinction only in some scenarios. Namely offline attack to a physical device.
In this scenario, even with the attempt restrictions the attacker has a couple of chances of relatively easy guesses, before falling back to the password protection. If we consider shoulder surfing, it’s a lot easier to distinguish a four or six digit PIN than a password.
I aware the PIN doesn’t give actual access to credential and so doesn’t impact online attacks. But that isn’t the only scenario.
Incidentally how much work is “in general” doing when you talk about the access Io Microsoft services granted by the PIN + TPM? It isnt zero access is it.
> how much work is “in general” doing when you talk about the access Io Microsoft services granted by the PIN + TPM?
I mean you can't just go to microsoft.com and log in knowing only my pin on a single device. If you know my PIN for a device, but you don't have the device, you don't have access to my Microsoft account at all.
And if you have all my devices? And what if you have all my external security tokens? And what if you also have all my passwords? And what if you have a complete replica of every thought in my head? And what if what if what if what if...
Sure. Whatever buddy. Nothing is truly secure. If they guessed my password as well along with my device I'd be in an even worse situation. At least my PIN just disappears forever after a few failed attempts and requires that physical device.
Needing a physical device which wipes itself after a few failed attempts is more secure than having a password that could be used anywhere on any device however many times they want to guess.
> without distinction only in some scenarios. Namely offline attack to a physical device.
There is a distinction in this domain though, and it's pretty massive. Offline attacks at guessing passwords, if you fail the PIN a few times (three on most of my machines) the PIN gets cleared never to be used again. Meanwhile you can keep trying the password over and over. The account password on the device isn't getting cleared. So I can make the PIN pretty simple and easy to type in while making my regular password very long and complicated. It doesn't matter if its a pain to type in, because its not like I'm typing it in every time I walk away and come back to my computer.
Except in this case it’s really important to learn how the implementation works because it has meaningful differences:
If you login to Google.com with a password, the remote server knows your password and if you are phished the attacker can use your password to access Google.
If you login to Google.com using a passkey secured by Windows Hello, your PIN or biometric check is between you and your computer, and the passkey is used for a public key exchange with Google’s servers. They do not know your PIN and you cannot be phished. That’s a transformative change.
A bicycle and a semi-truck are both machines with rubber tires to move people and things a faster speed than walking. The rest is implementation details.
X and Y are both Z. The rest is implementation details. Except sometimes "implementation details" makes the two pretty radically different in usage.
Incorrect. The PIN does not grant access to the service.
If all you have is the PIN, you don't get access to the service. Therefore, its not the PIN that grants the access.
If you know my keepass database passphrase, but don't have the actual database file, do you have access to the services contained within?
And as acdha mentioned, the entire login workflow is radically different with security keys / passkeys. Its a radically different implementation of authentication with different guarantees.
Do you leave SSH open on port 22 with only password authentication? It's just the same as using SSH keys, just a difference in implementation.
> If all you have is the PIN, you don't get access to the service.
That depends what the service is. If the "service" is a session on my desktop PC, then it absolutely does grant access. You'll have to take my word that if I type my PIN into it, it will start an interactive session.
My kid wants to play minecraft, but he can't because he doesn't have the PIN. If he did have the PIN, he could play minecraft.
I am willing to believe that the implementation of the PIN is totally different from passwords, but in this use case, the user experience is identical. The "attacker" does NOT need the password.
It is still not the PIN in the same way the password to the password vault isn't the password to an account. If you had a physical TPM that got removed, your pin wouldn't do anything. If the TPM got reset in the BIOS, the PIN wouldn't work. It's a step in the authentication workflow, but the PIN itself is not the credential. If a person tried to RDP to that computer with the PIN, they wouldn't be able to access it.
If your kid fails the PIN too many times, the PIN gets disabled. No more PIN retries until the real password gets used. If they tried the password a bunch of times, they'd get a timeout but could come back in a few minutes and try again.
I mean, I get what you're saying about from the user perspective the pin is the login, but the under the hood nuance makes things pretty different in the end when thinking more about what's happening.
Same thing with a fingerprint with a passkey to some service. The fingerprint itself isn't the login; you can't just go to any phone and press your finger and log in to the service. So the fingerprint isn't the login, its a part of the process on that particular device to unlock that particular saved credential that logs you in.
Before iPhones had biometric authentication, a PIN was the only means to unlock the cryptographic key that protects your data on the phone. It still is; you can bypass Face ID and Touch ID at any time by entering your PIN.
So it's not like this is a new thing. It's the same concept, but applied to a PC as well.
If you’re going to speculate about ulterior motives, fill in the supporting details so people can tell you’re not just promulgating conspiracy theories.
So you think that Netflix has gone to Microsoft to start a multi-year industry-wide standardization process to change how people login because that’s easier than looking at their own log files?
Netflix didn’t crack down on shared passwords when they were growing rapidly but that’s not because they couldn’t.
I don't, but yes; many seriously actually believe this is why the industry is moving to passkeys. It isn't logical, it isn't reasonable, but these are your customers.
Yes, if you're both using the same password manager. But, while you live in Silicon Valley bubbleland, most people don't. The world's most popular password manager is Excel; and sadly it does not support sharing passkeys (or, really, passkeys at all).
Baseless? Can you think of a reason why Netflix wouldn't support it for precisely this reason? Their campaign against account sharing is widely publicized. Do you think account sharing is easier or harder under passkeys? Just because it's a conspiracy theory doesn't mean it's false.
It’s baseless because it’s pure speculation without any evidence, or even a coherent argument for why they’d go to so much work for something they already do at much lower cost.
I think the argument is misunderstood here. I'm not saying this is the only reason that Netflix would be in favor of passkeys, just that it's one reason, not even the main one.
Here's the argument. I guess it's up to you whether you think it's coherent.
1. Netflix dislikes account sharing. They'd rather have two people pay for two subscriptions. They're a business, and are in favor of higher subscription numbers.
2. Passkeys make account sharing harder. Customer behavior modeling probably suggests that some fraction of account share-ers would create new subscriptions if they switched to passkeys.
3. Of all the reasons Netflix is in favor or against passkeys, this reason is in favor of them, via 1. and 2.
I think the argument was a flippant response by another user riffing off of a conspiracy theorist who misunderstood how passkeys work, and while I appreciate the effort you’ve made trying to salvage it I am skeptical that Netflix would be motivated enough to be part of their hypothetical Netflix/Google/Microsoft/Apple conspiracy but not enough to even implement passkey support.
That only works if the share target is using the same password manager.
If you asked most people "what password manager do you use" they would give you a blank stare; but sadly, the answer is rarely "I'm not using one" the answer is usually Apple or Chrome or whatever is built in and most convenient.
Ironically I've seen technical users far more confused by passkeys than 70 year olds on eBay. 70 years olds on eBay don't ask how the "Use Apple Face ID to Login to eBay" works and how secure it is, they just just generally trust Apple and eBay and just do it and it generally just works. It's the technical users that want to know all the details of passkeys down to minutia and have too many devices with syncing problems because at least one machine is a Linux machine with no hardware security enclave but "that's fine" because it is locked down to no real "cloud" access but still needs to login to eBay in an ancient Firefox fork that doesn't support passkeys once every couple of days for some hacky shell script bidder they've been running since they downloaded it off mIRC in the 90s…
Except if you switch phone numbers and get a new phone. My iCloud email address is permanently fucked because I set up an iCloud account years ago with a different phone number. Since I no longer have the number or another Apple device synced to that iCloud account, I'm permanently locked out forever.
Discussing 70+ year olds here, a decent portion of which will not have a smart phone due to age related visual impairment or motor control issues. Turns out that age related technical difficulties are not so much generational or digital-native nonsense, but physical. As the people pushing smartphone-for-everything will discover when they hit 50 and need reading glasses.
But don't you also get into that account via your passkey? How do you know that the passkey you are using to get into the Google/Apple account isn't the same one that will be lost if you lose your phone? I've actually implemented passkeys on my website and I still don't use passkeys for e.g my own Google account because I don't trust it.
I actually recently unexpectedly broke my phone. Getting back into my Google account protected by passkeys was pretty simple though, I just logged in to my new phone with a passkey stored on another device. Which is fine, because I've got several different devices with passkeys on them.
Same thing with logging into my mail provider which I use passkeys for.
A few accounts I did have to go find a backup passphrase for, but none of those accounts are the kind of accounts I'd normally be trying to get into while on vacation or something.
I don't travel very far or very long without a couple of different authenticators. If its farther than a bus fare and I'll be gone for a while, I'll probably have at least two, maybe three authenticators on me. For example, my phone, my laptop, and a yubikey. Its only a few dollars for the public transit around me, so if my car explodes on the other side of town with my bag containing my keys and my laptop in it and I had to jump out into the river to avoid the explosion and debris and it broke my phone I'll still be fine to get home with a few dollar bills in my pocket. Or hopefully those other physical security tokens commonly called credit cards will also still work. And there I'll probably have my desktop at home and another yubikey. But honestly that kind of thing doesn't happen to me too often so I'm not too worried.
All you said is that it worked for you, you even emphasize that your usecase was different because you have several devices. This doesn't relate to my question.
> your usecase was different because you have several devices
So we just normalize having multiple devices, and suddenly my use case is the same as everyone else's.
Its not like I'm talking about everyone having a dozen $1,000 devices. Several of my authenticators were like $20-30 and have lasted over a decade even getting thrown in the washing machine and getting left in the rain and dropped in the pool. One was on my keys when I was daily driving a motorcycle in a rainy season and still works a decade later.
People don't find it weird to have two car keys and those things often cost hundreds of dollars these days to be replaced.
People aren't going to buy little usb sticks, some phones don't even have usb ports and the NFC or bluetooth connection never works properly. Also generally even having multiple devices isn't going to save you when you really need saving. Like in a house fire or while on vacation and your phone breaks, who really keeps a second phone around constantly with all the passkeys on it, like e.g in your hotel room? Then what if someone breaks in and steals your backup phone, now you have to invalidate all those passkeys somehow right?
I also don't know whether there is even any recovery process planned or possible, I guess not? So why on earth would I pick a new system like passkeys where I can't just have Google email me a new password vs. a system where that is impossible? Effectively my email account is like a second device in the password system which is far easier to carry around than a physical device. Sure a second, different email account could get itself password guessed but the chances of that are so small, it's pointless to think about and even if it does get hacked, even then it probably wont matter because it will only get used during recovery processes for a few seconds.
It also still doesn't answer the question around how I would know whether the passkey I created on a different device will work. One time a login process on Windows told me to use a QR scanner via my phone and then I got logged in. Okay so did that create a new passkey now and where? Both devices were involved in the login process, it was unclear to me. Maybe it was also the registration process, they are so similar now that I can't remember.
I guess maybe half the problem is that the proposition seems so strange: We are being told that all of a sudden having multiple "passwords" for the same account is actually great, it's secure. In fact: Just have a new password for the same account on every device, you can just keep creating new passkeys and it's no problem at all?! Oh and btw, if you lose any one of those your entire account is utterly compromised and good luck figuring out which of those passkeys you have to invalidate now. Somehow this is okay and secure.
Tons of people walk around with lots of little hardware security modules every day. They've got a wallet full of chipped credit cards, they've got car keys with transponders, etc. What's one other piece of plastic on the keyring? What's one more card in the wallet?
> some phones don't even have usb ports
Practically no smartphone sold today has no USB ports. And besides, we're talking about activating a new phone, so chances are that new phone is going to have a working USB port.
If they don't even own a smartphone and don't want to own one, well, then sure I'd agree they maybe shouldn't use passkeys. But if they're not using a smartphone they're probably not too worried about logging into their iCloud account or Google account or whatever on their dumbphone. So I don't see the issue of their dumbphone not being able to log into the services which aren't supported on the device anyways.
I'm not necessarily arguing they're for everyone, but they do apply to most people in most developed countries. They should be an optional way to access your account.
> on vacation and your phone breaks, who really keeps a second phone around constantly
It's not a second phone, its either the yubikey on my keys probably still in a bag/safe in the room if I flew somewhere or it's in my pocket.
> someone breaks in and steals your backup phone
Yeah, I'd probably want to go about disabling it eventually. But generally, I'm not too worried in the immediate time. You need to unlock the device to get access to the passkeys. If you fail too many times, you're not getting access to the passkeys, ever.
> Effectively my email account is like a second device in the password system
So effectively all your accounts are protected by a single password that's available to have people attempt your password anywhere, anytime, pretty much however fast they want to.
> Sure a second, different email account could get itself password guessed but the chances of that are so small
As someone who's managed email for a lot of people, it's really not that small of a chance if it's just a password to an email account.
The only thing I'd potentially be really worried about is a house fire, but pretty much every important account of mine has backup passphrases in the fire-resistant safe. I do live just down the street from the fire station though, so the odds of a fire burning up all my stuff including everything in the fire resistant safe seems pretty low. Probably lower than your everything in your life email protected by just a password getting hacked.
I mean in the interim. How do they get into their email to find their support contract to get another phone if they can't get into email without their phone?
What if you're traveling and there is no Apple Store nearby? And now you can't log into your email to get your travel itinerary or your transportation receipt?
The greater point is not the specific edge cases, it's that they haven't been worked through. Even a sophisticated user like myself doesn't want to use passkeys exclusively yet because of this very reason. I'm not confident that I won't get completely locked out when it's absolutely critical that I get in.
As he’s 70 he’s using an old desktop PC and doesn’t have a smartphone. He uses the on device pass key system. One day, months down the line, Bluetooth gets switched off for whatever reason. What then.
So Microsoft blocks password attacks. A blocked password attack will never be successful. And they have to block a measly 7,000 of such attacks per second across the entire organization.
Wow ... how not to convince me that passwords are a problem.
I wonder how the internal metrics even define "password attacks". I have a 15 year old Skype account (with a long password) which I lost access to because Microsoft suddenly started requesting verification, insisting on 2FA via SMS to a 10-year-old phone number. Are all ten of my attempted logins counted in that statistic?
I imagine it has to be a certain number of attempts, because it's counting the password attacks that are stopped. You don't identify and stop a password attack after just two or three attempts. Let's say that the threshold is 20 attempts. So that's 7,000 * 20 = 140,000 password attempts per second. That's not very fast. It will not uncover strong passwords in any reasonable timeframe.
False negatives are a thing. If they've got a 99.9% success rate at blocking password attacks, it means there's 7 qps of successes. That's 500k hijacked accounts per day, 200M per year. That is a very large number.
And not a lot of systems have 99.9% recall, without trading away absurd amounts of precision...
If they suspend an account after, say, 20 password attempts, they're success rate at stopping password guessing will be vanishingly close to 100%. Especially if they've instigated strong passwords.
If passwords cannot contain dictionary words and must be mixed case with at least one special character in digit, there's no freaking way anybody's going to guess their way in, with a small number of tries before the account is frozen. The number of penetrations from that is going to be so tiny, it's not worth worrying about.
The bigger worry are stolen password hashes being cracked surreptitiously, where the attacker has an unlimited number of tries whose rate is only limited by their hardware.
Passkeys are good but giving my access keys to big tech (Google, Apple, Microsoft) is not acceptable to me.
There's other passkeys implementations and you can even use regular yubikeys as a passkey. But the problem is, many idiot sites block these implementations. PayPal for example only allows it in Chrome or Safari.
How do I backup my passkeys? I can print out a hard copy of passwords and even 2FA code generator strings, but I haven’t seen an easy way to export and import passkeys. This is a problem.
If it were as simple as printing out a list of QR codes or URL strings I would be happy, but so far no password app I know of supports this.
At the moment, export/import is not part of the "Passkey" standard. The FIDO Alliance has a draft of the Credential Exchange Protocol that would allow such actions. Allowing the trivial export of a passkey would end up defeating the cryptographic protections they offer.
I don't understand how can it really prevents exporting passkeys if it can be implemented by open source implementations like keepass.
For example, if keepass do follow the guideline of FIDO Alliance to not implement exporting, but it would still possible to make a fork of keepass that force it to dump the credentials somewhere.
You probably know most of this, so sorry for the over simplification. but you asked.
A passkey is an implementation of public key authentication.
The private part should stay with you, this is your identity. The public part gets shared with others, they can use this to verify your identity. "microsoft passkey" wraps all this up into a simple tool that just looks like you are putting in a pin number.
The vague thousand foot mechanism is. someone who wants to verify your identity will ask you to sign a unique number. because only you have the private part needed to to do this, only you can sign it correctly. they can then use the public part to verify the signature is correct. and know it is really you they are talking to.
The private part is usually protected by a device, something to prevent others from using it. this is often just a password, in this case a PIN. but some times is a dedicated usb dongle. this only has to have local security guarantees not global network security guarantees. so a simple password like a PIN is not considered a problem.
The primary advantage over a simple password based system is that the thing that is shared(the public part) is unable to be used as your identity so it can't be stolen like a password. or perhaps more accurately, it does not matter if the public part is stolen(it is already public knowledge)
And now the irony, I have no proof, however I have a suspicion that because loosing the private part is the same as loosing your identity, that is, a big deal and a huge hassle to recover the account. I suspect microsoft is storing them internally. which means your account security degrades to a password based system where the password is basically pubic knowledge, that is, your so called security questions. what is your favorite color? is not a good password.
1. Passkeys contain the username and the domain of the service that you have registered with
2. Because passkeys contain the domain, it provides very strong phishing protections, because a look-alike website still has a different domain.
Passkeys are resident keys. They take up storage space, which is a problem for dedicated hardware tokens which usually have limited storage space. A much nicer solution are non-residential keys that get recomputed on the fly based on the domain name that you want to authenticate against.
So is this following the OpenID Connect/JWT type flow?
The site registers itself with your passkey "wallet" (?), and logging in would use a signed request and your wallet provides a shared secured response so you both can confirm who you say you are?
> So is this following the OpenID Connect/JWT type flow?
No. This is orthogonal and can be used in combination with the aforementioned technologies.
Let's assume you want to use OpenID connect and also JWT.
1. You have your own web service that does not implement a login form but relies on OpenID connect.
2. You have an authentication service like GitHub, Facebook, Google, ...
3. Your users have a pre-existing account on GitHub, Facebook, Google, ... They use their passkey/non-resident key/plain old password/... to log into one of these services
4. Your users want to log in to your service. They start the OpenID Connection protocol using the authentication service. If they are not logged in yet, then they have to present their passkey/non-resident key/plain old password/... to get logged in. Once they are logged in, the authentication service can issue a fresh JWT to your user.
5. Your user can then use the JWT to use your service.
How does this mechanism prevent breaking one of the commandments of encryption systems:
Thou shalt not sign arbitrary plaintext
… if, as you say, a service first gives you something to sign with your private key ?
What kind of “phishing” would it be if Mallory convinced Alice to create a new account on some new service for the purpose of leaking private key bits?
A new private key is generates for each site, and only that site has the corresponding public key, and the domain name is checked, so malicious.com can't leak the private key for example.com.
As far as I can tell signing arbitrary plaintext is a core mechanism in how public key auth works.
The theory is you have to sign something to prove your identity. this thing you sign has to be provided by the authenticating body and should only ever be used once to prevent replay attacks. that is you never want a situation where someone can give you a copy of the signed message and login.
For example, and the only one I have actually read the standard, during auth ssh signs a number of fields, the critical one being the session id. the session id is provided by the server and is only used once, thus satisfying this critical part of public key auth.
It's like when you get the push notification on your smartphone for two factor auth. So instead of typing in a password you get a notification on a secure device. For example on macos I can save the passkey in the os/browser and use my fingerprint to log in instead of a password.
I really just want passkeys to exist for a decade and all lockout/lock-in edge cases being resolved before I retire my password manager, and before I tell my mother to move to passkeys.
Looks like they're beginning to work on it as we speak, how is this not supposed to be proven as stupid as possible by now :\
>At the moment, export/import is not part of the "Passkey" standard. The FIDO Alliance has a draft of the Credential Exchange Protocol that would allow such actions.
If it's already a standard, and it's that deeply faulty because it's been brain-dead since the beginning, then for a user having valuable data, they may be best advised to run the other way forever. Simple.
When you have an alliance of previous competitors and they are either incompetent or user-hostile enough from the beginning to leave out the most important factor in recovering from disaster -- personal backup & recovery -- I would want to wait a good ten years until after everyone as untrustworthy as that has been banished from any security work that could be the least bit consequential.
You can't have adequate security with untrustworthy people building the foundation no matter what they say otherwise.
People are the real problem, but clueless "security" people with initiatives this half-baked are more of a threat to average users' valuable data than millions of other clueless users are.
There's no reason not to trust it. It's strictly better than passwords in almost every regard. Of course if you manage your passwords well, you don't get more security with passkeys, because your account is already safe enough. But for someone, who used to write his universal "Johny1987" password on a sticker at his display, passkey provides security and usability benefits.
Passkey is just not supposed to solve all the problems in the world. It's supposed to replace login and password and that's about it. Authentication.
A trusted third party has a copy of the physical key to my flat. I handed them over once and they still work. I can print out the passwords and 2FA keys required to recover the most basic services (such as primary email and password manager) — as long as I don't change the credentials, it will keep working. But if I use passkeys stored on device, what are my recovery options? Do I need to retrieve the backup device every time I create a new passkey?
so OTP with the seeds backed up somewhere, and then passkeys on the devices I use often?
Seems like this will also be difficult for a lot of non-technical ppl. Though I guess not much worse than forgotten passwords?
In Scandinavia we have authenticators tied to the banking system (MitID in dk and BankID in sv), where if you lose it, you can get it renewed by going to your bank, or you can have a special hardware device at home that helps you renew it. Does this exist other places? These are used on more and more sites around here, where your real identity is important (everything utilities, banking, insurance, banking etc).
If you are comfortable using a cross-platform app like 1password, then passkeys can be a pretty great user experience even across ecosystems.
But Passkeys have a huge problem: They assume you will never have your device(s) stolen or broken or otherwise made inaccessible.
What happens if you're out of the country on holiday and your phone/laptop gets stolen and you need to log into your account(s) from a brand new device? You're mostly shit out of luck if you use passkeys. Especially because most peoples' backups/account recovery is a google email or icloud account which...requires you to have a known device handy to access them or set them up on a new machine.
I use Bitwarden. I don’t mind passkeys ending up there. But i want them all in there. I find the UI/UX is really poor with browser extensions, etc. and preferentially trying to use the OS’s password manager to store passkeys.
My mother has been using it because "now [she] only needs to enter her 4 digit computer pin instead of her long Bitwarden password"
Unfortunately she is unwilling to change her Windows pin to anything other than the PIN she uses everywhere else.
This has not improved her security at all. Before she switched it from what I assume was a Microsoft prompt, she had (through a bit of coaching from me) been fine with Bitwarden + TOTP
A lot of the arguments I'm seeing against passkeys are essentially that they are worse for power users who already have a password manager. But they're not mutually exclusive. I've been using bitwarden to store some passkeys. The UX is excellent. Everything is seamlessly synced across Linux, Android, and Windows.
I do worry a bit that using a passkey tends to disable MFA requirements, so basically anyone with access to my bitwarden vault can log into those services.
Does PAKE protect against scenarios like "password written on sticky note", "fake login page hosted at login.nnicrosoft.com", or "scammer impersonating IT staff"?
> If I lose my only front door key, I can't get into my house.
You can pay a locksmith to pick (and rekey) the door lock. You can even break down the door and replace it later. None of that is an option with passkeys.
> Signing in with a passkey is three times faster than using a traditional password
Unless I'm using a password manager.
> Users are three times more successful signing in with passkeys than with passwords (98% versus 32%).
With my password manager, I almost never fail to sign in. Admittedly, the autofill does mess up on some websites and then I have to spend a few seconds fixing it.
On the other hand, I am pretty darn skeptical that only 2% of users with passkeys have trouble signing in. Are they not counting the people whose passkey accidentally got deleted, or who are on the wrong device, since those people (by the nature of passkeys) could not even attempt to sign in?
I'd appreciate it if they let me block specific countries, etc from even attempting to log in. You can see the failure attempts somewhere in your user settings and I have them all day long from countries I'll never step foot in and quite a few adversarial.
It is an open standard that is supported by all major OSes and browsers.
In fact, I would wager that the majority of current passkey users are on iOS (since Apple has been pushing this for a while now, and it's nicely integrated).
Aren't passkeys centrally hosted? So if MS gets breached or decides I don't matter they can just lock me out of my life if I host my passkeys with them?
> There’s no doubt about it: The password era is ending.
No it's not. How am I suppose to login to a console of a air-gapped server with passkeys?
> Signing in with a passkey is three times faster than using a traditional password and eight times faster than a password and traditional multifactor authentication.
When you sign in to anything Microsoft, you have to go through four different redirects, sure automatically but not not exactly single page sign-in.
> We don’t let users permanently opt out of passkey invitations, but we keep the messaging friendly.
by friendly you mean Dark-UI to push the user in the corner forcing them to accept as you limit their options one by one with threatening notification and nagging.
> We’re proud to be part of this collective effort and hope you will share learnings as well as you progress in your passkey journey.
Learnings is a grammatical error. Microsoft is proud to be a collective for part of vendor locked in.
How are untrained users supposed to trust passwords if they don't understand the differences between unsalted SHA1 versus PBKDF2 versus bcrypt and probably don't know what practices their third party is doing to properly hash the password?
Explaining password managers like the browsers' or 1password is easier than explaining passkeys. At least with password managers, you can export the whole database when switching platforms.
I agree. People ask the same questions about password managers just storing passwords.
One of major failures of the passkey marketing is that the FIDO Alliance left it at:
1) Vendors marketing passkeys as this brand new thing for their customers;
2) Anyone technical needing to already know that passkeys weren’t this brand new vendor specific thing, and reading the standards documents.
Passkeys are essentially just a marketing name for FIDO2 credentials with a focus on particular kinds of implementation. But FIDO didn’t bother to handle communications to technical folks outside the authentication space, and they’ve failed to do so effectively beyond that area.
“In the two years since passkeys were announced and made available for consumer use, the FIDO Alliance reported a few weeks ago, “passkey awareness has risen by 50%, from 39% familiar in 2022 to 57% in 2024.”
I don’t think that math works? Am I misinterpreting something?
The FIDO Alliance can eat it until they support exporting passkeys and stop passive-aggressively threatening, "why don't we talk about this privately" anyone who tries to implement that.
My company uses Azure SSO so I am curious if this is just coincidence... but just this morning I had two (2!) separate desktop support technicians reach out to me today asking if I got my passkey set up for the company portals.
If they use MITM, that will include themselves. A password manager doesn't try to log in for you. But most passkeys managers are MITM. At least we can audit OpenSSL code, and we don't have to care about our public keys.
It is public key cryptography. You give websites your public key, and keep your private key hidden. When you sign in to a website, they send you a nonce. You then digitally sign the nonce with your private key. They verify that the signature was signed with your private key, allowing you to log in.
There is no private info (aka a password) going out in public so you don't have to trust anyone to keep your password secret.
It greatly reduces the attack surface of logging in, but the attack surface is moved to the weakest part of the system, aka the user.
I honestly don’t care about the “passkey” revolution. I use a password manager that generates a unique password for every service for a reason. Then secure it with 2FA (either with TOTP or emailed magic link), if available.
I think I have used a digital passkey a few times to try it. Works okay, I guess.
From the HN pushback I think this will end up like IPv6. I get to have nice things and some others likewise - many people get to repeatedly say "Nice things are impossible" and roll their eyes. I guess they're having fun in their own way?
It's nice when we build a non-brainer technology which gets adopted at scale by default, as happened for TLS 1.3, or even when other motives overwhelm the instinctive conservatism (e.g. Let's Encrypt) but that can't always happen and it looks like for WebAuthn the conservatives are going to stick by passwords "From my cold dead hands" etc.
One problem with HN in particular is that there are a lot more decision makers here, so more people whose conservatism means they're going to build, promote and demand worse solutions since the better option is in their minds impossible. That's unfortunate, it means there's a good chance that over the next years I'm going to be using more important services which have terrible authentication on account of somebody senior said "Passwords are good, we should require passwords" and anybody disagreeing was hushed or worse fired. So that's not great, but it is what it is.
Anyway, for the few people who get why this is a good thing but understandably don't trust Microsoft (or Apple, Google, Facebook, I dunno, Epic Games?) I have a suggestion: All of this technology also works fine with a Security Key, which is a thing you can buy from Yubico (or several other outfits, but Yubico is easiest if you have no idea what you're doing) for like $25. And if you - like me - use Security Keys those "But what if I lose it?" questions can be answered by Technology Connections' favourite: The magic of buying two of them.
Security keys (i.e. "roaming authenticators" in WebAuthN language) have significant practical usability and availability downsides.
> "But what if I lose it?" questions can be answered by Technology Connections' favourite: The magic of buying two of them.
And the magic of having to access both of them every time you create a new account anywhere, which probably means you'll keep them both close by – increasing the availability risk.
A more realistic recommendation would be to use an open source FIDO backend such as Bitwarden or Strongbox that let you cross-platform sync and, worst case, export your credentials if the vendor goes down a bad path.
Sure, if you trust Bitwarden but not Apple, you can, as I had assumed was obvious, use Bitwarden's Passkeys and not Apple's.
Personally I would rather have Security Keys, and there are going to be plenty of people like me. Yes, if you need a physical object as an authentication token you will sometimes need to have that object with you, I also thought that went without saying, but it's true in case it wasn't obvious.
Signing up for new accounts which deserve a separate meaningful identity (like a bank account, or a Youtuber's account, or GitHub maybe) is not a common occurrence, in the time since I last got a new Security Key I have added let's see, zero new accounts, so I had to add that key to all the existing accounts, at work and outside, then nothing.
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.
reply