Ancestors

Written by Nina "Erina" Satragno 💫 on 2024-10-23 at 22:01

"#Passkeys are useless to me because I use a fancy password manager and always look at the URL".

Yes but the other users of the site don't so you also have to pay the shitty 2fa tax like everyone else.

Also I promise you you can get phished.

=> More informations about this toot | More toots from nsa@hachyderm.io

Written by gigantos on 2024-10-24 at 05:34

@nsa I just wish they fixed the usability flaws in the spec.

For example:

• there is no way to check if a user has a passkey and let the user log in with it seamlessly. To check, the user will get a popup and be asked for verification, and then shown an empty list if none is available.

• there is no standard way to annotate the passkeys in a good way, so when you open the security settings on the server, you just get a list of passkeys with very little information per entry.

• passkeys never expire, so if you get the opportunity to add one to some users account, they are backdoored "forever"

• if a website loses your passkey, a new one can't be created until you also delete the existing one on the client

• there is no way to sync across ecosystems, passkeys is the perfect vendor-lockin scheme, and will benefit Google and Apple for decades to come

With that said, passkeys beat passwords every time, and I still want them to win

=> More informations about this toot | More toots from gigantos@social.linux.pizza

Written by canard164 on 2024-10-24 at 12:00

@gigantos

Your first point raises privacy issues. If I do not want to be identified, for a given session, by the service on which I have a passkey for other use cases, it should not be forced against my will. I think passkeys are properly designed on this aspect. It's a little bit inconvenient but in user’s interest overall.

Regarding sync, this is false. You can perfectly sync across ecosystems with third-party passkey managers. If it’s not available yet on all your systems, it will be.

@nsa

=> More informations about this toot | More toots from canard164@mastodon.social

Written by gigantos on 2024-10-24 at 16:08

@canard164 @nsa I think it doesn't have to be a privacy issue. It should be possible to cause the call in javascript to behave as if the user got an empty popup and clicked cancel. It is already possible for a website to request the passkey without asking the user first, it just leads to a popup for biometry and then an empty list after.

I don't know how to solve it, but I think it hurts passkey adoption.

As for the sync, I was under the impression all passkeys on iphone are tied to the Apple keychain. And if you wanted to switch to a non-apple device, you need to re-create all your passkeys.

On MacOs you can install a browser plugin on Chrome, so there is that.

So currently there is no way for me to have a passkey provider that supports sync and runs on all my devices (Windows, Mac, ipad, android, Linux).

And even if there was, my argument was that there is no sync as part of the standard, and almost all users will do whatever is standard. So the vendor lock-in is definitely real.

=> More informations about this toot | More toots from gigantos@social.linux.pizza

Written by canard164 on 2024-10-24 at 16:57

@gigantos

I do not know Apple ecosystem but I think that Bitwarden and Proton Pass are available on all platforms. I thought it would work; maybe something is still missing on Apple’s side to allow third-party passkeys managers. KeePass-compatible apps will come too.

Anyway there is nothing in passkeys intrinsically that make them lock users to a specific vendor. Only (bad) vendors implementations are locking users.

@nsa

=> More informations about this toot | More toots from canard164@mastodon.social

Written by gigantos on 2024-10-24 at 17:12

@canard164 @nsa my issue is that there is nothing in the standard to require it. And that lets Apple run their own locked down ecosystem. And with more than 50% of the market, that is a significant negative.

To my knowledge Apple does not plan to allow third party providers

=> More informations about this toot | More toots from gigantos@social.linux.pizza

Toot

Written by canard164 on 2024-10-24 at 19:33

@gigantos

I’m not convinced that such things should be part of tech standards.

This can be tackled by policies such as the EU requiring a standard USB-C charging cable.

But the best situation would be to avoid using such vendors in the first place. It’s not as it’s their first time doing it.

The tech standard is not to blame. The vendor is to blame for its unreasonably bad practises against its customers’ interests.

@nsa

=> More informations about this toot | More toots from canard164@mastodon.social

Descendants

Written by gigantos on 2024-10-24 at 20:17

@canard164 @nsa perhaps, but I still think the point stands. It is a negative for passkeys that it makes vendor lock-in much easier than before. And it will happen without users understanding that it is happening.

Password managers are used by a few people, and many of them are fairly technical.

Passkeys, if they work out, will be used by everyone, and most without them realizing it. All they do is enable "biometric login", which is the term used by most websites instead of passkeys.

I don't pretend to have a solution to this problem, and making one that doesn't also open the door for phishing may be hard. The whole point of passkeys is to make it impossible for someone to phish the private key after all.

=> More informations about this toot | More toots from gigantos@social.linux.pizza