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
Toot
Written by Nina "Erina" Satragno 💫 on 2024-10-24 at 11:46
@gigantos
- Native apps can fire a passkey sign in if the user has passkeys that fails immediately if there are none with no UI. It's tricky to do on the web without impacting privacy, but we're exploring this! We know it's a problem.
- You can use the aaguid and turn that into a user friendly name. E.g. webauthn.io does this. There's a json file out there with known mappings.
1/n
=> More informations about this toot | More toots from nsa@hachyderm.io
Descendants
Written by Nina "Erina" Satragno 💫 on 2024-10-24 at 11:48
@gigantos
- I don't think this is a problem... but if you really wanted to, you could have your service create a new passkey with the same user.id and that would overwrite the previous one after some amount of time. It might be possible to use the new automatic passkey creation to do that seamlessly, and I've been toying with the idea of using the capability to allow migrating passkeys to post quantum seamlessly.
- This isn't true, the website can override the passkey.
2/n
=> More informations about this toot | More toots from nsa@hachyderm.io
Written by Nina "Erina" Satragno 💫 on 2024-10-24 at 11:52
@gigantos
- Cross vendor sync won't happen, but import and export is already being experimented with.
https://fidoalliance.org/fido-alliance-publishes-new-specifications-to-promote-user-choice-and-enhanced-ux-for-passkeys/
I obviously can't deny that the current state for this sucks.
=> More informations about this toot | More toots from nsa@hachyderm.io
Written by gigantos on 2024-10-24 at 15:54
@nsa thank you for taking the time to answer my rant. I recently experimented with implementing passkeys and this was a mix of skepticism received from others and my own experience.
- Great, hope this works out. It would make the user experience so much better.
- Nice, will look into this
- It is not a new problem, the same applies to security keys and api keys and so on. The difference with passkeys is the expected volume and technical level of the user. If almost all logins of the world are passkeys, this becomes a likely attack vector, as the old ways no longer works. I know a service could improve it for themselves, but fear many won't. Expiry is not the only solution, and I guess fixing it in the standard may be implausible
- In my testing I had to replace the private key on the server for my Macbook with Chrome to accept a new passkey for the same user. The alternative was to first delete it in the keychain. Perhaps there is another way, but it wasn't obvious to me.
- That is something at least 👍
=> More informations about this toot | More toots from gigantos@social.linux.pizza
Proxy Information
- Original URL
- gemini://mastogem.picasoft.net/thread/113362231207414343
- Status Code
- Success (20)
- Meta
text/gemini
- Capsule Response Time
- 283.625727 milliseconds
- Gemini-to-HTML Time
- 2.712879 milliseconds
This content has been proxied by September (3851b).