this post was submitted on 09 Apr 2024
503 points (92.7% liked)
Technology
59534 readers
3183 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Better yet: use a hardware 2FA token that supports passkeys
The issue is that most of them are limited in the amount of passkeys they can manage.
In the case of the Yubikey 5
It depends on the passkey type (resident vs non-resident keys)
Right, now I remember reading about that, I forgot.
Passkey = Resident Key
Nonresident keys are not passkeys, they are solely a second form of authentication meaning the service you are logging into still requires a password.
Couldn't a site theoretically use a nonresident key with just a username, in place of a password?
This seems to imply it might be possible:
https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/Resident_Keys.html
For sure, but that still isn't a passkey. The method you are talking about is the equivalent of non-passphrase protected SSH protocol, which is a single form of authentication (i.e. if someone has your security key they have your account).
The term passkey implies MFA: having a physical key and a password, a physical key and a fingerprint scan, or equivalent.
Sure the username could be considered the password, but usernames are not designed to be protected the same way. For example, they typically are stored in clear text in a services database, so one databreach and it's over.
How is 25 bad? Do you need a passkey for each service /app/website? Can't you use the same key for many services? (trying to understand how they work)
Yes, you need a passkey per service, so you would quickly end up with your 25 slots full.
Ideally yes, they're supposed to eventually replace all passwords. Of which I have hundreds. And yes not 100% of them will do that on the near future but a lot more than 25 will.
/aparté: being downvoted for trying to understand gives me reddit vibes well done
Being down-voted for asking questions is bullshit. Your questions are valid and those people suck.
I have 150 passwords in my password manager. I’m not buying 7 YubiKeys (and to be fair that’s not what they’re designated for)
No, sharing passkeys across services is way too risky. One service gets compromised, someone gets your passkey, and then they have access to all of your services. It's the same principle with regular passwords.
Uh, each service only has access to your public key, not the private one that stays with you. It's less risky than a regular password.
Even with U2F hardware keys where the server-side stores the encrypted key (to allow for infinite sites to be used with a single hardware key), it's only decryptable on your key and thus isn't that useful for someone who has compromised a service.
Thanks. I'm still learning about this "new" technology (which already is, what, eight years?)
It started with U2F which may be older?
Having a key shared across sites wouldn’t be great. If it was great it would be an article talking about “passkey” not “passkeys” because you would just have one. Like some sort of Skeleton Passkey that unlocks all your shit when compromised.
That's impossible. Passkeys were designed specifically to be impossible to share across different websites.
Well, that’s basically my point. It’s not a good idea.
Thank you ; I misunderstood that one passkey could be like a fingerprint sort of
You only need one per website if you want it to autofill the username, because resident keys held on the security token can be recognized and suggested automatically but otherwise you must first enter your username on the website and let the website send its challenge value for the corresponding domain and account pair so that your security token can respond correctly.
Eh... That's not exactly a silver bullet or necessarily "way better"; it's got a lot of usability issues.
You really only want to do that for your most important sites and then you want to use multiple passkeys to make sure you retain access.