Earlier quoted context omitted.
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…
>2) In the second case when one service is breached you'd still have to manage rotation of public key somehow Why would you need to rotate your keys? If they're storing passwords/hashes it makes sense to rotate because they might be able to brute force the hashes on a GPU cluster, but you're not going to be able to brute force a randomly generated public key.
Passkeys: A shattered dream
291–300 of 789 posts
Re: Passkeys: A shattered dream
#292Oof, the Passkeys ecosystem is incredibly complex. Even as someone that deals with it day in and day out at $CURRENT_CO, it can be a headache. As an exercise from a developer's perspective, try creating a chart of every device type (mobile, desktop etc), browser, and Passkeys platform provider (Apple, Microsoft etc). Then fill out how each behaves across each combination, it is a nightmare! I'm hopeful that we'll see…
I am exploring this now, actually got 2 students doing their thesis on this. It's very complicated and unnecessarily so. My conclusion so far is that it's a promising technology, but no way as mature as I'd like it to be. Unfortunately we are stuck with emails and passwords for the foreseeable future, at least as a back-up mechanism for credentials recovery, which, funnily, makes the whole thing pretty much pointless…
You have to beat email/password with optional password manager (syncing, remembering , autofilling) and optional MFA (physical proof)
passkeys cant beat that in any area because they have no goals
Re: Passkeys: A shattered dream
#293Earlier 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.
> With passkeys it's literally impossible. I dunno about you. But I like being able to get my passwords out of the password manager. How is not being able to do so a feature?
Re: Passkeys: A shattered dream
#294Earlier quoted context omitted.
> I’ve avoided passkeys so far because I just don’t have a good mental model of them. OK, so the simplest way to understand is to first know about the previous generation. U2F keys are designed to be used alongside a username and password, as a more secure replacement for phone apps showing 6-digit codes. In U2F the key has a hardware 'secure element' where secrets can't be extracted, even if you plug it into a compr…
> "and use fingerprint/faceid instead of a password" This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now? Security guru Bruce Schneier has written about this w/ much more eloquence and authority.
Re: Passkeys: A shattered dream
#295Re: Passkeys: A shattered dream
#296I’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…
You can store passkeys in a password manager as well: https://1password.com/product/passkeys The super simple explanation is: SSH keys for websites. You have a unique private key for each website account stored on your device, in a local password manager, or in a cloud synced password manager (iCloud account, Google account, 1Password, etc). The website only gets the public key, so unlike password auth your secret is…
First, I had to figure out how to get the website to request the passkey. Then I had to figure out that I didn't want to use the browser's passkey but 1Password's, which is different on different browsers and platforms. And good luck if I'm on mobile, I don't think it's ever worked.
At this point I'm taking a break from signing up new passkeys. I'll stick to UN+PW+(TOTP|Yubikeys).
PS: Why is it that no financial institution lets you use anything more than a SMS U2F?
Re: Passkeys: A shattered dream
#297I’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…
You can store passkeys in a password manager as well: https://1password.com/product/passkeys The super simple explanation is: SSH keys for websites. You have a unique private key for each website account stored on your device, in a local password manager, or in a cloud synced password manager (iCloud account, Google account, 1Password, etc). The website only gets the public key, so unlike password auth your secret is…
Passkeys are great for consumers who use one or two devices (or browsers - I also switch browsers frequently). For anyone with more than one platform or one device in their lives they suddenly become added complexity, because even though you _can_ have more than one passkey per account per service, in practice there are all sorts of weird edge cases.
They're just not mature yet, period.
Re: Passkeys: A shattered dream
#298Earlier quoted context omitted.
> "and use fingerprint/faceid instead of a password" This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now? Security guru Bruce Schneier has written about this w/ much more eloquence and authority.
The unstated value of a USB key is the functional similarity to metal keys for ordinary people.
Re: Passkeys: A shattered dream
#299Earlier quoted context omitted.
> I’ve avoided passkeys so far because I just don’t have a good mental model of them. OK, so the simplest way to understand is to first know about the previous generation. U2F keys are designed to be used alongside a username and password, as a more secure replacement for phone apps showing 6-digit codes. In U2F the key has a hardware 'secure element' where secrets can't be extracted, even if you plug it into a compr…
> "and use fingerprint/faceid instead of a password" This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now? Security guru Bruce Schneier has written about this w/ much more eloquence and authority.
Think an SSH key protected by a passphrase. Your passphrase isn't the thing that actually logs you into the server, its just what you use to unlock your actual key material you use in your SSH handshake. Your fingerprint/face identity is just your local unlock of the actual key material stored in some other secure enclave.
Re: Passkeys: A shattered dream
#300Earlier quoted context omitted.
The risk of your password getting stolen in between your browser and whatever hash algorithm the service you're authenticating with puts your password through before storing/verifying it. That's the benefit you get from passkeys that no password manager will otherwise be able to give you.
If they control the information flow can't they simply steal the passkey too?
Passkeys use public-key authentication wherein the server only stores the public half of a keypair and the client authenticates by correctly signing a challenge sent by the server, which the server then verifies using the public key.
At no point is the private key ever sent over the network or otherwise exposed to any infrastructure or code controlled by the server.