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

281–290 of 789 posts

Re: Passkeys: A shattered dream

#281

Post by noirscape »

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…

That second one needs to be pointed out in particular - the US healthcare system is so expensive that if you have healthcare insurance as a foreigner, they're typically excluded from the international plan. You have to specifically go out of your way (and pay more) to make your local health insurance cover the US.

Quite a few people don't want to deal with that.

Re: Passkeys: A shattered dream

#282

Post by AnonC »

javawizard wrote: post #141
4ad wrote: post #68

Earlier quoted context omitted.

If you use a software-based password manager, passkeys are indistinguishable from passwords both from a UX perspective and a security perspective. If you store passkeys in hardware, then yes, passkeys are more secure, but you lose portability.

> If you use a software-based password manager, passkeys are indistinguishable from passwords both from a UX perspective and a security perspective. That's not correct. Passkeys use public-key cryptography and a challenge-response authentication mechanism, so an adversary in possession of a read-only copy of the database of the service you're trying to authenticate with won't be able to authenticate as you - which is…

> an adversary in possession of a read-only copy of the database of the service you're trying to authenticate with

True, but GP is referring to the private key on the (user’s) device or computer being stored in a password manager. The main protection that passkeys offer in such a case is that there’s no case of passkey reuse across services and accounts, which is something that’s possible with passwords even if one used a password manager (albeit poorly by not generating unique passwords for each account).

Re: Passkeys: A shattered dream

#283

Post by frantathefranta »

teeray wrote: post #271
saagarjha wrote: post #21

The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in. If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this. Of course this means you can never be phished for your credentials bu…

This is why I’m not interested in passkeys unless I can use it with my password manager (which I probably can at this point). It would also be nice to see the spec for these specifically address lock-in and provide anti-lock-in measures.

KeePassXC has support for passkeys now. However I've only managed to make it work with GitHub. Bitwarden does not work for now (although their passkey implementation for log-in is reportedly in beta).

Re: Passkeys: A shattered dream

#284

Post by frantathefranta »

bradley13 wrote: post #123
saagarjha wrote: post #21

The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in. If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this. Of course this means you can never be phished for your credentials bu…

KeepassXC says that it is adding (has added) passkey support. I haven't tested this yet, but if it works, that would avoid platform lock-in. Assuming, of course, that the platforms don't somehow intercept the passkey requests and refuse to allow KeepassXC to do its job. The big tech companies (Google, Apple, MS) have all become evil.

I've tried it and it works on GitHub. Sites seem to be hit-or-miss for now. Tip if you want to use it with the browser add-on, it needs to be manually enabled and you also need to remove any YubiKeys from the system because it will prioritize them over KeePassXC

Re: Passkeys: A shattered dream

#285

Post by brabel »

dogman144 wrote: post #269
brabel wrote: post #206

Earlier quoted context omitted.

They can, and hopefully will. To get a new passkey on another device, the provider needs to allow you to prove you have possession of your other device first. They can do that by sending you a one-time code, for example, when you authenticate using your existing device, which you can then type in the new device, and that lets you associate your new device-generated key with your existing account. With iCloud, you don…

There’s more to phishing threat models than strictly credential theft, as you seem to imply. If passkeys are around, phishing will certainly still exist, and shift to dropping malware on endpoints or w/e vs going after logins

I don't think you know what phishing means. By "dropping malware on endpoints" I think you mean having a website serving malware? That's not phishing. For an attack to be "phishing", the website needs to be pretending to be some other website that the user trusts. Passkeys completely prevent the user from logging in to another website than the one they've created an account with.

Your attack only works on people who basically "trust any website" at all. For those, yeah there's no salvation.

Re: Passkeys: A shattered dream

#286

Post by Mindless2112 »

donatj wrote: post #129

The problem with passkeys, beyond the painful UX that will scare any casual users away and the fact that they are being wielded as an extreme vendor lock-in mechanism is just that the design and implementation is so over complicated with second system syndrome. If you’re going to push a replacement for passwords and want it to be universal, it should be EASY to implement. Even if the backing cryptography is complex,…

If you want passkeys without Javascript, leave a thumbs-up on [1].

[1] https://github.com/w3c/webauthn/issues/1255

Re: Passkeys: A shattered dream

#287

Post by pseudo0 »

dboreham wrote: post #256
kriops wrote: post #247

Earlier quoted context omitted.

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.

The signed assertion includes the clientDataJSON, which contains the origin of the relying party. Assuming the server properly validates that assertion, it should prevent the use of a phished assertion by a third party.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...

Re: Passkeys: A shattered dream

#288

Post by agwa »

hlandau wrote: post #126

I've never tried to use passkeys, but determined a while ago my hard, non-negotiable, a priori requirements which would have to be met for me to be willing to use them: 1. I can, if I choose, have a passkey in software (no hardware enclave, no captive key, no TPM) even if the security of that sucks: => Implication: I can backup and copy a passkey without restriction, e.g. putting the key material in an airgapped pass…

Firefox and Chrome display a permission dialog when a website requests attestation, and you can deny it. If you deny it, the website has no idea how your passkey is stored, allowing you to use a pure-software solution if you so desire. The website could discriminate against you for denying attestation, but note that Apple always denies attestation for passkeys, so websites intended for the general public are unlikely to discriminate against users who deny attestation.

So yes, I believe your requirements are met in practice.

Re: Passkeys: A shattered dream

#289

Post by brabel »

Spivak wrote: post #239
brabel wrote: post #191

Earlier quoted context omitted.

They shouldn't be exactly like SSH keys. With SSH keys, you can go and copy/paste your private keys on a scammer's website because they asked you nicely. People will totally do it as they don't understand what they're doing. The main thing with passkeys, and key dongles in general, is that you simply can't do that as the keys are inaccessible and you can only prove possession of a key when asked by a domain you've ex…

There's a big difference between "can't just hit the copy button and paste in the key" and "can't export the key as part of a backup." Physically preventing users from ever accessing their own keys is an absurd user-hostile proposition. Even more absurd when the they're software keys stored in a database the user can decrypt. The FIDO alliance is just ensuring that password managers will require 3rd party backup tool…

Any security solution that involves lay people having access to keys is NOT secure. What you call "absurd user-hostile" is actually basic security in the real world with non-technical people.

Technical people can already be secure using appropriate protections, but even for them it's very difficult to do it properly.

Lay people will, without understanding what they're doing, ask the password manager to give them their password to enter manually on any phishing website as they'll think that it's not working because it's "broken". So , absolutely no, password managers do NOT prevent phishing.

If you think I am exaggerating, well, I work with this and I assure you it's even worse than that.

Re: Passkeys: A shattered dream

#290

Post by sevanteri »

jdiff wrote: post #278
sevanteri wrote: post #26

Earlier quoted context omitted.

This is why services need to support multiple passkeys per user just like they should support multiple 2FA methods...

Do they typically not? My only contact with passkeys has been the 2FA service (Duo) at my place of work, and I've got a passkey on my phone and laptop, as well as OTP push notifications, OTP SMS, or recovery code from IT. It's particularly handy with the Chromeboxes hooked into the big presentation displays since I can scan a QR code with my phone to use the passkey stashed inside it.

Slightly poor wording from me maybe. There have been cases where for example only one hardware key could be set up but other methods were available at the same time.

I remember AWS having some weird choices at some point too, not sure how they are currently.

But yeah, typically I think most services have had multiple choises available at the same time.

Post reply on HN