I really wish they would work on making passkeys simpler to implement, remove all the JS requirements and make the implementation basically impossible to get wrong.
Right now if you try to implement Passkeys for your website you either use some 3rd party system/library and hope they did it right or you get sucked into implementation mess and hope you implemented it right.
Chances are high nobody did it right, since it’s all still brand new and very complicated and I’m sure not all the different failure modes are known yet.
I really don’t see how it is possible. Fundamentally, the developer must provide the relying party and that is highly dependent on the service registering to. For example, you cannot simply set the relying party to the origin because some services have a dedicated auth service. RP cross-origin is a thing and requires careful consideration on behalf of the developer.
As far as I’m concerned, specifying the RP is one of the most annoying aspects of webauthn and it is also one of the pro-security features that it touts!
You are talking about one part of the protocol, I’m talking about the implementation of that protocol in the browser by people wanting to protect a website.
It’s still stupidly harder than it needs to be to protect a website. I’d argue Passkeys make it harder to protect a website, not easier.
As soon as you go past whatever the web server has built in(which at best is pretty sadly implemented HTTP basic authentication), it’s ridiculously hard to protect resources on the Internet.
It’s even annoyingly hard if you rely fully on third parties like Google, Microsoft or Apple to handle your auth for you.
Almost full circle. They reinvented the “password manager”, but with extremely complicated specifications (FIDO2, WebAuthn), especially considering the purpose, a shitload of JS and a pile of legacy crypto on top 🤡
Except that password managers use symmetric cryptography (shared secrets). Passkeys use asymmetric cryptography (public-private key pair), which comes with a lot of security benefits.
I have never really been able to figure out what a passkey is so apologies if this is missing the point, but the password manager I use uses asymmetric cryptography. I haven’t really used 1password or lastpass or any of the popular password managers; do those work differently?
The underlying protocol is WebAuthn, and “passkeys” is basically a mass-market branded version of it which is getting a lot of attention.
The basic idea is that instead of having a password or other type of shared credential, for each site you create a public/private keypair and the site stores the public key as part of your account data. Then when you need to authenticate to the site, they present you with something to sign using the private key, and use the public key on file to check the signature.
The claimed advantages here are:
Does away with credential breaches. If you pop the site’s auth database, all you get are the public keys, which are not usable to sign in.
Phishing resistance: whatever device you’re using knows which keypair goes with which site, and you have to fool it rather than fool the human user. And a key failure mode of password managers – that you can just override the password manager’s refusal and manually copy/paste the password to log into a phish anyway – is a lot more difficult since you’d need to manually conduct the whole cryptographic dance unassisted. You can if you’re sufficiently motivated and knowledgeable, but that’s a pretty high barrier.
Simple end-user workflow: when it integrates into the browser (either as a direct feature or via plugin), it’s a pretty seamless experience, and generally all you do to sign in to a site with passkeys is engage your device’s biometrics (fingerprint reader or face recognition or whatever) and it Just Works™.
The last bit is really an understated killer feature. Non-password-based authentication systems have historically had terrible user experience, bordering on completely unusable for insufficiently-technical people. And public-key cryptography also has historically had terrible user experience (I recall a conference once where the statement “we will drink until PGP makes sense” was uttered, for example). Automating the whole process works wonders for improving the experience.
Does away with credential breaches. If you pop the site’s auth database, all you get are the public keys, which are not usable to sign in.
If everyone uses a password manager, the long and hashed unique passwords also don’t give the attacker anything
Phishing resistance: whatever device you’re using knows which keypair goes with which site, and you have to fool it rather than fool the human user. And a key failure mode of password managers – that you can just override the password manager’s refusal and manually copy/paste the password to log into a phish anyway – is a lot more difficult since you’d need to manually conduct the whole cryptographic dance unassisted. You can if you’re sufficiently motivated and knowledgeable, but that’s a pretty high barrier.
On the other hand, if someone gets your device in their hands, they now have immediate access to all sites. It’s also not trivial to revoke the access - you can’t just use another device to do it, because 1.) how do you which passkeys to revoke and 2.) what stops the attacker from doing this before you do it? But if you have to follow a different process (without passkeys) to revoke passkeys then we are back to that this different process can be used for phishing attacks.
Simple end-user workflow: when it integrates into the browser
And when it doesn’t it becomes much more complicated. And on the implementation site it also becomes more complicated hashing and comparing passwords is a very simple thing to do in comparison.
All in all, a lot of open questions and the question is really if the added complexity does not create more (maybe yet unknown) security issues in combination with human usage than password managers.
Ok, there’s a fundamental misunderstanding of the threat model here.
Passkeys protect against all the actual real world threats. They do not protect against someone with physical access to your hardware, and knowledge of the login/unlock credential of that hardware. But if that is your threat model, passwords also fail.
However, even in the case of that level of compromise, the design of passkeys was intentionally such that the actual key material could not be extracted, so even that level of compromise would not allow for secret use of the credentials because passkeys were still restricted to the host device. Obviously once you add the ability to export credentials now an attacker with this level of access can extract that key material alongside all your passwords.
To go through your points:
On the other hand, if someone gets your device in their hands, they now have immediate access to all sites.
Which they get with your passwords already
you can’t just use another device to do it, because 1.) how do you which passkeys to revoke
All of them, just like all your passwords
2.) what stops the attacker from doing this before you do it?
Nothing, just like your passwords
But if you have to follow a different process (without passkeys) to revoke passkeys then we are back to that this different process can be used for phishing attacks.
Just like passwords.
And on the implementation site it also becomes more complicated hashing and comparing passwords is a very simple thing to do in comparison.
On the other hand, all that “complicated” stuff means:
Your users cannot be man in the middled into account compromise
Your users cannot be social engineered into account compromise
Your users get the above without having to use a separate 2FA gadget
Your site can avoid the need for obnoxious and phishable 2FA hoops in the normal sign in flow for passkey sign in
Your users (those who are technically minded) don’t have to wonder about whether your(*literally every site is functionally anonymous, not specifically you) is actually hashing and storing passwords properly
Again, the problem here is a failure to recognize the actual threat model. Outside of specific (expensive) case the real world problem is not someone stealing you/your user’s hardware and then using the independently discovered passwords from that hardware (because stealing your hardware doesn’t magically bypass your device passwords). But if that is a threat model that matters in your use cases, then passwords are still broken there as well, and the issue is that while objectively more secure and harder to exploit than passwords, passkeys are still possibly not good enough.
The overwhelming attack vector in the real world is phishing, social engineering, malware, and similar attacks, where the goal is to get you (or your system) to - by some mechanism - provide all the required log in credentials for the target site. Something that cannot be done with pass keys, because of the complicated stuff you’re questioning the value of. There is little to no interest in physical access to your devices, and in general the relevant parties would like to not even be in the same countries as their victims, let alone the general vicinity.
The problem of “what if someone has access to my device[s] and the passwords/codes required to unlock them” is outside of the bounds of any of this, because at that point they can access any and all of the data that device ever has. Again, prior to this proposal to support exporting passkeys, passkeys were still superior to passwords because by design your attacker would not be able to copy the key material and so could not just silently reuse your passkeys at their leisure, which they can easily do with passwords, which is to my mind much worse.
They do not protect against someone with physical access to your hardware, and knowledge of the login/unlock credential of that hardware. But if that is your threat model, passwords also fail.
Not if the passwords are in my head only. Which is true for the really important ones.
so even that level of compromise would not allow for secret use of the credentials because passkeys were still restricted to the host device
Yeah, but if I have access to all the passkeys and create new ones, why would I need the “credentials” (i.e. the private key)?
On the other hand, all that “complicated” stuff means:
Your users cannot be man in the middled into account compromise
Yes they can because of the “different process” for recovery. You might claim that this is harder to abuse, but I’m not so sure. It might turn out it’s not.
Your users cannot be social engineered into account compromise
See above
Your users get the above without having to use a separate 2FA gadget
And the attacker only needs one device instead of two now. Just like with a password manager.
Your site can avoid the need for obnoxious and phishable 2FA hoops in the normal sign in flow for passkey sign in
Your users (those who are technically minded) don’t have to wonder about whether your(*literally every site is functionally anonymous, not specifically you) is actually hashing and storing passwords properly
That last part is really the only thing that is really positive - it’s guaranteed that an attacker can’t access the service even if they are able to get a copy of the database of the service. With passwords, the service needs to have the password hashed and not in plaintext.
Not if the passwords are in my head only. Which is true for the really important ones.
Then, even if they are good, they’re just as susceptible to phishing to a password manager, only a password manager is not as easily fooled by online phishing scams as people are. Neither really has meaningful defense against multi step social engineering.
Yeah, but if I have access to all the passkeys and create new ones, why would I need the “credentials” (i.e. the private key)?
Because passkeys are not passwords - they’re a key that used for a cryptographic operation. Signing in is not a matter of vending a secret to the host. The host service transmits a nonce, the browser takes that nonce, looks up the passkey for service it has connected to over TLS, if it finds one, and then you approve it (via some local authentication mechanism - i.e. malware compromising the device cannot arbitrarily perform these operations, that’s part of the reason for the hsm involvement) - then the passkey implementation’s hsm signs a response that includes the server provided nonce, and the browser sends that back to the server. Which validates your current session.
So having access to your device, and the ability to unlock your device, an attacker can sign into a service that uses a passkey - just like they could with a password manager. But now, this person - who remember, we’ve already declared has your device passwords - can copy all of your passwords off your device to use at their leisure. To abuse their current compromise of your device they would have to add an additional passkey (something you can and should be notified about, and you can see the list of valid keys).
And the attacker only needs one device instead of two now. Just like with a password manager.
The attacker doesn’t need any of your devices, that’s literally why phishing works. 2FA increases the cost of compromise, but in your threat model your accounts are valuable enough for them to be working towards and successfully getting:
Physical access to your device[s]
Your device passwords/passcodes
So the costs of intercepting the standard 2FA schemes is not a major issue, more over they can extract the state from any of your 2FA apps given they have access to your 2fa apps and device passwords they can use those to add their own devices to your 2fa mechanisms.
That last part is really the only thing that is really positive - it’s guaranteed that an attacker can’t access the service even if they are able to get a copy of the database of the service. With passwords, the service needs to have the password hashed and not in plaintext.
You seem to not be understanding the attack vectors here.
The reason for password hashing is not to protect your own service. At the point your servers are compromised to the point that an attacker has access to your authentication database, your service, and all of the accounts it hosts are completely compromised. The reason for password hashing is so that an attacker cannot take the passwords from your server, and then try them on other services. Run by other people.
Password hashing is not a method to protect your service, or to protect your users on your service. It is solely to protect your users against those secondary attacks, which do not otherwise involve you at all.
Passkeys render that problem moot, not because there’s no password to leak, but because the client will never use a passkey from Service A to authenticate against anything that cannot prove that it is itself Service A. So authentication is not relayable (and so phishing and spoofing are not possible), and that any given authentication response is not replayable, so a moment in time compromise does not provide data that allows the attacker to authenticate again in future.
The purpose of passkeys is to secure users against actual real world attack vectors, rather than hypothetical attacks, especially ones as extreme as what you are suggesting. They are more secure than passwords in every practical sense, they are more secure than any multi factor scheme.
They are not robust against your proposal of a person who has gained physical access to your hardware, and who has the ability to authenticate themselves as you on that hardware. But that vector is even more catastrophic for passwords, including those that are in your head, because at that point your attack vectors include malware, key loggers, malicious extensions, etc which mean your passwords can be intercepted, and then used at will by the attacker.
Not sure if that’s worth all the disadvantages…
That’s your call, but I’m concerned that you are making that call without an accurate threat model (your go to model is a local hardware attack by someone with you device passwords), nor an accurate model of the complexity, like I suspect you have no problem with your site using TLS, despite TLS being vastly more complex.
Again: you either lose full access once you lose your passkey(s) - or you have a recovery flow and now a phisher does not need access to the device but rather to the information in the recovery flow.
You seem to not be understanding the attack vectors here. The reason for password hashing is not to protect your own service.
Honestly, instead of making assumptions, maybe try to understand what I’m saying.
And yes, my threat model might be different than yours. I see anything between me and a service as a potential threat and that includes my hardware, my OS and so on.
And yes, I do have my doubts about TLS and let’s not pretend there haven’t be major security issues with those certificates before.
Not if the passwords are in my head only. Which is true for the really important ones.
You’re doing something 99% of users never will.
And the attacker can’t open my device, and thus can’t access my passkeys, because they would need to know my pin code (that’s in my head), or use physical violence to get me to put my thumb on the fingerprint scanner.
If everyone uses a password manager, the long and hashed unique passwords also don’t give the attacker anything
If you can get 100% of people to follow 100% perfect security hygiene 100% of the time, sure, technical improvements in the nature of the credentials don’t matter. I wish you luck in your attempt. One thing passkeys and other non-password-based systems try to address is the fact that we’ve never succeeded at this and so maybe “fix the people” isn’t going to be the solution.
On the other hand, if someone gets your device in their hands, they now have immediate access to all sites.
The mobile-device implementations I’ve seen rely on the mobile device’s biometrics to gate access to passkeys. Same for desktop implementations – lots of computers have a fingerprint reader, for example. And lots of people already set up that stuff for convenience, which means you don’t have to change user behavior to get them to do it.
Besides, someone getting their hands on your device is an immediate breach of your password manager, too, and if you want to argue the password manager should be locked by a password or biometrics, well, passkeys should be too, so password managers offer no improvement.
And when it doesn’t it becomes much more complicated. And on the implementation site it also becomes more complicated hashing and comparing passwords is a very simple thing to do in comparison.
“Simple” hashing and comparing of passwords is anything but.
At any rate, it seems pretty clear that you are not really open to having your mind changed and that no amount of argument or evidence would change it, so I’m going to drop out of this conversation.
If you can get 100% of people to follow 100% perfect security hygiene 100% of the time, sure, technical improvements in the nature of the credentials don’t matter.
The same is true for passkeys. If no one uses them, they don’t help. Or do you mean forcing everyone to use passkeys? Yeah, well, great. And sure, you can’t force people to use password managers.
The mobile-device implementations I’ve seen rely on the mobile device’s biometrics to gate access to passkeys
And is that guaranteed to be secure? Can a Scammer not fake your fingerprint with all those devices? As far as I know the devices can usually be tricked pretty easily.
Besides, someone getting their hands on your device is an immediate breach of your password manager, too
That’s actually true and it is the reason why I’d like to see a password manager that limits the number of accesses over time. Ofc. for that to work it can’t run locally.
“Simple” hashing and comparing of passwords is anything but.
But the shared secret (password) is still symmetric cryptography.
This matters because with passkeys, some bad actor who controls the website for a few seconds can extract your token and use it for a while. But with a password, it can extract the password and then use this to generate new tokens.
(there are ways around this even with symmetric cryptography such as hash-chains, but it’s not really used in the wild)
That really only makes sense as a rebuttal if there are significant advantages. The password manager workflow is that I create a secret key which I store in a secure key store, I give that key to the website, and then the website gives my client a temporary access token when I provide my key. That temporary access token is then used for day-to-day authentication, requiring renewal using the secret key every now and then or when authenticating a new device.
This, honestly, is a pretty great system. What’s more, it’s universally supported everywhere already. What benefit does passkeys actually provide compared to this?
They are not vulnerable to interception. If your browser is compromised or some part of the connection is insecure, for example, and you use a password then that password is visible as plain text. An attacker can copy it and then later, from another machine, log into the service. In contrast, with a pass key the attacker sees only the challenge-response for the current session. They cannot replay that later.
They are not vulnerable to leakage if the server does not store them securely. A lot of systems over the past decades have been compromised and had password databases leak. Some of these were unhashed and so were complete compromises. If you reused a password, other systems may be compromised with it. Even with hashing, older hash schemes are vulnerable to brute force attacks and so attackers can find passwords. With a pass key, the server holds only the public key. Exfiltrating this does not help the attacker (unless they have a quantum computer, but it’s easy to move passkeys to PQC before this becomes a realistic threat).
They cannot be reused. You may have a single secret, but this is used with the remote host name in a key derivation function to provide a unique private key for each service. This prevents impersonation attacks because your key for service X and your key for service Y are guaranteed to be different. If you go to a phishing site and it forwards a challenge from another site, you will sign it with the wrong key and the login will not work.
If Apple’s sync service is compromised, passkeys can leak, but this would have to happen at the point when you set up a new device. The secure elements on the sync’d devices perform a key exchange protocol via iCloud, and with iCloud providing some attestation as to device identity when you enable syncing. The exchanged key is never visible to another device (iCloud can’t intercept it, but it could make your source device do the key exchange with the wrong target. This is similar to a TOS handshake, where iCloud is the certificate signing authority). After this point, iCloud only ever sees cypher text for wrapped keys and so can’t decrypt them even if it is completely compromised (though it could trick users into initiating the sync flow to an untrusted device). I believe the secure elements also have a certificate that’s baked in at device provisioning time so you’d need to also compromise that if you wanted to sync keys to a device that let you extract them, rather than to another Apple device.
What benefit does passkeys actually provide compared to this?
For one, this system does not allow a central entity to monitor and disable someone’s access to all their services at once. (you didn’t specify who the benefit should apply to…)
I feel there’s no real way to get onboarded on this technology (is there usable documentation anywhere?) and it probably has relatively extreme failure modes where you can be locked out of stuff entirely.
IMHO, being able to export passkeys is missing the point of passkeys. They are supposed to be cheap and easy to create so you should be able to set up a passkey for your account on any device/account/browser that you use. If you use an account on a device, just create a passkey on it on demand.
Exporting passkeys would make sense if it was expensive or complex to set them up. I guess it depends on the account provider how easy or difficult they make it, but making it difficult to set up a passkey on a device seems like a great way to kill their adoption.
Expecting people to log into all online services they use and set up a new passkey for each of them when they switch devices is also a great way to kill their adoption, as is expecting them to tie all their logins to a singular account with a sync provider.
I know. That’s why I said they people can do it on an ‘as-needed’ basis, and not pay the entire setup cost up-front. When you need access to an account, log in with an email flow, then set up a passkey. If the app is designed correctly, you should be guided on this flow automatically.
Click on ‘forgot my password’ or equivalent account access alternative flow
Enter the email address associated with the account and let them send you the email
Read the email, find the 6-digit one-time token
Enter the one-time token in the account recovery screen
You are now logged in. Go to your account auth settings page, eg https://github.com/settings/security#passkeys , and create a new passkey for the new device. Optionally, delete the old passkey for the old device.
Forgot password should NEVER EVER EVER be part of the normal flow. It must always be a thing that you only need to use in emergencies. Having it be part of the normal flow leaves zero margin for error.
There are already many sites out there that default to logging in with email only. Actually, any service that studies their users’ login metrics knows that a significant number of people always use the ‘forgot password’ flow to log in to their account, because they can’t be bothered to even remember a password. They just use the path of least resistance. I’m just suggesting using that as a convenience to set up a passkey on a new device, to create an even easier and more secure auth flow.
Forgot password is a last resort. If that doesn’t work then you’re locked out. You should never need to use it unless there’s an emergency. Switching platforms absolutely does not qualify.
I’m thinking about it in terms of incidents at organizations that cause people to be woken up at night. Forgot password is an escape hatch for that level of severity.
I regard forgot password as just another means of authentication, nothing more or less. And if it was so critical, then it’s a joint that should be well oiled.
Of course ‘forgot password’ is a last resort, I never said otherwise. But users need some way to recover their accounts if they lose access. You can’t just lock them out forever. At least, no sane website is going to do that. You are going to have to offer alternative login methods, and ‘forgot password’ with an email flow happens to be the most common one, which is why I suggested repurposing that as a step towards setting up a much easier and more secure passkey auth. If you have a better alternative than ‘forgot password’ to recover access so the user can log in and set up a passkey, then of course go for it.
But users need some way to recover their accounts if they lose access. You can’t just lock them out forever.
Yes you can. Companies are already doing it. Even Google does it.
And many companies require 2FA and lock you out if you lose access to your phone number. Some don’t even allow you to setup a third factor for recovery. This is reality and chances are with passkeys it will get worse.
But having a “forgot password’ flow immediately invalidates lots of the arguments in favor of passkeys. E.g. phishing now works. E.g. present the user a fake bank website and show them a message that says “we have updated our security and your old passkey no longer works. It seems your device is unable to do that automatically, so please use the forgot password flow to do so” yadda yadda and we are back to square one.
OK, good luck being a viable business that locks out users forever when (not if) they lose their credentials. IMHO, the risk of the ‘email login’ flow is being greatly overblown when you don’t actually have passwords, only email login and passkeys. First, the malicious actor would have to go to the real bank website, enter your email address, and initiate the email login flow. Then, they would need to immediately send you another email telling you to click on the given link and enter the temporary token from the first email there. Chances are really good that if the temporary token expires in 5 minutes, the intended victim wouldn’t even open these emails in time to enter the token. And even if they did, the first (legit) email from the bank should warn them against entering the token into any other page than the bank’s. And if the attacker floods the victim with a flurry of ‘email login’ emails, anyone would be able to tell something phishy is going on.
First, the malicious actor would have to go to the real bank website, enter your email address, and initiate the email login flow. Then, they would need to immediately send you another email telling you to click on the given link and enter the temporary token from the first email there.
I think if you tie this all to a malicious link the user has followed, you can make doing all this a lot smoother. It would depend on egregious user error (entering the code in the box on the phisher’s site that it presented them and told them to post the code in, rather than following the link in the email), but egregious user error will happen some of the time.
Realistically, the “forgot password” flow is probably used extremely routinely by most users. And I kind of expect that routine use of passkey re-enrollment flows will become just as common if passkeys catch on. Which means that passkeys can’t be, in practice, any more secure than their re-enrollment flows.
If you have a passkey on your phone, and your phone gets stolen/hardware dies how do you recover if you haven’t created backup passkeys ahead of time on other devices?
Also how do you migrate passkeys to a new phone from the old one when you upgrade your phone?
In a sane world the service/site you’re trying to use would have ensured you’d created recovery codes or similar. But given we don’t live in a sane world, the option to backup/export passkeys does seem like one I’d like to have :/
Of course, the best place to store account recovery codes is in your password manager, because it should be well maintained with decent security and availability.
You log in to the account whose passkey was lost with an account recovery method like ‘log in with email’. Then you set up a new passkey on the new device. And, if the app is implemented correctly and lets you manage passkeys properly, you delete the passkey that was on the lost device.
But if you preserve that email flow as an option, you break the benefits of credentials being tied to device hardware, and are back at needing password + second factor + backup second factor.
No you’re not? You can have an email login flow and then use it to set up a passkey on the device. You don’t need password + MFA at all. But you need to offer some way for the user to recover access to their account even if you don’t have passkeys. You can’t just lock users out of their accounts if they forget their credentials. Can you?
Your objection is based on the fear that re-enrolling is going to be a horrendously complex and slow process. What I am suggesting is to make it a smooth and easy process, almost as natural and quick as logging in with a passkey and Touch ID. If you do this on an as-needed basis, the burden won’t even be noticeable.
Please don’t try to convince me that you need to access your 1000 logins on your new device immediately as soon as you get the new device because you know that’s not true 😉
Not all of them, sure, but any one of them, yes. And there is literally no way to know which of the 1000 you’ll need next. You’re describing a Kafkaesque hellscape of bullshit any time you get a new phone or laptop or something catastrophic happens to one of your OS installations or tokens. It’s completely unnecessary tedium and I hope to god that we’re somehow lucky enough that the people working on the specification actually listen to what people want instead of just being smug and argumentative like you are in the comments here.
I don’t think you need to worry so much; we are literally discussing an article which says that passkeys can be exported. The people working on the specification clearly want this. All I’m saying is that in my opinion exporting passkeys defeats the point of passkeys. If you want the burden of having to manage passkey exports (which are going to get outdated at periodic intervals), that’s on you 🤷♂️
I think it’s important that passkeys provide support for the model you’re describing, because creating private keys inside boxes you can’t remove the keys from (smart cards, HSMs, etc) is a strong security model.
That said, for most people most of the time it’s bloody inconvenient. If you require people to maintain two or more passkeys in every place that they store accounts, and you don’t allow exporting, you’re basically guaranteeing that people will lose access to some of their accounts from time to time. This is basically like backing up your data: the only thing that works for most people most of the time is something automatic like periodic backups to the cloud that they don’t have to remember to do or really manage at all. The more first class the mechanisms for passkey export and portability are, the more likely the end result is something that balances security with the reality of how people actually use their computers, as well as providing some much needed user control of their own data.
you’re basically guaranteeing that people will lose access to some of their accounts from time to time.
No; I’m calling for a model which guarantees users access to their accounts in a simple and secure way in all situations, whether they have a passkey or not, as long as they have access to an email account. Let me detail the flow again, in case it helps:
User goes to login page
Login page has script that detects user passkeys; (a) if any of them are tied to this site, prompts user to log in with one of them, or (b) if no passkeys found for this site, asks user for email address, emails an OTP code to the user with a big warning to never share this code with anyone else, user enters code successfully, then site logs the user in and immediately prompts them to create a passkey
User is now logged in
From the user’s perspective, this process is minimally intrusive, not cumbersome, while still being as secure as possible.
emails an OTP code to the user
this process is minimally intrusive, not cumbersome, while still being as secure as possible.
It’s basically the opposite of secure. “Log in via email” emails are sent in plain text out into the world. They’re generally short codes that you copy and paste, which are the thing most likely to be phished from users.
It’s also absolutely cumbersome. To log in I now have to go and find the message in my email, do something with it, delete it. I have to switch between browser tabs and generally screw around. Sometimes mail delivery is not instantaneous. Regular passwords are a thousand times better than this flagrantly user hostile experience, because at least there are mature password managers that integrate with browsers and don’t require anything but a couple of in place clicks on the login page to use.
You’re also ultimately just punting authority to the mail provider for all authentication. It would be better to just demand all websites use OpenID Connect to use your mail provider as an identity provider; at least that would be both secure and convenient for users.
The problem is most people don’t use password managers. Why do you think ‘Have I been Pwned’ exists? It’s because people keep using bad passwords and repeating them in multiple places. In light of actual user behaviours, it turns out that short-lived email tokens (which can be sent via TLS-encrypted email) is more secure than most users’ passwords.
Re: why not just use the email provider as an OIDC. Because (a) not all providers are OIDC-enabled; many people use smaller or ISP-specific emails which don’t have fancy identity provider capabilities. We would like to support them too. And (b) we are talking about email login as a fallback auth flow when you don’t have a passkey set up. Once you do have the passkey set up on the device, you can cut the reliance on any third-party service and just use the passkey.
Passkeys are already synced between e.g Apple devices for people in the Apple ecosystem. Apple may be missing the point of passkeys in your opinion, but the result of not being able to export them is that transferring passkeys between Apple devices is easy, while transferring them to non-Apple devices is impossible.
Mind you, this will only barely improve with this change; it will help people who are transitioning entirely from the Apple ecosystem to some other coherent ecosystem, but it won’t help people keep their keys in sync between their iPhone and their Windows laptop or their Mac and their Android phone. Passkeys remains an amazing tool for Apple to create ecosystem lock-in because they only sync between your iPhone and your Mac.
transferring them to non-Apple devices is impossible.
And I’m saying that allowing transferring passkeys is missing the point of passkeys, which is that they are locked inside the Trusted Platform Module and impossible to extricate, which makes them super-secure. Basically it becomes impossible to be tricked or hacked into giving up the passkey.
If you are allowed to export your passkeys, someone will find a way to trick people into exporting them en masse and leaking them. The article mentions encryption but is light on details so it’s anyone’s guess how secure it will really be.
If you need access on a new device, just set up a passkey on the new device. And possibly delete the one on the old device if that’s desired.
We’re going in circles. Passkeys are already synced between e.g Apple devices for people in the Apple ecosystem. Apple may be missing the point of passkeys in your opinion, but the result of not being able to export them is that transferring passkeys between Apple devices is easy, while transferring them to non-Apple devices is impossible.
Syncing within the Apple ecosystem is an easy problem because Apple can exhaustively enumerate the set of hardware roots of trust that will enforce the required security properties and permit key exchange only with them. This is a much harder problem when arbitrary other RoTs are involved.
You have repeated your previous comment word for word, I understood you the first time and tried to explain why your premise is incorrect (in my opinion) 🤷♂️
I repeated my previous comment word for word because it applies just as well to your response as it does to your initial comment. In other words, circles.
In general, I would recommend against repeating your comments verbatim in discussions, because it makes it look like you think the other person is an idiot who needs to be told the exact same thing over and over again. Please keep in mind that people who don’t agree with you about something are not idiots, and may have valid arguments and reasoning that you just don’t understand 🤷♂️
No, the point of passkeys is not that they’re in a TPM. The point of passkeys is to replace symmetric shared-secret auth with asymmetric auth.
Whether passkeys are stored in a TPM is an implementation detail. I use 1password which doesn’t use a TPM (but also works on every single one of my devices, which is worth much more than storing keys in a TPM.)
That’s the point for power users like you who use password managers. For ordinary people who don’t, one of the huge benefits of passkeys is that their secret keys are unreachable and so can’t be extracted through trickery.
For someone like you who uses a password manager to store your passkeys, a specification for exporting passkeys is a moot point, it doesn’t impact you either way.
I think that the increase in security that passkeys provide is large enough even without HSM backed private keys. For one you can do that still if you care about that threat model, but I’d argue for most people that trade off isn’t worth it, which is why we see these platforms focusing on sync. I have well over 300 items in my password manager, and while I have been going through and making 2 passkeys where I can, it is quite a pain. I also think the export spec isn’t just a plaintext export of the private keys, theres more too it to that to keep folks from getting tricked into exporting them.
Do you need immediate access to all of the 300 items? No? Then why make all the passkeys for them up front? Just make a passkey on an as-needed basis, when you actually log in to that service?
But this seems to rely on every site that uses passkeys implementing them correctly… whereas I’ve seen several cases where they use passkeys essentially like a password alternative: you get exactly one per account. So now you’re stuck and either need to share the passkey, only ever use that account from one device, or still need a password manager to provide a fallback option.
Yes, it’s possible that some sites don’t implement passkeys correctly. Should we really be papering over their deficiencies, or should we accept that they aren’t going to support passkeys properly and move on?
If you use an account on a device, just create a passkey on it on demand.
Without a password manager, how do you do this? I have a number of passkeys saved to my 1password, but without some other form of auth there is no way I could add a new passkey for a new device other than via a usb security key or a password manager with passkey support that lets me bring the passkey to a new machine so I can authenticate and initiate the process of creating a new passkey for that device (but why would I once I have the ability to log in?)
The same way you created the first passkey? Log in to the account with an account recovery method like ‘log in with email’, then create a new passkey once logged in.
there is no way I could add a new passkey for a new device
There is if the app is implemented correctly and lets you create new passkeys once you log in and go to the security/auth settings. Eg, https://github.com/settings/security#passkeys
but why would I once I have the ability to log in?
Because you might need to do it on a new device where you don’t already have a passkey.
ah, I’m used to dealing with the regime of “once you have a security key, you need that security key 100% of the time i.e. to add an additional security key” that is imposed by my employer
That’s how we do it too, whenever I have a say. They break, lose, forget their MFA sometimes, we require an on-site tech to verify their identity before the tech can delete the MFA and let them login and set it up again. The benefit of having 99.9% of staff on our own campuses and dedicated IT at each one.
Its not much to do with privacy and its all to do with security. So in that regard:
It stops phishing.
That’s the biggest “need” for it. Which is a pretty good one if you ask me. And it is completely capable of this on paper. Its clear there seems to be issues across the front end and back end of it: massive UX issues and massive implementation issues.
I really wish they would work on making passkeys simpler to implement, remove all the JS requirements and make the implementation basically impossible to get wrong.
Right now if you try to implement Passkeys for your website you either use some 3rd party system/library and hope they did it right or you get sucked into implementation mess and hope you implemented it right.
Chances are high nobody did it right, since it’s all still brand new and very complicated and I’m sure not all the different failure modes are known yet.
I really don’t see how it is possible. Fundamentally, the developer must provide the relying party and that is highly dependent on the service registering to. For example, you cannot simply set the relying party to the origin because some services have a dedicated auth service. RP cross-origin is a thing and requires careful consideration on behalf of the developer.
As far as I’m concerned, specifying the RP is one of the most annoying aspects of webauthn and it is also one of the pro-security features that it touts!
I agree RP is important, but why does it have to be done via JS calls? Unless you are talking about some other aspect of my comment?
You are talking about one part of the protocol, I’m talking about the implementation of that protocol in the browser by people wanting to protect a website.
It’s still stupidly harder than it needs to be to protect a website. I’d argue Passkeys make it harder to protect a website, not easier.
As soon as you go past whatever the web server has built in(which at best is pretty sadly implemented HTTP basic authentication), it’s ridiculously hard to protect resources on the Internet.
It’s even annoyingly hard if you rely fully on third parties like Google, Microsoft or Apple to handle your auth for you.
Almost full circle. They reinvented the “password manager”, but with extremely complicated specifications (FIDO2, WebAuthn), especially considering the purpose, a shitload of JS and a pile of legacy crypto on top 🤡
Except that password managers use symmetric cryptography (shared secrets). Passkeys use asymmetric cryptography (public-private key pair), which comes with a lot of security benefits.
I have never really been able to figure out what a passkey is so apologies if this is missing the point, but the password manager I use uses asymmetric cryptography. I haven’t really used 1password or lastpass or any of the popular password managers; do those work differently?
The underlying protocol is WebAuthn, and “passkeys” is basically a mass-market branded version of it which is getting a lot of attention.
The basic idea is that instead of having a password or other type of shared credential, for each site you create a public/private keypair and the site stores the public key as part of your account data. Then when you need to authenticate to the site, they present you with something to sign using the private key, and use the public key on file to check the signature.
The claimed advantages here are:
The last bit is really an understated killer feature. Non-password-based authentication systems have historically had terrible user experience, bordering on completely unusable for insufficiently-technical people. And public-key cryptography also has historically had terrible user experience (I recall a conference once where the statement “we will drink until PGP makes sense” was uttered, for example). Automating the whole process works wonders for improving the experience.
If everyone uses a password manager, the long and hashed unique passwords also don’t give the attacker anything
On the other hand, if someone gets your device in their hands, they now have immediate access to all sites. It’s also not trivial to revoke the access - you can’t just use another device to do it, because 1.) how do you which passkeys to revoke and 2.) what stops the attacker from doing this before you do it? But if you have to follow a different process (without passkeys) to revoke passkeys then we are back to that this different process can be used for phishing attacks.
And when it doesn’t it becomes much more complicated. And on the implementation site it also becomes more complicated hashing and comparing passwords is a very simple thing to do in comparison.
All in all, a lot of open questions and the question is really if the added complexity does not create more (maybe yet unknown) security issues in combination with human usage than password managers.
Ok, there’s a fundamental misunderstanding of the threat model here.
Passkeys protect against all the actual real world threats. They do not protect against someone with physical access to your hardware, and knowledge of the login/unlock credential of that hardware. But if that is your threat model, passwords also fail.
However, even in the case of that level of compromise, the design of passkeys was intentionally such that the actual key material could not be extracted, so even that level of compromise would not allow for secret use of the credentials because passkeys were still restricted to the host device. Obviously once you add the ability to export credentials now an attacker with this level of access can extract that key material alongside all your passwords.
To go through your points:
Which they get with your passwords already
All of them, just like all your passwords
Nothing, just like your passwords
Just like passwords.
On the other hand, all that “complicated” stuff means:
Again, the problem here is a failure to recognize the actual threat model. Outside of specific (expensive) case the real world problem is not someone stealing you/your user’s hardware and then using the independently discovered passwords from that hardware (because stealing your hardware doesn’t magically bypass your device passwords). But if that is a threat model that matters in your use cases, then passwords are still broken there as well, and the issue is that while objectively more secure and harder to exploit than passwords, passkeys are still possibly not good enough.
The overwhelming attack vector in the real world is phishing, social engineering, malware, and similar attacks, where the goal is to get you (or your system) to - by some mechanism - provide all the required log in credentials for the target site. Something that cannot be done with pass keys, because of the complicated stuff you’re questioning the value of. There is little to no interest in physical access to your devices, and in general the relevant parties would like to not even be in the same countries as their victims, let alone the general vicinity.
The problem of “what if someone has access to my device[s] and the passwords/codes required to unlock them” is outside of the bounds of any of this, because at that point they can access any and all of the data that device ever has. Again, prior to this proposal to support exporting passkeys, passkeys were still superior to passwords because by design your attacker would not be able to copy the key material and so could not just silently reuse your passkeys at their leisure, which they can easily do with passwords, which is to my mind much worse.
Not if the passwords are in my head only. Which is true for the really important ones.
Yeah, but if I have access to all the passkeys and create new ones, why would I need the “credentials” (i.e. the private key)?
Yes they can because of the “different process” for recovery. You might claim that this is harder to abuse, but I’m not so sure. It might turn out it’s not.
See above
And the attacker only needs one device instead of two now. Just like with a password manager.
That last part is really the only thing that is really positive - it’s guaranteed that an attacker can’t access the service even if they are able to get a copy of the database of the service. With passwords, the service needs to have the password hashed and not in plaintext.
Not sure if that’s worth all the disadvantages…
Then, even if they are good, they’re just as susceptible to phishing to a password manager, only a password manager is not as easily fooled by online phishing scams as people are. Neither really has meaningful defense against multi step social engineering.
Because passkeys are not passwords - they’re a key that used for a cryptographic operation. Signing in is not a matter of vending a secret to the host. The host service transmits a nonce, the browser takes that nonce, looks up the passkey for service it has connected to over TLS, if it finds one, and then you approve it (via some local authentication mechanism - i.e. malware compromising the device cannot arbitrarily perform these operations, that’s part of the reason for the hsm involvement) - then the passkey implementation’s hsm signs a response that includes the server provided nonce, and the browser sends that back to the server. Which validates your current session.
So having access to your device, and the ability to unlock your device, an attacker can sign into a service that uses a passkey - just like they could with a password manager. But now, this person - who remember, we’ve already declared has your device passwords - can copy all of your passwords off your device to use at their leisure. To abuse their current compromise of your device they would have to add an additional passkey (something you can and should be notified about, and you can see the list of valid keys).
The attacker doesn’t need any of your devices, that’s literally why phishing works. 2FA increases the cost of compromise, but in your threat model your accounts are valuable enough for them to be working towards and successfully getting:
So the costs of intercepting the standard 2FA schemes is not a major issue, more over they can extract the state from any of your 2FA apps given they have access to your 2fa apps and device passwords they can use those to add their own devices to your 2fa mechanisms.
You seem to not be understanding the attack vectors here.
The reason for password hashing is not to protect your own service. At the point your servers are compromised to the point that an attacker has access to your authentication database, your service, and all of the accounts it hosts are completely compromised. The reason for password hashing is so that an attacker cannot take the passwords from your server, and then try them on other services. Run by other people.
Password hashing is not a method to protect your service, or to protect your users on your service. It is solely to protect your users against those secondary attacks, which do not otherwise involve you at all.
Passkeys render that problem moot, not because there’s no password to leak, but because the client will never use a passkey from Service A to authenticate against anything that cannot prove that it is itself Service A. So authentication is not relayable (and so phishing and spoofing are not possible), and that any given authentication response is not replayable, so a moment in time compromise does not provide data that allows the attacker to authenticate again in future.
The purpose of passkeys is to secure users against actual real world attack vectors, rather than hypothetical attacks, especially ones as extreme as what you are suggesting. They are more secure than passwords in every practical sense, they are more secure than any multi factor scheme.
They are not robust against your proposal of a person who has gained physical access to your hardware, and who has the ability to authenticate themselves as you on that hardware. But that vector is even more catastrophic for passwords, including those that are in your head, because at that point your attack vectors include malware, key loggers, malicious extensions, etc which mean your passwords can be intercepted, and then used at will by the attacker.
That’s your call, but I’m concerned that you are making that call without an accurate threat model (your go to model is a local hardware attack by someone with you device passwords), nor an accurate model of the complexity, like I suspect you have no problem with your site using TLS, despite TLS being vastly more complex.
Again: you either lose full access once you lose your passkey(s) - or you have a recovery flow and now a phisher does not need access to the device but rather to the information in the recovery flow.
Honestly, instead of making assumptions, maybe try to understand what I’m saying.
And yes, my threat model might be different than yours. I see anything between me and a service as a potential threat and that includes my hardware, my OS and so on.
And yes, I do have my doubts about TLS and let’s not pretend there haven’t be major security issues with those certificates before.
You’re doing something 99% of users never will.
And the attacker can’t open my device, and thus can’t access my passkeys, because they would need to know my pin code (that’s in my head), or use physical violence to get me to put my thumb on the fingerprint scanner.
Or steal your fingerprint from a glass…
modern fingerprint sensors scan the tissue underneath the outer skin. it’s not just the oil pattern left by the wrinkles
Maybe. If the manufacturer gives me a guarantee and is regulated by law and has to have a liability insurance, I might put my trust it it.
Do CIA and NSA rely on it? No? Then I have my doubts.
If you can get 100% of people to follow 100% perfect security hygiene 100% of the time, sure, technical improvements in the nature of the credentials don’t matter. I wish you luck in your attempt. One thing passkeys and other non-password-based systems try to address is the fact that we’ve never succeeded at this and so maybe “fix the people” isn’t going to be the solution.
The mobile-device implementations I’ve seen rely on the mobile device’s biometrics to gate access to passkeys. Same for desktop implementations – lots of computers have a fingerprint reader, for example. And lots of people already set up that stuff for convenience, which means you don’t have to change user behavior to get them to do it.
Besides, someone getting their hands on your device is an immediate breach of your password manager, too, and if you want to argue the password manager should be locked by a password or biometrics, well, passkeys should be too, so password managers offer no improvement.
“Simple” hashing and comparing of passwords is anything but.
At any rate, it seems pretty clear that you are not really open to having your mind changed and that no amount of argument or evidence would change it, so I’m going to drop out of this conversation.
The same is true for passkeys. If no one uses them, they don’t help. Or do you mean forcing everyone to use passkeys? Yeah, well, great. And sure, you can’t force people to use password managers.
And is that guaranteed to be secure? Can a Scammer not fake your fingerprint with all those devices? As far as I know the devices can usually be tricked pretty easily.
That’s actually true and it is the reason why I’d like to see a password manager that limits the number of accesses over time. Ofc. for that to work it can’t run locally.
Compared to passkeys? I think it is.
But the shared secret (password) is still symmetric cryptography. This matters because with passkeys, some bad actor who controls the website for a few seconds can extract your token and use it for a while. But with a password, it can extract the password and then use this to generate new tokens.
(there are ways around this even with symmetric cryptography such as hash-chains, but it’s not really used in the wild)
More a logical extension to the concept of a password manager, not a reinvention
That really only makes sense as a rebuttal if there are significant advantages. The password manager workflow is that I create a secret key which I store in a secure key store, I give that key to the website, and then the website gives my client a temporary access token when I provide my key. That temporary access token is then used for day-to-day authentication, requiring renewal using the secret key every now and then or when authenticating a new device.
This, honestly, is a pretty great system. What’s more, it’s universally supported everywhere already. What benefit does passkeys actually provide compared to this?
A shared secret, not a secret key.
I could go on, but I’m sure any search engine could answer this question in great depth.
Passkeys make Sign in via Apple / Google style flows accessible to all without vendor lockin. I look forward to them being better baked.
What do you mean by “passkeys can’t be leaked”? Surely they could theoretically leak if e.g Apple’s passkey syncing service is compromised?
Specifically:
They are not vulnerable to interception. If your browser is compromised or some part of the connection is insecure, for example, and you use a password then that password is visible as plain text. An attacker can copy it and then later, from another machine, log into the service. In contrast, with a pass key the attacker sees only the challenge-response for the current session. They cannot replay that later.
They are not vulnerable to leakage if the server does not store them securely. A lot of systems over the past decades have been compromised and had password databases leak. Some of these were unhashed and so were complete compromises. If you reused a password, other systems may be compromised with it. Even with hashing, older hash schemes are vulnerable to brute force attacks and so attackers can find passwords. With a pass key, the server holds only the public key. Exfiltrating this does not help the attacker (unless they have a quantum computer, but it’s easy to move passkeys to PQC before this becomes a realistic threat).
They cannot be reused. You may have a single secret, but this is used with the remote host name in a key derivation function to provide a unique private key for each service. This prevents impersonation attacks because your key for service X and your key for service Y are guaranteed to be different. If you go to a phishing site and it forwards a challenge from another site, you will sign it with the wrong key and the login will not work.
If Apple’s sync service is compromised, passkeys can leak, but this would have to happen at the point when you set up a new device. The secure elements on the sync’d devices perform a key exchange protocol via iCloud, and with iCloud providing some attestation as to device identity when you enable syncing. The exchanged key is never visible to another device (iCloud can’t intercept it, but it could make your source device do the key exchange with the wrong target. This is similar to a TOS handshake, where iCloud is the certificate signing authority). After this point, iCloud only ever sees cypher text for wrapped keys and so can’t decrypt them even if it is completely compromised (though it could trick users into initiating the sync flow to an untrusted device). I believe the secure elements also have a certificate that’s baked in at device provisioning time so you’d need to also compromise that if you wanted to sync keys to a device that let you extract them, rather than to another Apple device.
Leaked by extraction from some WWW.
I’m talking about passkeys in general. As for Apple, they end-to-end encrypt the transfer of passkeys; so, no, they couldn’t theoretically leak.
For one, this system does not allow a central entity to monitor and disable someone’s access to all their services at once. (you didn’t specify who the benefit should apply to…)
[Comment removed by author]
Hm doesn’t it? Can’t Apple or 1Password delete all my synced passkeys just like they can delete all my synced passwords?
Maybe, but you can also use a local OSS password manager (e.g. keepass).
[Comment removed by author]
Who’s pushing this?
I feel there’s no real way to get onboarded on this technology (is there usable documentation anywhere?) and it probably has relatively extreme failure modes where you can be locked out of stuff entirely.
https://lobste.rs/s/wmu16g/new_passkey_specifications_will_let#c_bjjbwh
IMHO, being able to export passkeys is missing the point of passkeys. They are supposed to be cheap and easy to create so you should be able to set up a passkey for your account on any device/account/browser that you use. If you use an account on a device, just create a passkey on it on demand.
Exporting passkeys would make sense if it was expensive or complex to set them up. I guess it depends on the account provider how easy or difficult they make it, but making it difficult to set up a passkey on a device seems like a great way to kill their adoption.
Expecting people to log into all online services they use and set up a new passkey for each of them when they switch devices is also a great way to kill their adoption, as is expecting them to tie all their logins to a singular account with a sync provider.
I know. That’s why I said they people can do it on an ‘as-needed’ basis, and not pay the entire setup cost up-front. When you need access to an account, log in with an email flow, then set up a passkey. If the app is designed correctly, you should be guided on this flow automatically.
Please define what you mean by “login with an email flow”?
Exactly - or in other words: then how is the email account protected?
Forgot password should NEVER EVER EVER be part of the normal flow. It must always be a thing that you only need to use in emergencies. Having it be part of the normal flow leaves zero margin for error.
There are already many sites out there that default to logging in with email only. Actually, any service that studies their users’ login metrics knows that a significant number of people always use the ‘forgot password’ flow to log in to their account, because they can’t be bothered to even remember a password. They just use the path of least resistance. I’m just suggesting using that as a convenience to set up a passkey on a new device, to create an even easier and more secure auth flow.
Both of those things are widespread systemic failures.
No, that’s just an unforeseen emergent property of a designed system. See also https://en.wikipedia.org/wiki/Desire_path
How so?
Forgot password is a last resort. If that doesn’t work then you’re locked out. You should never need to use it unless there’s an emergency. Switching platforms absolutely does not qualify.
I’m thinking about it in terms of incidents at organizations that cause people to be woken up at night. Forgot password is an escape hatch for that level of severity.
I regard forgot password as just another means of authentication, nothing more or less. And if it was so critical, then it’s a joint that should be well oiled.
Of course ‘forgot password’ is a last resort, I never said otherwise. But users need some way to recover their accounts if they lose access. You can’t just lock them out forever. At least, no sane website is going to do that. You are going to have to offer alternative login methods, and ‘forgot password’ with an email flow happens to be the most common one, which is why I suggested repurposing that as a step towards setting up a much easier and more secure passkey auth. If you have a better alternative than ‘forgot password’ to recover access so the user can log in and set up a passkey, then of course go for it.
Yes you can. Companies are already doing it. Even Google does it. And many companies require 2FA and lock you out if you lose access to your phone number. Some don’t even allow you to setup a third factor for recovery. This is reality and chances are with passkeys it will get worse.
But having a “forgot password’ flow immediately invalidates lots of the arguments in favor of passkeys. E.g. phishing now works. E.g. present the user a fake bank website and show them a message that says “we have updated our security and your old passkey no longer works. It seems your device is unable to do that automatically, so please use the forgot password flow to do so” yadda yadda and we are back to square one.
OK, good luck being a viable business that locks out users forever when (not if) they lose their credentials. IMHO, the risk of the ‘email login’ flow is being greatly overblown when you don’t actually have passwords, only email login and passkeys. First, the malicious actor would have to go to the real bank website, enter your email address, and initiate the email login flow. Then, they would need to immediately send you another email telling you to click on the given link and enter the temporary token from the first email there. Chances are really good that if the temporary token expires in 5 minutes, the intended victim wouldn’t even open these emails in time to enter the token. And even if they did, the first (legit) email from the bank should warn them against entering the token into any other page than the bank’s. And if the attacker floods the victim with a flurry of ‘email login’ emails, anyone would be able to tell something phishy is going on.
I think if you tie this all to a malicious link the user has followed, you can make doing all this a lot smoother. It would depend on egregious user error (entering the code in the box on the phisher’s site that it presented them and told them to post the code in, rather than following the link in the email), but egregious user error will happen some of the time.
How exactly? What’s the flow after the user follows a malicious link?
Realistically, the “forgot password” flow is probably used extremely routinely by most users. And I kind of expect that routine use of passkey re-enrollment flows will become just as common if passkeys catch on. Which means that passkeys can’t be, in practice, any more secure than their re-enrollment flows.
Related: https://lobste.rs/s/uooaw4/email_is_authentication_pattern
Exactly https://lobste.rs/s/wmu16g/new_passkey_specifications_will_let#c_ne7ag1
If you have a passkey on your phone, and your phone gets stolen/hardware dies how do you recover if you haven’t created backup passkeys ahead of time on other devices?
Also how do you migrate passkeys to a new phone from the old one when you upgrade your phone?
In a sane world the service/site you’re trying to use would have ensured you’d created recovery codes or similar. But given we don’t live in a sane world, the option to backup/export passkeys does seem like one I’d like to have :/
Recovery codes are for emergencies, when there’s been a system failure. Using another ecosystem is not an emergency.
Of course, the best place to store account recovery codes is in your password manager, because it should be well maintained with decent security and availability.
So now we again have something that can be phished.
You log in to the account whose passkey was lost with an account recovery method like ‘log in with email’. Then you set up a new passkey on the new device. And, if the app is implemented correctly and lets you manage passkeys properly, you delete the passkey that was on the lost device.
But if you preserve that email flow as an option, you break the benefits of credentials being tied to device hardware, and are back at needing password + second factor + backup second factor.
No you’re not? You can have an email login flow and then use it to set up a passkey on the device. You don’t need password + MFA at all. But you need to offer some way for the user to recover access to their account even if you don’t have passkeys. You can’t just lock users out of their accounts if they forget their credentials. Can you?
No. Please. Stop it. This is actively hostile to users.
I have over 1000 logins. I don’t want to re-enroll passkeys 1000 times per device.
Your objection is based on the fear that re-enrolling is going to be a horrendously complex and slow process. What I am suggesting is to make it a smooth and easy process, almost as natural and quick as logging in with a passkey and Touch ID. If you do this on an as-needed basis, the burden won’t even be noticeable.
Please don’t try to convince me that you need to access your 1000 logins on your new device immediately as soon as you get the new device because you know that’s not true 😉
Not all of them, sure, but any one of them, yes. And there is literally no way to know which of the 1000 you’ll need next. You’re describing a Kafkaesque hellscape of bullshit any time you get a new phone or laptop or something catastrophic happens to one of your OS installations or tokens. It’s completely unnecessary tedium and I hope to god that we’re somehow lucky enough that the people working on the specification actually listen to what people want instead of just being smug and argumentative like you are in the comments here.
I don’t think you need to worry so much; we are literally discussing an article which says that passkeys can be exported. The people working on the specification clearly want this. All I’m saying is that in my opinion exporting passkeys defeats the point of passkeys. If you want the burden of having to manage passkey exports (which are going to get outdated at periodic intervals), that’s on you 🤷♂️
I think it’s important that passkeys provide support for the model you’re describing, because creating private keys inside boxes you can’t remove the keys from (smart cards, HSMs, etc) is a strong security model.
That said, for most people most of the time it’s bloody inconvenient. If you require people to maintain two or more passkeys in every place that they store accounts, and you don’t allow exporting, you’re basically guaranteeing that people will lose access to some of their accounts from time to time. This is basically like backing up your data: the only thing that works for most people most of the time is something automatic like periodic backups to the cloud that they don’t have to remember to do or really manage at all. The more first class the mechanisms for passkey export and portability are, the more likely the end result is something that balances security with the reality of how people actually use their computers, as well as providing some much needed user control of their own data.
No; I’m calling for a model which guarantees users access to their accounts in a simple and secure way in all situations, whether they have a passkey or not, as long as they have access to an email account. Let me detail the flow again, in case it helps:
From the user’s perspective, this process is minimally intrusive, not cumbersome, while still being as secure as possible.
It’s basically the opposite of secure. “Log in via email” emails are sent in plain text out into the world. They’re generally short codes that you copy and paste, which are the thing most likely to be phished from users.
It’s also absolutely cumbersome. To log in I now have to go and find the message in my email, do something with it, delete it. I have to switch between browser tabs and generally screw around. Sometimes mail delivery is not instantaneous. Regular passwords are a thousand times better than this flagrantly user hostile experience, because at least there are mature password managers that integrate with browsers and don’t require anything but a couple of in place clicks on the login page to use.
You’re also ultimately just punting authority to the mail provider for all authentication. It would be better to just demand all websites use OpenID Connect to use your mail provider as an identity provider; at least that would be both secure and convenient for users.
The problem is most people don’t use password managers. Why do you think ‘Have I been Pwned’ exists? It’s because people keep using bad passwords and repeating them in multiple places. In light of actual user behaviours, it turns out that short-lived email tokens (which can be sent via TLS-encrypted email) is more secure than most users’ passwords.
Re: why not just use the email provider as an OIDC. Because (a) not all providers are OIDC-enabled; many people use smaller or ISP-specific emails which don’t have fancy identity provider capabilities. We would like to support them too. And (b) we are talking about email login as a fallback auth flow when you don’t have a passkey set up. Once you do have the passkey set up on the device, you can cut the reliance on any third-party service and just use the passkey.
Passkeys are already synced between e.g Apple devices for people in the Apple ecosystem. Apple may be missing the point of passkeys in your opinion, but the result of not being able to export them is that transferring passkeys between Apple devices is easy, while transferring them to non-Apple devices is impossible.
Mind you, this will only barely improve with this change; it will help people who are transitioning entirely from the Apple ecosystem to some other coherent ecosystem, but it won’t help people keep their keys in sync between their iPhone and their Windows laptop or their Mac and their Android phone. Passkeys remains an amazing tool for Apple to create ecosystem lock-in because they only sync between your iPhone and your Mac.
And I’m saying that allowing transferring passkeys is missing the point of passkeys, which is that they are locked inside the Trusted Platform Module and impossible to extricate, which makes them super-secure. Basically it becomes impossible to be tricked or hacked into giving up the passkey.
If you are allowed to export your passkeys, someone will find a way to trick people into exporting them en masse and leaking them. The article mentions encryption but is light on details so it’s anyone’s guess how secure it will really be.
If you need access on a new device, just set up a passkey on the new device. And possibly delete the one on the old device if that’s desired.
But that becomes a moot point when every service provides access via email with easily-stealable magic links or 6-digit codes.
True, but you have to give the user access to their account some other way otherwise how will they get in to make a passkey in the first place 🤷♂️
At least with links and codes you can caution users against giving them to any other party.
We’re going in circles. Passkeys are already synced between e.g Apple devices for people in the Apple ecosystem. Apple may be missing the point of passkeys in your opinion, but the result of not being able to export them is that transferring passkeys between Apple devices is easy, while transferring them to non-Apple devices is impossible.
Syncing within the Apple ecosystem is an easy problem because Apple can exhaustively enumerate the set of hardware roots of trust that will enforce the required security properties and permit key exchange only with them. This is a much harder problem when arbitrary other RoTs are involved.
1password too, ofc.
Which works cross-platform. I assume Bitwarden will get there too, if they are not already there.
You have repeated your previous comment word for word, I understood you the first time and tried to explain why your premise is incorrect (in my opinion) 🤷♂️
I repeated my previous comment word for word because it applies just as well to your response as it does to your initial comment. In other words, circles.
In general, I would recommend against repeating your comments verbatim in discussions, because it makes it look like you think the other person is an idiot who needs to be told the exact same thing over and over again. Please keep in mind that people who don’t agree with you about something are not idiots, and may have valid arguments and reasoning that you just don’t understand 🤷♂️
No, the point of passkeys is not that they’re in a TPM. The point of passkeys is to replace symmetric shared-secret auth with asymmetric auth.
Whether passkeys are stored in a TPM is an implementation detail. I use 1password which doesn’t use a TPM (but also works on every single one of my devices, which is worth much more than storing keys in a TPM.)
That’s the point for power users like you who use password managers. For ordinary people who don’t, one of the huge benefits of passkeys is that their secret keys are unreachable and so can’t be extracted through trickery.
For someone like you who uses a password manager to store your passkeys, a specification for exporting passkeys is a moot point, it doesn’t impact you either way.
I think that the increase in security that passkeys provide is large enough even without HSM backed private keys. For one you can do that still if you care about that threat model, but I’d argue for most people that trade off isn’t worth it, which is why we see these platforms focusing on sync. I have well over 300 items in my password manager, and while I have been going through and making 2 passkeys where I can, it is quite a pain. I also think the export spec isn’t just a plaintext export of the private keys, theres more too it to that to keep folks from getting tricked into exporting them.
Do you need immediate access to all of the 300 items? No? Then why make all the passkeys for them up front? Just make a passkey on an as-needed basis, when you actually log in to that service?
But this seems to rely on every site that uses passkeys implementing them correctly… whereas I’ve seen several cases where they use passkeys essentially like a password alternative: you get exactly one per account. So now you’re stuck and either need to share the passkey, only ever use that account from one device, or still need a password manager to provide a fallback option.
Yes, it’s possible that some sites don’t implement passkeys correctly. Should we really be papering over their deficiencies, or should we accept that they aren’t going to support passkeys properly and move on?
Without a password manager, how do you do this? I have a number of passkeys saved to my 1password, but without some other form of auth there is no way I could add a new passkey for a new device other than via a usb security key or a password manager with passkey support that lets me bring the passkey to a new machine so I can authenticate and initiate the process of creating a new passkey for that device (but why would I once I have the ability to log in?)
The same way you created the first passkey? Log in to the account with an account recovery method like ‘log in with email’, then create a new passkey once logged in.
There is if the app is implemented correctly and lets you create new passkeys once you log in and go to the security/auth settings. Eg, https://github.com/settings/security#passkeys
Because you might need to do it on a new device where you don’t already have a passkey.
ah, I’m used to dealing with the regime of “once you have a security key, you need that security key 100% of the time i.e. to add an additional security key” that is imposed by my employer
That’s how we do it too, whenever I have a say. They break, lose, forget their MFA sometimes, we require an on-site tech to verify their identity before the tech can delete the MFA and let them login and set it up again. The benefit of having 99.9% of staff on our own campuses and dedicated IT at each one.
What’s passkey again and why it’s needed, besides
big tech privacyarguments?Its not much to do with privacy and its all to do with security. So in that regard:
It stops phishing.
That’s the biggest “need” for it. Which is a pretty good one if you ask me. And it is completely capable of this on paper. Its clear there seems to be issues across the front end and back end of it: massive UX issues and massive implementation issues.
In the general sense, it’s just adding a new way to use public/private key pairs for authentication in browser contexts.
Using public/private key pairs in browser has already been done at least 2 other times:
[Comment removed by author]