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

211–220 of 789 posts

Re: Passkeys: A shattered dream

#211

Post by knallfrosch »

javawizard wrote: post #143
michaelt wrote: post #127

Earlier quoted context omitted.

If you've already got a password manager, what benefit do you get from passkeys? Avoiding the risks of short, weak passwords? The risks of reusing passwords across sites? The inconvenience of remembering loads of passwords? The frustration of having to type passwords manually? The risk of getting phished or typing one site's password into a different site? Remembering and typing usernames? The password manager takes…

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?

Re: Passkeys: A shattered dream

#212

Post by arianvanp »

jchw wrote: post #152

Yeah, unfortunately passkeys are confusing and the UX is generally fucking awful. I hesitate to just blame the tech companies for being greedy, as a result of my experience with passkeys I'm starting to wonder if maybe they've legitimately just lost the skills and knowledge necessary to actually make usable software. What's most disappointing is, password managers have already solved the problem of syncing credential…

FWIW: MacOS and iOS allow third party password managers to ingrate directly into AuthenticationServices and list passkeys in the native passkey UI through a "Credential Provider" extension. And it's documented how: https://developer.apple.com/documentation/authenticationserv...

This is the same Credential Provider API they already have to integrate with to show the password autofill in iOS so there is already _some_ code for this.

1Password _could_ just integrate with the native UI. But they chose not to. This however means shipping a native app which is a lot more heavy-weight than shipping a web extension.

I opened an issue in the webauthn repo about giving an API for WebExtensions to hook into the passkey autocomplete but there hasn't been any traction or appetite for it unfortunately :(

https://github.com/w3c/webauthn/issues/1976

Re: Passkeys: A shattered dream

#213

Post by knallfrosch »

vanburen wrote: post #82

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…

There's no account recovery process for passkeys. I thought they are your identity?

Re: Passkeys: A shattered dream

#214

Post by jorvi »

PaulHoule wrote: post #175
Nextgrid wrote: post #41

Earlier quoted context omitted.

Big problem with this is that enrolling the secondary passkey requires the authenticator to be present. This is super inconvenient and risky as it always requires both authenticators to be present at the same machine/physical location, exposing both to local, physical threats (faulty USB ports on your machine frying anything you plug in? Congrats, you've now fried your main and any backup authenticators before you re…

It always struck me that 2FA is a corporate suicide pact. Some percentage of users are going to lose their keys per year so your user base is going to decay like a radioactive element.

That’s why most 2FA’s are 1.5FA by default where you can recover via SMS, delayed e-mail, etc, and you can (sometimes) only disable this by clicking through three scary screens and saving your 10 backup codes.

Re: Passkeys: A shattered dream

#215

Post by ezfe »

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…

Not reused, each service has a different key

To rotate, you go to the key management page of the service and delete/add a new key.

Re: Passkeys: A shattered dream

#216

Post by thinkharderdev »

masklinn wrote: post #171
javawizard wrote: post #143

Earlier 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 your TLS connection has been MITM’d, you have much bigger problems than your unique randomly generated password being sniffed out.

It is not required that your connection has been MITM'd. The service you are authenticating can accidentally log the plaintext password, they can store it with an insufficiently secure hash function or not salt it. A malicious browser extension can scrape it directly from the input form. Etc, etc, etc.

Passwords are reasonably secure since we've been using them for a long time but there is in fact a huge chain of trust required to keep them secure and links in that chain frequently break.

Re: Passkeys: A shattered dream

#217

Post by 4ad »

crote wrote: post #209
dwattttt wrote: post #187

Earlier quoted context omitted.

You should produce a key per device, and produce a backup key that is safely stored & not used anywhere. You can recover if you lose all devices via your break-glass backup key, and you limit the blast radius of "my key got stolen" from rotating all your keys to just a single device (or maybe the more likely "I screwed up and pushed my key somewhere public")

... which is completely nonviable if you connect to more than a single service. I agree that you should use a different key per device, but when you connect to over a dozen different services/machines it quickly starts to become a serious chore to add another key. Have fun spending an hour enrolling your new device - provided you can even remember every single usage it should be enrolled with.

SSH certificates solve this issue.

AFAIK there is no equivalent for Passkeys.

Re: Passkeys: A shattered dream

#218

Post by crote »

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 away?!

Re: Passkeys: A shattered dream

#219

Post by gruez »

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…

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

Re: Passkeys: A shattered dream

#220

Post by kmlx »

> Apple Keychain has personally wiped out all my Passkeys on three separate occasions. There are external reports we have recieved of other users who's Keychain Passkeys have been wiped just like mine.

i have been using passkeys on apple since they launched it. i have also converted all of my 2fa’s to passkeys (where supported) or enabled them as password alternatives. a lot of website support passkeys nowadays. i never encountered what the author encountered and it seems like something seriously wrong happened.

did anyone encounter this issue? is it logged somewhere?

i seriously considered dropping passwords completely for future projects, but it looks like there are still issues…

Post reply on HN