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

741–750 of 789 posts

Re: Passkeys: A shattered dream

#741

Post by psd1 »

torstenvl wrote: post #462
dfabulich wrote: post #366

Earlier quoted context omitted.

People keep trying to answer this question, so I'll try, too, but I'm going to do a better job than anyone else. ;-) Passkeys are randomly generated passwords that are required to be managed by a password manager. All the major password managers support them, including Apple, Google, Microsoft, Mozilla, and 1Password. By requiring the passkey to be managed by a password manager, you get some anti-phishing protection.…

> there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy This is a deep, fundamental flaw in passkeys. It's just another example of enshittification disguised as denying end-user control "for their own good." There is no for-profit organization anywhere that I trust more than I trust myself, and there's no threat model where it's more likely I'll be socially engi…

Good for you; I'm ashamed to say that I've hurt my data sanctity far more than any criminal has, with 2am tinkering with my systems.

I have vaultwarden at home but I don't use it because I just know I'll fuck up my tunnel while I'm travelling or something.

This is my threat model: "hi mum. I need you to drive to my house and fish a keyboard out of the cupboard. Plug it into the big black box and type exactly what I tell you..."

Re: Passkeys: A shattered dream

#742

Post by jiggawatts »

jhasse wrote: post #699
jiggawatts wrote: post #547

Earlier quoted context omitted.

I’m sorry, but you’re either naive or lying. This is precisely like the imaging standards trying to replace JPG. After two decades of vendors like Google trying to establish a new standard, I can’t send anything other than an SDR sRGB JPEG to anyone, especially to an Android user. The current post-JPG formats may as well be called “the Apple format”, “Google image”, and “Netflix pics”. There is no practical interoper…

> This is precisely like the imaging standards trying to replace JPG. After two decades of vendors like Google trying to establish a new standard, I can’t send anything other than an SDR sRGB JPEG to anyone, especially to an Android user. Android supports WebP since Android 4, HEIF since Android 8 and AVIF since Android 14. They are only missing JPEG XL, but to my knowledge neither iOS nor Windows support that format…

Having a library in the OS and actual interoperability are vastly different things. Not only do most consumer chat apps completely disregard HDR, but even worse, sending HDR images via almost any such channel has a high chance of the colours being mangled or -- at best -- silently converted to 8-bit SDR.

"Ultra HDR is amazing, but can be only viewed as such only on a Pixel phone. If I'm sending a pic to say FB Messenger it doesn't upload as Ultra HDR." https://www.reddit.com/r/GooglePixel/comments/17n0fkh/ultra_...

Also, unlike Apple iPhone users, people with Android phones tend to get stuck on older major versions and can't upgrade. Easily half of all Android phones out in the wild can't correctly tone map or display either wide-gamut or HDR still images.

You mentioned Android 4 and 8, but full support for wide-gamut (Display P3 and Rec.2020) was only supported starting with Android 14: https://source.android.com/docs/core/camera/wide-gamut

Android 8.1 was the first version to introduce any display colour management at all, which was in late 2017: https://source.android.com/docs/core/display/color-mgmt

As recently as May 2019, there were Android developers blog articles with titled "Wide Color Photos Are Coming to Android": https://android-developers.googleblog.com/2019/05/wide-color...

Similarly, mixed SDR and HDR content (i.e.: not just a full screen Netflix-style app) was supported only since Android 13: https://source.android.com/docs/core/display/mixed-sdr-hdr

Re: Passkeys: A shattered dream

#743

Post by calaverainfo »

sholladay wrote: post #696
calaverainfo wrote: post #625

Earlier quoted context omitted.

Number 2 is not true. I have a Yubikey and it can't be used on Android without a Google made app or account. It's always the same story, give a plausible option to seem open or neutral, but make sure there are "details" that establishes chain of consequences preventing it that is weird enough to allow denying intention. Even though I'm not that young I thought I just need to wait for Firefox to implement it, but as t…

I was able to log in to GitHub using a Yubikey on my Pixel without a special app. Check whether your Yubikey supports resident keys (aka discoverable credentials) and whether the FIDO key for your account was created with residentKey: true, otherwise it’s a completely different (older) flow under the hood, where the private key actually gets sent to the server, and it wouldn’t surprise me if that’s the underlying cau…

Thanks for trying to help but I really meant it can't be done, not that it doesn't work for me. This is the starting point for understanding why https://bugzilla.mozilla.org/show_bug.cgi?id=1678045 but that rabbit hole is pretty deep if you want to understand the whole web of consequences.

Re: Passkeys: A shattered dream

#744

Post by calaverainfo »

matheusmoreira wrote: post #635
calaverainfo wrote: post #625

Earlier quoted context omitted.

Number 2 is not true. I have a Yubikey and it can't be used on Android without a Google made app or account. It's always the same story, give a plausible option to seem open or neutral, but make sure there are "details" that establishes chain of consequences preventing it that is weird enough to allow denying intention. Even though I'm not that young I thought I just need to wait for Firefox to implement it, but as t…

Wow. I just bought a couple of new YubiKeys for the OpenPGP Curve25519 support. I was looking forward to using the NFC feature with my Android phone. Is it just a Chrome problem? I downloaded some OpenPGP app from fdroid and it says it supports NFC keys.

I'm not sure about your exact situation, lot of the scenarios are OK, just the one without Google services which are dependent on Google account doesn't work. That is actually irrelevant for "normal" phone users that are logged to Google all the time anyway.

Re: Passkeys: A shattered dream

#745

Post by xescure »

mrinterweb wrote: post #549
shepherdjerred wrote: post #325

Here's my opposing view: I love Passkeys. I use Firefox as my browser and 1Password as my password manager. On my iPhone, I use 1Password + Firefox. I look at https://passkeys.directory/ every so often and switch my logins from passwords to passkeys. This has included a lot of my common logins like GitHub, Google, and Microsoft. There is a lot of confusing terminology. For some reason sites will say "login with Touch…

Also a 1Password passkey user. It is the most portable implementation of passkeys I've used. Still, if you want portability with passkeys you have to trust some company to sync them. I don't want to need to rely on Google, Apple, or Microsoft to sync my keys because those platforms all have some lock-in. Guess 1Password is a form of vendor lock-in too, but it is one I don't mind. I don't think we should consider pass…

What about selfhosting Bitwarden?

Re: Passkeys: A shattered dream

#746

Post by remram »

shepherdjerred wrote: post #325

Here's my opposing view: I love Passkeys. I use Firefox as my browser and 1Password as my password manager. On my iPhone, I use 1Password + Firefox. I look at https://passkeys.directory/ every so often and switch my logins from passwords to passkeys. This has included a lot of my common logins like GitHub, Google, and Microsoft. There is a lot of confusing terminology. For some reason sites will say "login with Touch…

> It would be inconvenient if I needed to login to a shared computer

Ok, I'll bite. Anyone knows how this would be done in that setup?

"Can't" is a deal breaker, so is "use the password you had to generate and store in your manager anyway".

Re: Passkeys: A shattered dream

#747

Post by random2021 »

lll-o-lll wrote: post #183
wiktor-k wrote: post #156

Earlier quoted context omitted.

Linux most definitely has a TPM interface, it's called /dev/tpmrm0 and plenty of libraries for accessing it (eg. https://github.com/parallaxsecond/rust-tss-esapi/ full disclosure: I'm co-maintaining it). Systemd is not needed for that.

So where are things falling down? I seem to be unable to get passkeys to work in linux; Chrome or Firefox. I’m suspecting the issue is something to do with bluetooth.

https://alfioemanuele.io/dev/2024/01/31/a-vision-for-passkey...

Re: Passkeys: A shattered dream

#748

Post by random2021 »

wiktor-k wrote: post #156
test20201 wrote: post #119

Earlier quoted context omitted.

It is because desktop linux does not have passkey interface built into the OS. There needs to be TPM, systemd, etc need to talk altogether.

Linux most definitely has a TPM interface, it's called /dev/tpmrm0 and plenty of libraries for accessing it (eg. https://github.com/parallaxsecond/rust-tss-esapi/ full disclosure: I'm co-maintaining it). Systemd is not needed for that.

IIRC, all these hardware exist. Software is not 100 % fine for them. The point is to have OS and password manager trust each other. Once this is done then all should work. That should allow for the browser to query the password manager for appropriate info. At the moment, password manager is poorly integrated onto OS.

Re: Passkeys: A shattered dream

#749

Post by lima »

TacticalCoder wrote: post #248
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…

> I can backup and copy a passkey without restriction ... We were so very nearly there with U2F... I did extensive testing and you can have a U2F (Fido2/webauthn) device deriving it's private keys, never leaving the device's HSM, from a BIP-44/BIP-39 seed. You write 12, 18 or 24 words down (out of a dictionary of 2048 words) and with these words, you can always reinitialize another Ledger Nano (a cryptocurrency hardw…

Why would the U2F-on-Ledger route stop working?

Re: Passkeys: A shattered dream

#750

Post by red_admiral »

Xelynega wrote: post #465
red_admiral wrote: post #416

Earlier quoted context omitted.

I'm assuming tech people would also like to know that a passkey is not just "a really long password" but also one that's never sent to the server directly - instead it's used in a challenge/response protocol (like SSH keys). Which requires software, either the browser or an external password manager, to run. I think that's what you're getting at in paragraph 3? There's no reason you couldn't have an open source passk…

It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves. The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was creat…

It feels ... suspicious ... to me that in 2024, we're designing a new authentication scheme explicitly around resident keys, but challenge-response is optional. Credentials in any new protocol should never be sent over the wire, period.
Post reply on HN