- cross-posted to:
- [email protected]
- technology
- [email protected]
- cross-posted to:
- [email protected]
- technology
- [email protected]
You must log in or register to comment.
If you really want passkeys, put them in a password manager you control. But don’t use a platform controlled passkey store, and be very careful with security keys.
Amazing article. Lots of great inside baseball. I’m a big proponent of hardware security keys, the whole pass key thing didn’t make sense to me. Especially the resident keys. If you user workflow is terrible, nobody is going to use them. Which is even worse than not existing
The hardware keys are great but so far don’t have enough storage. For example, Yubikey as a second factor dynamically generated its responses, but now that it’s storing them it’s very limited to at most 25. It’s a known issue that will be solved though.
Fido2 solves this already …
Passkeys are FIDO2. The issue is the tokens don’t have much storage for them. For passwordless vs use as a second factor, it has to store it instead of dynamically generating a response to a challenge. They are two features of the protocol.
While non-discoverable credentials are not considered passkeys, you should still be aware of them as there are still a number of valid scenarios where your application will need to support the use of them - especially as they are still valid WebAuthn credentials. These are credentials that cannot be generically invoked by a relying party. Instead a user will need to prompt the relying party with a username (user handle) to have the application provide a list of credential IDs to denote which credential(s) can be leveraged for authentication.
Fido2 webauthn non-discoverable credentials are completely unlimited. Because the private key is on the yubikey directly. The only downside of this, is you have to type in your username first, but I think that’s an upside personally. I do not want anybody who compels disclosure of my hardware security key, to see all the accounts on it.
Are your non-discoverable credentials also locked on the key, or can someone who knows your handle and possesses your key access your accounts? Online usernames are not well protected, I’d rather my key lock out after a few failed attempts to access it.
The non-discoverable keys cannot be removed from the device. The secret is non-transferable.
In the yubikey bio series, this is implemented as a second factor. So you log in, and then present your hardware key as a second factor. You need your fingerprint, the key, your username. Fairly secure.
I think this is a more secure model than pass keys as they’re being promoted today
Yes, but do you need to unlock your key to use it? Possession is not enough to access discoverable credentials.
You edited, but I don’t see this as significantly more secure than the Passkeys, and most keys are not the bio series (not that I trust fingerprint readers anyway).
My biggest problem with hardware keys are replacement. If I lost one of my keys and get a replacement I would now need to go to a hundred sites and enroll the new key (and remove the old one). Until this workflow is automated I can only reasonably use hardware keys with a small number of “critical” accounts.
So for 99% of sites I’m going to use a synced software key.
That is a reasonable use case for software keys, maybe the sweet spot is using a hardware key to lock your software keys.
I use passkeys stored in my proton pass app when I don’t have my yubikey next to me
ive been saying dont trust corpos on this one, and being downvoted every time.
I admit that passkeys have never made sense to me. You still have a username and password, but you’ve added a middleman who manages the password. Why not just use a password manager (without MFA, another useless annoyance)?
Passkeys are not passwords. When you authenticate using passkeys you will proof that you have the secret (passkey), but you will never reveal that secret to the service you are authentication against.
So even if someone is able to steal that package containing the answer, that answer will not be valid a second time.
I’m sorry, but this still sounds as much like “Mares eat oats” as it did when I first heard it a decade ago. You still enter a username and password somewhere (ideally in your password manager) to gain access to your account.
If you’re entering a u/p along with a passkey, then it’s MFA.
There are only a few sites I know of that do passkey correctly. CVS works wonderfully on my phone. Requires a username and then the passkey on my browser.
My company is working on a passkey only for login and it’s really really slick.
You basically click “login” and then authenticate your passkey and you’re in.
How do you authenticate your passkey?
Either with a pin or thumbprint
I must be dense. I just don’t see how that’s an improvement.
Admittedly my primary experience is with the code kiddies at my campus trying to implement Duo through a dozen redirects to Google, Microsoft, and whichever vendor platform we’re trying to login to. It’s a hot mess.
Your passkey is an encrypted message that authenticates you, the service you’re trying to reach, and your computer.
If you go to a phishing site, the passkey won’t even come up because the browser doesn’t recognize the site. Granted a dumb user could still use their user/pass but ideally the user has MFA set up so they can’t get far.
The goal of a passkey is to replace username and passwords entirely so that phishing becomes less common.
The main issue with passkeys is that unless you have something like a YubiKey or an authenticator (like bitwarden), the passkey is tied to the browser which means if the device gets lost you can’t log in anymore.
I’m going to get technical. A registered passkey is basically your phone or whatever holding a private key and the server holding the public one. When you want to log in, you enter the username on the service, which contacts wherever you registered it, and asks for a verification. Then, the device creates a nonce, which is a random number to be used once (NumberONCE), and a copy of that number encrypted with the private key. Then, the service can unencrypt the piece and check that the value is the same as the unencrypted value. This process is called a digital signature, it’s a way for online processes to verify the sender of whatever.
This way, the server knows that whoever is trying to authenticate is doing it from the authorised device. The difference between sending a signed nonce and a password, is that is someone steals the signed nonce they get nothing, since usually that number gets registered somewhere so it’s not valid again or something, it’s not exactly as explained but the point is that whatever is sent can’t be sent again. Something like a timestamp in milliseconds where it will be obvious that the signature would have expired. If an attacker captures the authentication attempt, with passwords they get the actual password and can the use it again whenever, while with nonces, they can’t.
Iirc, the server sends the device a code and the device must send the signed code back, so the service knows that the one trying to authenticate is the device. No need for passwords.
Now, if you need to authenticate to gain access to that private key, that’s of course an attack vector, so if you want any kind of syncronisation of passkeys, you need to make sure that you don’t need to send a password to get the pkeys. I use bitwarden, and unless I misunderstood, you don’t authenticate against the bitwarden server, when you access your vault they actually give you you the encrypted data, which you then unencrypt with the password locally on the browser. I’ll have to double checknon this because I have a 2fa on that for extra measure butidk how it actually works. My plan for the future is to actually use a yubikey to authenticate against bitwarden, following the same logic explained above, to then gain access to a bigger pool of passkeys. This way, ultimately all access is protected with my physical key which I can connect to most devices I use, and I can, with NFC use the key to authenticate the android bitwarden app, so it should be completely usable.
In any case, passkeys are better than passwords, provided toy don’t store them in a less secure place. As we all know, the security level of a system is the security level of its weakest cog.
It’s one of the very few things Microsoft actually gets right on their websites. You select to log in with a passkey, authenticate, optionally select which account you want to use, and you’re signed in. Not a single username or password entered into the website.
The difference is, that even if you enter the “password” on a phishing site, it is useless. Or when the server is compromised.
The only way the passkey can get compromised, is when the device that holds it gets compromised.
The same reason why hardware tokens for things like FIDO or U2F are recommended.
That makes no sense to me — and I’m not technically illiterate. If it makes no sense to someone like me, there was never any hope that it would be adopted by the masses who just want things to work. Google may not have helped here, and I’m certainly not among their fans, but it’s hardly entirely their fault that it never caught on.
The user does not need to understand it. A user does not understand https or hashing and salting. Still, every one of these is important these days for online security.
I am not a huge fan of passkeys themself, especially when the secrets are held by big tech, but they promise better security and protection against command n attacks like phishing.
I take your point. But I would argue that the user needs at least to understand the basic theory. Otherwise you get me, who sees no benefit, resents when it’s imposed unilaterally, and finds ways around the inconvenience.
You have a point that it will be hard to explain this to everyone on why it is better.
From my understanding, when you use a password manager, the user will enter a pw into it that they remember and the vault will unlock. Then when they go to log into a website, a different, longer, and impossible to remember password will be sent to the site at login. (Assuming they are using the manager well). A week later when they go to log in again, the same long password will be delivered.
The problem is that if a bad actor gets involved, whether it is the website is attacked or they send the user a phishing url or something and the password from the manager is exposed, it will have to be changed. That scammer can now log into that website as the user whenever they want, and possibly any other website that user used the same password for. Hopefully they didn’t if they are using a manager.
With passkeys, a user will log into their manager with a password they remember, but when they go to log into a website, a different token will be sent, based on their key, every time. So if a scammer is listening at the router they still can’t log in again because it has expired.
It is still not a perfect thing, I would imagine that phishing sites could still get a scammer in, who could possibly do bad things or change the login credentials but it is still much more secure than sending a password to the site for the user.
What makes no sense to you, exactly?
Users not having to remember a bunch of passwords makes a huge amount of sense to them. The support is already built into the devices they are using and it’s somehow, they don’t know or really care, more secure.
You need to check out public key cryptography and digital signatures. Those are the basics of Fido.
When the private key is bound to a device it is not possible to fake or steal it through conventional methods. Passwords are the weakest link and an easy target for attackers - passkeys basically solve that.
User adoption depends on implementation, but everything is easier than remembering a secure password or using a password manager for most people. There needs to be an easy and secure way to distribute passkeys across devices, and any backup mechanisms may be a weak point. In any case: still better than passwords.
Passkeys are. more similar to TOTP codes than passwords. Everything about passkeys is autogenerated. Browser negotiates with website to generate a key pair that will establish your identity on that site. Every time you “login” they exchange unique autogenerated keys to prove to each other who they are. That’s it. You never have to remember anything again and it’s impervious to many attacks that affect passwords and 2fa codes.
Where they fucked up is allowing big tech to call the shots so now instead of simply having passkeys in your browser you have to go to a higher authority to have them validated. And goes who that is — Google, Microsoft, Apple. So it’s basically gatekeep and you can’t touch them without depending on them.
How is that different from mutual TLS authentication?
Edit: It seems like OPAQUE just initiates mutual TLS authentication after the TLS session has already been negotiated with PKI. So it basically just allows websites to design their own login page instead of the one designed by the web browser.
It’s like the initial authentication, where server and clientnexchange a symmetrical key with their asymmetrical keys. The difference is that in that exchange the server and the client meet for the first time whereas the point of pass keys is that once when you were already authenticated, you validated the device or whatever will hold the private key as a valid source, so then when the authentication code gets exchanged, both ends can verify that the other end is who they tell is, and both can verify the other end as valid, and thus that exchange authenticates you because you, in the past, while authenticated, trusted that device as valid.
Technically, yeah, it’s an asymmetrical key exchange. Iirc the server sends you a signed certificate and you need to unencrypt itnwithbtheir public key and sign it with your private key, so they can the getnit back and ensure that it was you who signed it, using your public key to check the validity of whatever was sent.
I don’t know enough to be 100% corrextbon the details, but the idea is that it’s an interaction between asymmetrical keys.
Soporta like how we use keysbto authenticate through github through SSL, but with an extra level of security where the server validates a key in a single endpoint, not wherever that private key would be held (like with SSL)
With this much complexity, why not just use TLS client certificates without PKI and managed by a password manager?
Much of the complexity described here comes from the question “which password manager?”
I also find passkeys to be underwhelming and hope they don’t catch on. It seems like a huge mire of complexity for very little gain. It seems like there are two main goals here:
- Don’t sent secrets to the sever.
- Stop phishing.
Both great goals. However I wonder if we threw out the baby with the bathwater with passkeys.
A password manager is already a huge step to blocking phishing, because if the password doesn’t auto-fill you get super suspicious. If you push your user to randomly generate their passwords then they also don’t remember them so would have to look them up, then copy them over. If you are worried about users who are a risk to themselves you can make the route to extract a password from the password manager as complicated as you like.
As for not sending secrets to the server I think using a PAKE would have been a great option. If this was paired in a browser-integrated password manager it could be very secure. Think about some type of form field that can be filled with a password that isn’t accessible to the page itself. The browser would then tag the password as PAKE and never expose it to the page again.
Another cool think able PAKE is that they can also authenticate the server. TLS-integrated SRP was very cool like this as you could have a self-signed certificate but verify it by entering your username and password. The UX may not have been good enough for public sites but it was an amazingly easy and secure option for private sites. This would actually be more secure than a PKI signed certificate as you aren’t risking CA compromise. That being said integrating this with browsers with good UX may be quite difficult. I would love to see it.
But the biggest thing we lost was understandability. Even my grandmother understood what a password is. She knew how to back it up, how to transfer it to a new device. She could use it in two different browsers without setting up some multi-browser sync tool. She could write it in a notebook and log in at the library computer.
I really think that we should have just iterated on passwords. Switch to a PAKE and keep improving password-manager UX and pushing most users to auto-generated passwords. So much was lost by switching to a system that most users don’t understand.
I wrote a blog about this a while ago. https://kevincox.ca/2022/04/07/passwords/
Glad to see another person who is not keen on the passkeys. I have the feeling it is being hyped and perhaps without good reasons. Therefore I was glad to share this blog post when I saw it on Mastodon. btw, the blog post author turns out to be the software developer of similar software like Authentik and Keycloak. In other words, not just the average Linux user :)
I really think that we should have just iterated on passwords. Switch to a PAKE and keep improving password-manager UX and pushing most users to auto-generated passwords. So much was lost by switching to a system that most users don’t understand.
When I search with a search engine for PAKE I don’t find anything useful. Got a link ?
I like your reasoning about just using passwords. However, my experience is that a scary amount of users are using the same rather weak password for lots of different accounts. And a still scary amount of users does get tricked into phishing emails. What I like for myself is have a bunch of security keys and use them as much as possible for important logins.Some applications allow for five different security keys to be configured.And this could theoretically also be a way to use 2FA within teams. One team person does the login, adds a key, then let’s the second team member put in their key and so on.
I wrote a blog about this a while ago. https://kevincox.ca/2022/04/07/passwords/
Thanks. I see you shared it two years ago on Lobsters and got a fair amount of comments. 👍
https://en.wikipedia.org/wiki/Password-authenticated_key_agreement
Cloudflare also had a fairly good post a while ago about a newer PAKE algorithm: https://blog.cloudflare.com/opaque-oblivious-passwords
a scary amount of users are using the same rather weak password for lots of different accounts
This is true, but you can force them to use a random password just as easily as you can force them to use a randomly generated key. The end UX can look basically identical if you want it to. My point is that this is basically a UX problem. Instead of just making the change we are inventing this new protocol to shuffle along a UX change at the same time. Maybe part of this is because the change has major unaddressed downsides that would be too obvious to slip by if made as an incremental upgrade to passwords.
One team person does the login, adds a key, then let’s the second team member put in their key and so on.
There is no reason you can’t have multiple passwords associated with an account.
But… PAKE is used as a method for ongoing exchange of messages, you wouldnt avoid using a password when authenticating, which is the whole point of this debacle.
In really don’t see it that complex, in my last job IT installed a passkey in my laptop, which then Microsoft used to login and thorough its SSO, I just stopped using passwords altogether after logging into my PC itself. This is way more secure for the average Joe than having 5 postists with passwords pasted in the sides of the monitors. Yes this is way more common then you think, there’s a reason passwords need to be rotated all the freaking time.
Once rolled out, workers didn’t have to do anything to authenticate, as long as they were using the work laptop the company assumed that the used was the one using it, since the laptop was registered to the user, and it was way more comfortable.
It’s not really that hard to explain to people. Sending passwords is insecure because if an attacker gets the password, you lost. With passkeys, once you set it up, google/microsoft/pepapig.com will send a request to authenticate to your phone, where you will just say “yes” and they will talk with each other to give you access. If an attacker gets hold of that message, it doesn’t get anything of value because each time pepwpig.com and your phone talk with each other, they say different stuff and the attacker would just have yesterday’s responses, so they lose.
Old people won’t adopt it unless forced, just like they adopted special passwords by adding 1 and * to whatever stupid word they use and writing it next to their work monitor, in the office. They just won’t. Either IT automates everything for them or anything we develop will get completely bypassed.
But… PAKE is used as a method for ongoing exchange of messages
I don’t know what you mean.
In really don’t see it that complex, in my last job IT installed a passkey in my laptop
They can also install a randomly generated password just as easily.
Sending passwords is insecure because if an attacker gets the password, you lost
That is why you use a PAKE, you don’t send the password.
Old people won’t adopt it unless forced
They also won’t adopt passkeys unless forced. What is the difference?
This PAKE post by Cloudflare is way over my head, but very good to see that new things are explored to make security really better.
Not sure if this applies but incidentally I changed my otp manager from microsoft to vaultwarden today. Adding security keys in the process is mostly two additional clicks. Of the 20 accounts I migrated, only about 7 had the option and only with one it was more work than adding totp.
Yeah I use bitwarden and it was pretty panless. My only issue was on github the addon didn’t pick up on the passkey initially, had to make a new one.
Happy to hear it works for others as well. :)
Doesn’t using the same service for password management and OTP defeat the purpose of 2FA?
Its a pretty tough decision what to use for this imo since technically, you‘re right. Then again, you already have to log into your os and unlock the password safe to get the passwords or the otps.
The reason why mfa is done is if your password leaks you are not completely effed. You can obviously use a second selfhosted service with a different password but chances are most people would rather use something easier.
Also, passkeys work the same way. They work if you are logged into a device. That way you get no additional password except you can only use it from the device in question.
deleted by creator
