Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

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.

>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 can give a better answer than the sibling:

The passkey is domain bound, so the UI won't show up on the phishing site before the passthrough can even happen.

Password managers are also domain-bound though.

> Password managers are also domain-bound though.

are also --> can be

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.

Agreed. Even a few hours ago I got something for w-m.com (!) which was actually genuinely sent by Walmart.

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.

A dash in a domain though is pretty ratchet.

> 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?

This would require compromising the website as a whole

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.

>This flavor of phishing is eliminated by passkeys.

... and also eliminated by password managers that use autofill based on the domain name.

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.

Finance sites using passwords feels... so off. I do use Kraken somewhat, and they have a passwors still, but also use an authentication app.

In Sweden no bank has used passwords online.. ever I think? It has always been 2-factor of some kind.

What was the first factor ?

For me it was always some kind of PIN - and then they built their own proprietary second factors which is also a bit insane imo

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.

Really tired of the fixation with tying everything to DNS in order to make it the "single lever to censor the web". We have to be able to do better.

Great explanation, thank you. Thinking about them in terms of PKI and SSH keys finally clicked for me.

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

pwdhash does that for passwords - binds them to DNS name.

So, it's just a password manager that doesn't show you the password? With pwdhash it's difficult to fill things manually too.

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!

...this is also the problem with passkeys. It makes it so much harder to move to a new device, and easier to get locked out.

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.

> have about the same level of protection

They don't

> have less lock-in

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. Like MS, Apple, Google.

And the real independent implementations like bitwarden are often blocked by sites like PayPal does.

> 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.

Which ones then? Using yubikey means enrolling multiple of them as backup which a lot of sites don't allow.

Other implementations are often blocked, eg on paypal I've never been able to do it and they also only allow one.

The big tech ones don't have these issues but I won't use them because I want to keep control.

> a lot of sites don't allow.

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.

Just gonna point out that AWS IAM only started allowing multiple 2fa devices 2 years ago.

https://aws.amazon.com/blogs/security/you-can-now-assign-mul...

It's entirely possible that many sites shared this flaw.

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.

"A dad took photos of his toddler for a doctor – Google flagged him as a criminal"

https://news.ycombinator.com/item?id=32538805

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.

You don't need to involve Google or Microsoft or Apple to use passkeys.

Your whole argument is a misunderstanding of how they work.

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.

It's not honest discussion.

> People that by into systems they don't control are shooting themselves in the foot

I don't have any control how any site I didn't build actually handles my password.

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?

"you" can copy out the password and still "log in" on the phishing site, leaking your password.

"Dang, this stupid password manager seems to rarely autofill right, lemme quickly paste that in there...got it!"

You can never make this mistake with a passkey or FIDO authenticator.

You can still provide your Passkey password though to some scam. A centralized storage of your passwords.

There is no passkey password. If there are, it is entered into the dialog box not a site. And wouldn't do any good cause the passkey is saved on the device and does a key exchange.

If you mean the password manager password, then it is entered in a different place and really hard to confuse it with a website. Also, 1Password requires extra info to login account and that is only used, usually copying from another device, when setting up device.

The PIN for the hardware passkey device in my locked drawer at home is 1234567.

Oh no, you have its PIN! Can you now log in to $service as me?

Not without that hardware module.

My password for $service is hunter42.

Now you can log in as me.

See the difference?

I am trying to come up with a counter argument but gave up. Since you are correct.

Is it fine if a waive my hands around and say "complexity"?

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.

It’s theatre because you still need the non passkey recovery method. The system is as weak as its weakest link.

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.

I tend to agree @tpatek but I’m really too much of a security newb to hold a strong opinion.

What’s the best resource in your opinion for learning enough about passkeys for a lay person to make informed decisions on them?

How about... an interview with Adam Langley about their design and properties?

https://securitycryptographywhatever.com/2022/08/11/passkeys...

(I'm not being totally serious).

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.

The pin code can be easily registered by one of ubiquitous security cameras.

Fingerprints can be lifted from photos where your hand is in frame. And no, you can't change fingerprints after they are compromised.

>it requires physical access to the device

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).

> Fingerprints can be lifted from photos where your hand is in frame.

Or used with your own fingers while you have been drugged or you passed out being drunk.

A PIN or fingerprint aren’t necessarily less secure than a password (and can in fact be much more secure).

In any case, nobody is stopping you from using a password-secured implementation! I do that myself on some of my devices.

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.

Reply on news.ycombinator.com