Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passkeys: A shattered dream

fy.blackhats.net.au

Post reply on HN
Print view View original

251–260 of 789 posts

Re: Passkeys: A shattered dream

#251

Post by noirscape »

The main thing that hurts Passkeys was how the implementation was so deeply tied to letting the browser do stuff rather than making it something like TOTP where any password manager can implement it and it's usable, agnostic from the browser. Everything about Passkeys is defined around using your browser as the agent that authenticates.

The problem is that browsers are infamous for randomly losing things like localstorage, settings and saved passwords. It's way too volatile software to do authentication with besides a "stay logged in" checkmark. In both of the main desktop browsers, a corrupt profile is often only "fixable" by just nuking it and having the browser recreate it.

That's what killed Passkeys; people you want as early adopters (technical folks) don't use it because browsers aren't a trustworthy storage and the implementations all severely stalled in providing alternative methods that are tied to more reliable storage mechanisms. The hyper aggressive vendor lock-in is also not helping much (to the point where KeePassXC got yelled at for providing an export mechanism).

Re: Passkeys: A shattered dream

#252

Post by TacticalCoder »

crote wrote: post #218

The part I hate most about Passkeys is that it essentially killed the FIDO1/U2F ecosystem. Just about every website which implemented Passkeys removed the option to use hardware tokens with "non-resident" credentials. This means you're stuck using your Yubikey as either an insecure TOTP token, or as a practically-useless Passkey. We had the perfect 2FA method with U2F hardware tokens, why did they have to take that a…

> We had the perfect 2FA method with U2F hardware tokens, why did they have to take that away?!

It deeply saddens me too.

But I think we shouldn't discard one of the obvious reason: the U2F system was too secure.

Let's not forget this: the original U2F system even had a way for the user to know if its device had been cloned, for they'd be using a counter. And they silently removed this.

When Apple+Google+MSFT team up to lower security, I'm pretty sure three-letters agencies and their backdoors aren't very far.

The whole concept of passkeys that can be copied around is honestly hilarious. FFS: we had the perfect solution...

I don't think it's only incompetence at work here: there has to be mischief or at least mischief shouldn't be discarded.

Re: Passkeys: A shattered dream

#253

Post by acheron »

squigz wrote: post #23
rob74 wrote: post #19

Earlier quoted context omitted.

Apparently... of course, the threat of "mass casualty violence and terrorist attacks" is real, but you're probably still more likely to die in a plane crash while getting to the US (or in a car accident while there) than in a shooting or terrorist attack. And if you insist on only travelling to countries that have a lower level of violent crime than Australia, you probably won't get around much ( https://worldpopulat…

Oops, you forgot the other 2 travel advisories the author quoted in that part: - "Violent crime is more common in the US than in Australia" - "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance" I think some Americans don't realize that, outside of America, many people don't ever consider the risk of gun violence in their day-to-day lives, or owing thousands of dollars for…

We don’t actually consider that in the US either, you probably shouldn’t get your views of the US from Reddit or the Guardian.

Re: Passkeys: A shattered dream

#254

Post by acheron »

joshstrange wrote: post #134

I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up. I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not in…

Yeah I’m not sure what’s going on either. Is this just a rebranding of mutual-auth SSL client certs?

Re: Passkeys: A shattered dream

#255

Post by barnabee »

makeitdouble wrote: post #242
brabel wrote: post #186

Earlier quoted context omitted.

You're wrong, with password managers you can definitely be phished. Unless it's literally impossible to extract the password to enter it manually, but I don't think password managers make that impossible (and if it's possible, users will do it). With passkeys it's literally impossible.

Could you expand on how to trick a password manager to enter the password on a fake domain ? I'd see having the user add the domain themselves, or get the user to copy/past the password themselves on some other form. But the phishing is not happening on the password manager side, and these use cases still exist even after you chose passkeys (i.e. I'd still need to somewhat log into Google's auth from my Nest hub for…

It happens to me very regularly that a password in my password manager is needed on a different domain. Maybe the logon process is at id.domain.com and password is pinned to domain.com, or maybe the password was created at signup.domain.com and so it doesn't pop up on domain.com, or you have to log in to a hotel's site with the password from their reward scheme (different domain), etc...

In any case users are trained by the internet to need to search for the right password outside the pinned domains. Most of the time I guarantee people don't add the extra domains to the password records. So when a phishing site pops up they'll do the same: search for the site name/domain that they think they're logging into and go from there.

Password managers solve password reuse, weak passwords, etc. but IMO do not solve phishing, especially not for the kind of user who's most susceptible t it (little technical understand, hates this stuff, just wants to follow instructions and not deal with it), but passkeys might.

Re: Passkeys: A shattered dream

#256

Post by dboreham »

kriops wrote: post #247
geertj wrote: post #181

Earlier quoted context omitted.

Nice phrasing, I lack that mental model as well. Anyone here willing to distill down the whole thing to a few sentences? Who stores what kind of secret, and is there some kind of challenge/response at auth time?

Most important feature imo: The effective "password" being sent over the wire is essentially some hash(secret, uri). Think about the consequences for phishing!

Not true.

Re: Passkeys: A shattered dream

#257

Post by UncleMeat »

Twisell wrote: post #200
xoa wrote: post #185

Earlier quoted context omitted.

> All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up. The basic logic here is pretty clear imo. Passwords are still symmetric factors, and they're also completely unstandardized. So you still have to do a significant amount of manual management crap that should not exist, deal with UI that should not exist, and…

Yes but what I'm still confused about is that: 1) Is one/some of your public key reused on different services 2) Or is there a different public key for each service 1) In the first case what will prevent different services to track users by comparing public key... and if so I would be more at ease with a site specific randomly generated password 2) In the second case when one service is breached you'd still have to m…

The whole point of a public key is that it is not secret. A breach where a service leaks the public keys of its users does not harm your security posture at all.

Re: Passkeys: A shattered dream

#258

Post by dboreham »

acheron wrote: post #254
joshstrange wrote: post #134

I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up. I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not in…

Yeah I’m not sure what’s going on either. Is this just a rebranding of mutual-auth SSL client certs?

Kind of. With the sharp edges filed off. There's no CA though. The web site provisions and authorizes the client's key at onboarding.

Re: Passkeys: A shattered dream

#259

Post by makeitdouble »

triblemaster wrote: post #210
makeitdouble wrote: post #203

Earlier quoted context omitted.

I reread your analogy a few times, and while I think it's probably accurate, there is absolutely nothing simple in it. It reminds me of the "It's like Uber, but for mortgage insurances" kind of startup pitch. It perfectly encapsulates the concept, but the concept itself is just crazy niche. To note: the key to start a car is provided with the car with no specific operation, is locked to no other device, doesn't care…

https://news.ycombinator.com/item?id=40168230 See this and let me know if it makes more sense.

I understand passkeys as authentication through a private/public key generated by the client when creating the credential, with the private key staying client side and the public key kept server side, with some more details around it to make the whole thing discoverable/automatable.

To me the best explanation was just to go to the passkeys.io site, the subject is complicated enough that analogies tend to introduce a lot of cognitive noise IMHO.

Re: Passkeys: A shattered dream

#260

Post by UncleMeat »

acheron wrote: post #254
joshstrange wrote: post #134

I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up. I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not in…

Yeah I’m not sure what’s going on either. Is this just a rebranding of mutual-auth SSL client certs?

It is a different technology with some different edge cases so I wouldn't call it a rebranding but in the broad scope yes. The problem with this stuff was always the integration, not the tech.
Post reply on HN