- cross-posted to:
- news@lemmy.linuxuserspace.show
- cross-posted to:
- news@lemmy.linuxuserspace.show
You must log in or register to comment.
Missed opportunity for “What the eff is a Passkey?”
That is truly amazing. (Golf clap)
Someone on slashdot correctly pointed out that these are only single factor on the server end. You enter a pin to unlock the device, the server can check if the device says you unlocked it, but there is no sending a second factor to the server. If a device was hacked to get the keys, or just says to the server that you presented a pin but didn’t really, the server has no clue. Passkey + TOTP would be multi factor on the server side.
TOTP generated on the same device as the passkey is not a secondary factor. It will have been compromised together with the passkey.
For passkeys, the secondary factors are used to access the passkey vault, not auth to the server. And these secondary factors should be a master password, biometrics, or physical keys. TOTP and SMS are out.
I understand how it works, but again, it is not two factors being used to authenticate to the server.
It is a single factor being used to access the vault. The server has no way of confirming this actually happened, the device just tells the server it has happened. A single factor is then used for authentication. This seems especially worth knowing since most cell phones deliberately weaken the security by sharing them between devices.
Passkeys would preferably not be stored on the same device as a secondary factor used for authentication. Hardware tokens have supported them for years at this point, they can also hold TOTP keys instead.
I’m not sure I follow you - if someone can compromise the key material on my phone that is protected by a different factor, then it doesn’t matter whether the 2FA is server-side or not, it’s compromised either way.
If they compromise key material on your phone they still cannot get into whatever you are authenticating to, because it uses a completely separate factor that should not be on your phone.
It seems like you are trying to protect against a compromise of the user’s device. But if their device is compromised then their session is compromised after auth anyway and you aren’t solving much with extra auth factors.
You’re assuming that the passkey is on their phone and the phone is compromised. Passkeys can also be stored in password managers, or hardware tokens, or people’s iCloud or Google accounts. And if someone’s device is compromised, they have keys to everything even if the user never logs into those services to grab session data. If someone compromises my password vault they get passwords, but not TOTP keys. If they compromise my vault that is holding passkeys, that is all they need.
I am only pointing out that a single factor is all that is sent to the sever, with most no longer allowing a secondary factor for authentication, and all of the security is all dependent on the client-side now.
Passkeys are indeed only the first factor. A second factor could be a(n unrelated) password, or raw biometric data.
The traditional authentication factors (something you know, something you have, something you are) still work like they used to. Passkeys use the “something you have” factor by default.
The “something you are” factor (biometrics) isn’t commonly used, because most services actually use a stored secret that gets unlocked through biometric rather than biometrics data directly; any fingerprint login is just a public/private key in implementation, except the hardware is supposed to not use that key unless the biometrics sensor validates you.
Theoretically you could achieve the same factor as passkeys by logging in through username + TOTP code, because TOTP codes are only supposed to be generated on a dedicated device you have.
With some implementations of passkeys, the factor becomes a bit ambiguous. For example, a synchronised passkey behind just a password might as well be a password, albeit for a different service.
For traditional passkey storage (a TPM, a Yubikey), this isn’t a problem of course.
This is where PAKE algorithms for secure password checks fits in
The second factor doesn’t necessarily exist, since you’ve moved all of that to the client side now. It entirely depends on implementation and that the implementation is done correctly and is honest. The server only knows that you have the key, it’s single factor authentication.
In the past, it verifies that I know the password and that I have a key on the server side through separate challenges.
It’s still way better than username / password, it just has new (more difficult) vulnerabilities.
Passkey plus TOTP doesn’t really make sense (they’re both client side cryptographic keys, you don’t need two protocols), at least use a PAKE algorithm with a PIN instead if you want the server to be able to check the user’s knowledge of a secret without sending it in a readable form
Damn I was wondering exactly that a few days ago. Once again lovely job from eff to clarify here.
You’re still entering the password or pin for your password manager. I genuinely do not see how this is better. It’s simply an alternative, not an improvement.
-
Password managers are, generally speaking, far more security conscious than the average website. I’d rather send a password to my password manager a couple times a day than send passwords to every website I interact with.
-
One click to confirm vs. 2-3 to autofill. Tiny gains in speed 🤷♀️ If you make a password manager even slightly more convenient than just using
gregspassword123for everything, you can onboard more normies.
But does their advantage in security overcome the fact that they’re a much larger target?
It’s similar to how money under a pillow could be safer than money in the bank; depending on who you are.
In general, yes. Big sites get hacked all the time. Passwords from those sites get cracked all the time. Anyone who uses the same password on multiple sites is almost guaranteed to have that password stolen and associated with a username/email at some point, which goes on a list to try on banks, paypal, etc.
Conversely, to my knowledge, there has been one major security breach at a password manager, LastPass, and the thieves got more-or-less useless encrypted passwords. The only casualty, at least known so far, is people who used Lastpass to store crypto wallet seed phrases in plaintext, who signed up before 2018 when the more secure master password requirements were put in effect, chose an insecure master password, and never changed it once in the four years prior to the breach.
It’s not perfect, but the record is lightyears better.
Put it this way: Without a password manager, you’re gambling that zero sites, out of every single site you sign on to, ever gets hacked. From facebook, google, netflix, paypal, your bank, your lemmy or mastodon instances, all the way down to the funny little mom-n-pop hobby fansite you signed up for 20 years ago that hasn’t updated their password hashing functions since they opened it. With a password manager, you’re gambling that that one site doesn’t get hacked, a site whose sole job is not to get hacked and to stay on the forefront of security.
(Also, you don’t even have to use their central servers; services like BitWarden let you keep your password record locally if you prefer, so with a bit of setup, the gamble becomes zero sites)
I use a different password for every site tho. Using same pw for every site, that’s another extreme entirely.
Most people do not. The average user has one or two passwords, and maybe swaps out letters for numbers when the site forces them to. Because remembering dozens of passwords is hard. If you, personally, can remember dozens of secure passwords, you’re some kind of prodigy and the use-case for a password manager doesn’t apply to you, but it still applies to the majority.
One doesn’t have to remember dozens. Just a basic algorithm for deriving it from the name of the site. Complex enough that it’s not obvious looking at a couple passwords but easy to remember.
This method works for me. I understand its dangers (can still correlate. Dozen passwords and figure out the algo). But it’s my current approach. I hate even discussing it since obscurity helps.
Your system is most likely way less secure than you think. I mean, possibly not since you’re here, but most schemes are trivial to solve even automatically.
…and that doesn’t really matter either, because so many people have such shitty passwords (and use the same ones everywhere) that noone really bothers checking for permutations when they have thousands of valid accounts.
But if truly enough people are convinced to be more secure your scheme may eventually become a target, too.
With passkeys (and password managers in general) the security gets so good that the vast majority of current attacks on passeord protection get obsolete.
Okay, I’m glad you have a system, but it’s not really relevant? I didn’t say you should use a password manager. I said it’s good for the majority of people who can only remember one or two passwords.
Most people that have password managers are already using different passwords for each website. Usually randomly generated. What’s the difference between that and a passkey?
The secret key pair of a passkey is never transmitted over the internet. Even if somebody snoops the authentication, they will not be able to reproduce the secret key to login in the future.
Think of it just like SSH public and private keys.
Normal passwords, are typically provided at login time, and get transmitted, relying on HTTPS to keep them secure, if somebody could observe the authentication, they could reproduce the password later.
(Yes someone could hash the password client side and send over the output… But that’s extra work and not guaranteed)
Client side hashing of a password just makes the hashed result the password, as far as security is concerned.
Unless there is some back-and-forth with the server providing a one-time-use salt or something to make each submission of the password unique and only valid once, at which point that might get snooped as well.
Better off relying on client certificates if you are that concernedPasskey’s approach is actually relatively close to client side certificates. It’s just in a form that is compatible with using a password manager. From the user standpoint once everything supports it properly, logins become relatively transparent and man-in-the-middle is pretty effectively mitigated. The other upside is of course unless you’re hosting your own stuff, no one supports client side certificates. This is an opportunity for all the big players to actually push people into better security.
Ah, thanks for that explanation. That makes sense. Eliminates a possible attack vector with https
Passkeys use cryptographic keys held client side which are never transmitted, they user cryptographic challenge-response protocols and send a single use value back. You can’t intercept and reuse it unlike with passwords.
A pass key is the private key in a private/public key pair. The private key is stored in the TPM on your device. The website contains the public key. When you use your “one password” you’re in effect giving your device permission to access the key storage in your TPM to fetch the private key to present it to the site.
What this means in practice is that if a website has a data breach they won’t have your hashed password, only your public key which… is public. It doesn’t and can’t do anything on its own. It needs the private key, which again only you have and the website doesn’t store, to do anything at all.
If you want to read more about it look into cryptographic key pairs. Pretty neat how they work.
When you use your “one password” you’re in effect giving your device permission to access the key storage in your TPM to fetch the private key to present it to the site.
Very small correction as I understand, but your private key is never presented. The web service should never interact with the private key directly. Your device is signing some bit of data, then the server uses your public key to verify that it was signed by your private key. Its a small distinction, but is one of the principal uses of asymmetric encryption is that the public key can truly be public knowledge and given to anyone, while the private key is 100% always only accessed by you the user.
I’m not sure there’s a requirement for the TPM to be used. To me that would imply the private key is stored in the TPM so you couldn’t export it. But a lot of the passkey providers have remote sync available.
Which to implement, would mean they’re storing the key outside of the TPM, but using the local TPM to decrypt the secret stored outside of the TPM. IE the certificate payloads are decryptable by a variety of keys that are stored in different TPMs. There’s lots of assumptions here of course.
I imagine password managers won’t touch the TPM, but iPhones essentially work as you say. Apple has a lot of documentation for how they synchronize.
-
Because you don’t send a secret value, you only send a cryptographic asymmetric single use value which is safe to disclose
You’re entering your password into your password manager, which is stored by a company or entity whose entire job is to keep it secure. You’re not giving your password, in any form, to the website or service you’re accessing. When the website gets compromised, your hashed password is not in a database waiting to be cracked. All the attacker gets is a public key they can’t use for anything.
Because it’s for your website logins. It just stores the key and auto logins.
Passkeys are asymmetric, meaning that the server only ever sees your public key. If the server gets breached, then only your public key is leaked, which isn’t a big deal. Functionally, it’s almost identical to SSH keys.
Since you should use a password manager anyways, it wouldn’t make a difference if they get a randomised password or public key.
If they get your password they can impersonate you to the server. They can’t do that with just the public key part of your passkey.
I can see the “phone falls into the toilet” as a big problem that people will have.
RIP local sexpot.
something from a corporation that cannot be trusted?
Except passkeys are an Open Authentication standard from the FIDO alliance. Soooooo, not from a corporation.
https://fidoalliance.org/passkeys/
You can use passkeys in KeePassXC, if I understand correctly.
They are the equivalent of using a hardware key like YubiKey or SoloKey, except the passkey is stored on your phone/PC instead of a USB thumbstick.
still no reason to trust google with this.
they have hijacked and dominated open source software quite a bit in the past.
Except Google was only mentioned in terms of whether or not they support it.
You’re commenting on an article from the Electronic Frontier Foundation, an organization dedicated to fighting for internet and digital freedoms, about an open standard that has only just begun being implemented widely.
Look, I hate corpos as much as anyone, but please let’s please tone down the alarmism.
I’d like to thank you for providing context to reactivism based solely on an emotional reaction without doing any research first.
I am guilty of that as well, but you put effort in, explained things and that takes time. Thanks.
Then use your self-hosted Bitwarden server as a passkey instead. All open source, no code from Google.
They are fine, just ssh public private keypairs but for “the web”… worse than fido2… so not really sure why they are being pushed so much above fido2
They are FIDO2. This is the passwordless stuff yubico has been talking about and working on for ages, plus a marketing name.
Wow! I had no idea. I assumed the yubikey bioseries didn’t work with passkeys. But I read the documentation that you linked, and I just tested it out on the demo site. It works.
That’s amazing! Thanks
Can only store 25 keys but hey that’s still something.
I like that you are able to query what keys are stored, so if you are ever replacing or upgrading the key you can see where you should update to the new one. That is tough on the current yubikey, I’ve got a few generations of them and have to hold onto them just in case I happened to use them for 2FA somewhere and don’t remember it. 2FA is dynamically generated so there’s not really a way to change that, it’s just inconvenient.
I prefer the yubikey webauthn fido2 non passkey approach. It’s not limited to 25 slots. And if your key gets compromised, or you’re forced to unlock it, there isn’t a list of sites that it works on.
With passkeys, if somebody compromises you, physically, they can see everything you can log into. That makes me feel icky
There are definitely pluses and minuses. It will lock you out after 8 incorrect pins so if it came down to it, you could probably force it to lock pretty quickly.
