Live data from Hacker News

Passkeys: A shattered dream

fy.blackhats.net.au

391–400 of 789 posts

Re: Passkeys: A shattered dream

#391
post #201

Earlier quoted context omitted.

> I want to still use a username/password and the Yubikey. Why?

Because of the whole "multi-factor" thing, and not making account recovery impossible? Passkeys are always going to be less secure than username + password + Webauthn, why would you intentionally make your account less secure and give yourself a massive failure mode in the process?

Account recovery is a separate issue. There's nothing about a pass key that makes account recovery any harder or easier than if someone loses their MFA TOTP device or forgets their password.

Re: Passkeys: A shattered dream

#392

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…

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

Do you know if there an open source self-hosted implementation available?

Re: Passkeys: A shattered dream

#393

Earlier quoted context omitted.

That's assuming the user does have a strong passphrase to protect their local password safe and the device wasn't compromised while the password safe was in an unlocked state. If an attacker managed to get root on my machine right now, they'd get my whole password safe as its currently decrypted and in memory. However, they wouldn't be able to access any of my passkeys.

And if they get the passkey's private key, when you're signing some ticket to send off to prove identity? That has to be unlocked for that too, it's in memory somewhere. Then they privilege escalate, lock out all your other devices after adding a new one, it's the same issue. And it's opaque, reinforces the ideas that users are too stupid to do anything right, so that we shouldn't even try.

> That has to be unlocked for that too, it's in memory somewhere.

Its in-memory on my physical hardware token or a TPM or a secure-enclave, which only activates and unlocks after a valid identity challenge (fingerprint, physical touch, face scan, pin, etc.) not my main system's userspace memory. A massively different target.

Re: Passkeys: A shattered dream

#394

Earlier quoted context omitted.

> But they don't have the right to extract something from your brain. Most folks store passwords in password managers and don't use their brains to retrieve them.

password managers are growing, but I'm not sure that 'most' people use them. Maybe 'most' software engineers or techies, but the average person probably has no idea what a password manager is.

>”the average person probably has no idea what a password manager is.”

In my experience, that’s a notebook or piece of scrap paper next to the PC with all their usernames and passwords scribbled on it.

That being said, all of the friends and extended family members that I have helped with computer issues have chosen to save several passwords in their browser’s autofill. Yet, none of them knew that they could view and edit these passwords.

Re: Passkeys: A shattered dream

#395
I don't trust passkeys, and yet so far, I'm not bothered by them. This is because I use them as an additional way to log in.

The other day I noticed that for some reason GitHub couldn't seem to find my Android passkey. Weird. So I logged in using my Yubikey and recreated it.

But this would be a lot worse if it were your only way of logging in. Always have multiple authentication methods for important accounts.

Re: Passkeys: A shattered dream

#396

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…

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…

How do you back up the private key? With ssh I know to back up .ssh with the rest of my home folder. With a passkey I'd have no idea where it was, and get the feeling the "modern" software won't tell me on purpose, so that it can manage/sync it for me. Which leads to a lack of a mental model.

Re: Passkeys: A shattered dream

#397

Every time I see a long inscrutable discussion about Passkeys, I see a weird avoidance of the "something you know" part of security. Here in the US, courts and law enforcement have every right to get your username, fingerprint, retina scan, face ID, whatever. But they don't have the right to extract something from your brain. Unless I'm missing something basic (which at this point, I don't think is my fault since thi…

Keys can require a pin (or maybe a password depending on implementation). But in general I haven't felt these are secure enough for the reason you say. While my practical threat model today would make passkeys seem great, the theoretical future threat model in my head does not support it.

PINs and passwords on HSM keys like this are typically very secure as they will wipe themselves or at least lock themselves after a small number of failed attempts. For example if you only allow 5 failed attempts a 4 digit random PIN has a 0.05% chance of being guessed and a 6 digit PIN is 0.0005%.

So the only real risk is key extraction, hardware key extraction is always possible but likely incredibly expensive, so for most threat models it is not an issue. (Software key extraction or side channels is a different problem which may be easier but in theory is not possible.)

Re: Passkeys: A shattered dream

#398

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

Do you know if there an open source self-hosted implementation available?

Bitwarden, which you can self-host (I do this) seems to have at least partial support now, and I know they're working on improving it. However, I'm not sure if their client and server are both fully FOSS.

Re: Passkeys: A shattered dream

#399

Earlier quoted context omitted.

password managers are growing, but I'm not sure that 'most' people use them. Maybe 'most' software engineers or techies, but the average person probably has no idea what a password manager is.

They may not know the name of a password manager, but many may know their iPhone remembers and fills in passwords.

Same goes for Chrome and Firefox on all platforms

Re: Passkeys: A shattered dream

#400
post #207

Usernameless always seemed like an optimization too far to me. I think it's totally reasonable, and probably a good thing for users having to use their username at login. Especially as it reminds them what username they are using for that service. I could totally see a situation where a user uses a Usernameless passkey for years to access a service and for some reason loses access to the Usernameless passkey, and the…

> Usernameless always seemed like an optimization too far to me. I think it depends on the service. But aside from the occasional forum or social site, usernames are just an extra step. I don’t want or need one for banking/administration/ordering a product. For better or worse, email is usually a better identifier, assuming you already need one for other reasons (like you say recovery is typically needed). > Especial…

Or you can just use a verified email as a username...
Post reply on HN