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.
