In my experience, for most basic services, Passkeys are absolute overkill: Your ability to recover your account without too much hassle usually beats having a key explicitely tied to physical hardware (even worse, your phone that you carry around in public). Besides, passkeys are also often used by companies like Microsoft to peddle their apps, because of course you have to have specific apps for it.
Makes me all feel like passkeys are largely a convenient security excuse for vendor lock-in and siphoning personal information. OTP-Generators seem to be more generally applicable and less phone or company-bound.
Passkeys aren't tied to physical hardware. They're tied to your password manager. Passkeys are just passwords that require a password manager.
On Windows, macOS, iOS, and Android, there's a cloud-based password manager built into the operating system, so you can use your passkey anywhere you use that password manager.
Microsoft, Apple, Google, 1Password, and Bitwarden all have password-manager apps for Windows, macOS, iOS, and Android.
Pick a password manager and use the same one everywhere, and your passkeys will be available wherever you go.
Well, unless you have a device-bound or FIDO2 key, according to the post.
And I think for FIDO2 keys, this is fine. If I can register a key (plus a backup) the usage doesn't seem so different from a regular key.
For the rest, I think what irks me is the feeling of "you have free choice which corporation you want to entrust all your login credentials with, but you will have to choose one". Previously, password managers were a convenience (that incidentally also increased security, because they made keeping a separate, hard password for each domain practically feasible) - but nothing stopped me from keeping passwords at several different places at once or memorizing some of them, in case I lose access to the password manager.
Now suddenly, they become the arbiters of my logins everywhere. What happens if they ban me, or go out of business or get bought up? (Or in Apple or Google's case, make arbitrary business decisions that can now affect the way I login to completely unrelated services?)
>even worse, your phone that you carry around in public
Sorry to attach on to such a small part of your comment. Why do you think having it attached to your phone is worse? In my understanding phones are WAY more secure than any run of the mill laptop or desktop due to a variety of security measures like sandboxing, encryption by default, and secure elements. If I came home to a break in I would be way less nervous about them swiping my phone than my desktop.
Personally, I like if not everything is going through my phone.
It can be distracting. You have social media, messages and apps on the same device you need to login. Already makes it harder to put away the phone for a while.
It can never be "cold": You have your phone always with you, which means the risk of it being stolen or lost is higher than with something you can keep in your desk drawer for 99% of the time.
It's a single point of failure: If you should lose it, you potentially have a huge problem: You're right that a thief couldn't make much use of it and we have sophisticated tech to remote-lock and locate phones now. But that won't help you if you need your phone to log into your Google or Apple account to access that tech in the first place.
(Yes, I know there alternative ways to regain access to Apple or Google accounts, but those all rely on you having something... not on your phone)
I don't really own the phone. I know it's paranoid, but I don't like the idea of some update being able to change the way authentication is done. (Even if this is improbable in practice)
At least FIDO2 firmware has a fixed interface.
On the other hand, all the little services I'm building for myself are passwordless and use passkeys with emailed codes for setup/reset.
Passwords were a really poor solution to the problem of security, they didn't take the human factor into account. After a rocky start, I'm now finding passkeys super easy and convenient to use. Far more convenient than OTP codes.
I appreciate that if you're OS/browser doesn't integrate nicely with passwords you might be in for a bad time. I'm having a great time with 1Password, though I believe native apple handles them nicely now too – and I suspect this is true of any modern password manager (even the ones built into the browser).
"Something you have"/"device bound" is not what I want if I don't control it. In the case of passkeys, I don't have access to the private key, so I consider that not controllable by me.
I'm happy to be wrong if I am able to extract and import the private keys (it's what I do with TOTP now), but my understanding is designers of passkeys explicitly don't want users access to their own privkeys so they can tie them to physical objects. I get that, I don't want that.
So passkeys are not something I'll ever use or useful or convenient to me.
Bitwarden lets you extract and import passkeys. Apple, Google, Microsoft, and 1Password don't support that directly, but they do support a finicky app-to-app transfer system, where you install two password-manager apps on the same device, and you directly export your passkeys from one app to another. It's called the "Credential Exchange Protocol" (CXP).
Bitwarden's app can receive CXP passkeys, so you can install a passkey in Apple's password manager, CXP it to Bitwarden, and then export it to a file that you control.
Putting the file under your control does make it possible for someone to trick you into sending you that file, undermining some of the phishing protections of passkeys. It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.
KeypassXC was threatened with blacklisting for deigning to let users access their private keys. Passkey Consortium lackeys will try and reassure you that you have control over your keys, but they are lying through their teeth.
okay but on apple devices (for instance) I believe the private keys are stored in the icloud keychain, otherwise there would be no passkey portability between your apple devices
Passkeys are a solid idea in theory - in practice they are a confusing mess. Basic users are incredibly confused by them. My recommendation still continues to be a very strong password + app based MFA.
I sometimes consider the number of man-hours wasted every year by companies (such as Amazon and Dropbox) that repeatedly offer to convert passwords to passkeys, despite having already been declined (once, or even dozens or hundreds of times).
This reminds me of the number of man-hours wasted on logging in into Microsoft accounts - bonus points for "No, this app only" being hit after the session timeout of the login session so you have to log in _again_. (instead of being able to make that decision any time you like, because, you know, you've already authenticated yourself)
I don't get the passkey hate in the comments. I just store it in Bitwarden, and it syncs across my phone, laptop and desktop. Has been a better experience than passwords
The elevator pitch for passkeys is okay. A bit more complexity than we should be pushing non-technical users, but fine. A deeper dive into the the actual implementation reveals that the whole thing is a massive vendor lock-in hell-hole, pushed by megacorps who want nothing short of complete domination of your life.
First off, sites are extremely pushy about replacing your perfectly good password with a passkey, but then they hide the process for adding additional passkeys, if they offer it all, deep in the settings somewhere. Guess what? That means people locking themselves out of their accounts. All the time. Sites should not be able to choose to only accept 1 passkey. The process of making multiple keys should have been entirely client side. It's nothing short of malpractice to coerce users into setting up exactly 1 passkey.
Second off, the villains in the consortium decided that sites should be able to discriminate about what vaults they want to accept. This is a massive recipe for vendor lock in, and it's already been wielded as cudgel against KeypassXC for having the audacity to let users access their own keys, by threatening to add them to a blacklist. Sites ought to have ZERO say over what vault I use. If I want my vault to be a powershell script with a bunch of hard-coded values, that should have been my prerogative. Instead, you're trusting a bunch of oligopolic assholes to deign your vault acceptable.
It is much, much, much easier for non-technical people to understand the concept of "don't give strangers your passwords" than it is to get them to understand that by giving into the nagging prompts that their email is showing them every single time they log in, they've effectively locked themselves into only ever logging into their email on this computer.
Don't use passkeys, make sure your less-technical peers understand the danger of passkeys, and don't let the holier-than-thou, patronizing ghouls of the consortium spread their propaganda unopposed.
You mean via attestation? If the company that you work for requires you to use a device-bound key, then they should also issue you a FIDO hardware token.
The company I work for requiring device-bound passkeys is the least of my concern. Once the idea of device-bound passkeys being "more secure" gets into the public consciousness as being "more secure" it'll be like the idiotic websites that don't permit pasting into password fields.
People just assume that, but it's not true. If you have access to your Microsoft account, then you'll have access to your Microsoft passkeys in the cloud.
Passkeys are just passwords that require a password manager. You can login to Microsoft with a Microsoft passkey, but that's not the only way to login to your Microsoft account. You can still login to Microsoft with a password.
All password managers require just one last password outside the password manager to access your account. That's how Microsoft's password manager works, too, and that's why you'll always be able to use a password to login to your Microsoft account.
(If you're afraid of Microsoft banning you from your Microsoft account, then don't use Microsoft's password manager. Bitwarden is pretty good.)
Few observations about Passkeys after implementing them for a client...
First, what surprised me is that during the enrollment process, the client is not required to sign a challenge and the server is not required to check it. There's some irony here. Adding this to the flow would be simple layered security, instead of complete reliance on the TLS channel. Something for the Internet Standards people to take into consideration.
Next, passkeys are annoying the way most major websites use them. You can in fact, make a great login experience using passkeys, but not that way capitalone.com Google does (Sorry to pick on you two guys, but it's pretty bad). I won't even mention statefarm.com because their entire website is in a constant state of being javascriptastically broken. Websites treat Passkeys as an accessory, when really it should be the other way around. Passwords, and... sigh, sms, need to be treated as unwelcome accessories.
To make a better user experience:
1: When enrolling a passkey, use the consumers name and permanent business key on your side. Something like `John Doe - PK501867` where PK501867 is an external customer identifier.
2: Lose passwords. Make this a secondary login method on your website, hidden.
3: Don't require SMS "2fA" if they use their passkey. You shouldn't be doing SMS anyway, so stop.
4: Don't use the "well known endpoints" for passkeys or anything related. It's an annoying and confusing consumer experience. Let the user initiate the login. Don't be clever.
5: Instead, just put a button called "Login with Passkey". When they click it, begin the auth flow in the browser. Use async RESTful calls with proper verbs (POST) and correct http signalling. If they authenticate, then redirect. If they don't, update the page but don't cause a navigation.
This by far, keeps the browser 100% functional and follows a natural user experience. It pushes users to use their passkey.
In my experience, for most basic services, Passkeys are absolute overkill: Your ability to recover your account without too much hassle usually beats having a key explicitely tied to physical hardware (even worse, your phone that you carry around in public). Besides, passkeys are also often used by companies like Microsoft to peddle their apps, because of course you have to have specific apps for it.
Makes me all feel like passkeys are largely a convenient security excuse for vendor lock-in and siphoning personal information. OTP-Generators seem to be more generally applicable and less phone or company-bound.
Passkeys aren't tied to physical hardware. They're tied to your password manager. Passkeys are just passwords that require a password manager.
On Windows, macOS, iOS, and Android, there's a cloud-based password manager built into the operating system, so you can use your passkey anywhere you use that password manager.
Microsoft, Apple, Google, 1Password, and Bitwarden all have password-manager apps for Windows, macOS, iOS, and Android.
Pick a password manager and use the same one everywhere, and your passkeys will be available wherever you go.
Well, unless you have a device-bound or FIDO2 key, according to the post.
And I think for FIDO2 keys, this is fine. If I can register a key (plus a backup) the usage doesn't seem so different from a regular key.
For the rest, I think what irks me is the feeling of "you have free choice which corporation you want to entrust all your login credentials with, but you will have to choose one". Previously, password managers were a convenience (that incidentally also increased security, because they made keeping a separate, hard password for each domain practically feasible) - but nothing stopped me from keeping passwords at several different places at once or memorizing some of them, in case I lose access to the password manager.
Now suddenly, they become the arbiters of my logins everywhere. What happens if they ban me, or go out of business or get bought up? (Or in Apple or Google's case, make arbitrary business decisions that can now affect the way I login to completely unrelated services?)
>even worse, your phone that you carry around in public
Sorry to attach on to such a small part of your comment. Why do you think having it attached to your phone is worse? In my understanding phones are WAY more secure than any run of the mill laptop or desktop due to a variety of security measures like sandboxing, encryption by default, and secure elements. If I came home to a break in I would be way less nervous about them swiping my phone than my desktop.
Personally, I like if not everything is going through my phone.
It can be distracting. You have social media, messages and apps on the same device you need to login. Already makes it harder to put away the phone for a while.
It can never be "cold": You have your phone always with you, which means the risk of it being stolen or lost is higher than with something you can keep in your desk drawer for 99% of the time.
It's a single point of failure: If you should lose it, you potentially have a huge problem: You're right that a thief couldn't make much use of it and we have sophisticated tech to remote-lock and locate phones now. But that won't help you if you need your phone to log into your Google or Apple account to access that tech in the first place.
(Yes, I know there alternative ways to regain access to Apple or Google accounts, but those all rely on you having something... not on your phone)
I don't really own the phone. I know it's paranoid, but I don't like the idea of some update being able to change the way authentication is done. (Even if this is improbable in practice) At least FIDO2 firmware has a fixed interface.
Passkeys “done right” via Apple Keychain however it does it seems to work well enough for the normies.
Being able to sign in with touchID is amazing
On the other hand, all the little services I'm building for myself are passwordless and use passkeys with emailed codes for setup/reset.
Passwords were a really poor solution to the problem of security, they didn't take the human factor into account. After a rocky start, I'm now finding passkeys super easy and convenient to use. Far more convenient than OTP codes.
I appreciate that if you're OS/browser doesn't integrate nicely with passwords you might be in for a bad time. I'm having a great time with 1Password, though I believe native apple handles them nicely now too – and I suspect this is true of any modern password manager (even the ones built into the browser).
"Something you have"/"device bound" is not what I want if I don't control it. In the case of passkeys, I don't have access to the private key, so I consider that not controllable by me.
I'm happy to be wrong if I am able to extract and import the private keys (it's what I do with TOTP now), but my understanding is designers of passkeys explicitly don't want users access to their own privkeys so they can tie them to physical objects. I get that, I don't want that.
So passkeys are not something I'll ever use or useful or convenient to me.
Bitwarden lets you extract and import passkeys. Apple, Google, Microsoft, and 1Password don't support that directly, but they do support a finicky app-to-app transfer system, where you install two password-manager apps on the same device, and you directly export your passkeys from one app to another. It's called the "Credential Exchange Protocol" (CXP).
Bitwarden's app can receive CXP passkeys, so you can install a passkey in Apple's password manager, CXP it to Bitwarden, and then export it to a file that you control.
Putting the file under your control does make it possible for someone to trick you into sending you that file, undermining some of the phishing protections of passkeys. It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.
KeypassXC was threatened with blacklisting for deigning to let users access their private keys. Passkey Consortium lackeys will try and reassure you that you have control over your keys, but they are lying through their teeth.
If you're using a hardware device, you can't extract them, because that's the point.
If you're using a password manager to store your passkeys, there are protocols to move them between password managers.
okay but on apple devices (for instance) I believe the private keys are stored in the icloud keychain, otherwise there would be no passkey portability between your apple devices
Passkeys are a solid idea in theory - in practice they are a confusing mess. Basic users are incredibly confused by them. My recommendation still continues to be a very strong password + app based MFA.
I sometimes consider the number of man-hours wasted every year by companies (such as Amazon and Dropbox) that repeatedly offer to convert passwords to passkeys, despite having already been declined (once, or even dozens or hundreds of times).
This reminds me of the number of man-hours wasted on logging in into Microsoft accounts - bonus points for "No, this app only" being hit after the session timeout of the login session so you have to log in _again_. (instead of being able to make that decision any time you like, because, you know, you've already authenticated yourself)
I don't get the passkey hate in the comments. I just store it in Bitwarden, and it syncs across my phone, laptop and desktop. Has been a better experience than passwords
The elevator pitch for passkeys is okay. A bit more complexity than we should be pushing non-technical users, but fine. A deeper dive into the the actual implementation reveals that the whole thing is a massive vendor lock-in hell-hole, pushed by megacorps who want nothing short of complete domination of your life.
First off, sites are extremely pushy about replacing your perfectly good password with a passkey, but then they hide the process for adding additional passkeys, if they offer it all, deep in the settings somewhere. Guess what? That means people locking themselves out of their accounts. All the time. Sites should not be able to choose to only accept 1 passkey. The process of making multiple keys should have been entirely client side. It's nothing short of malpractice to coerce users into setting up exactly 1 passkey.
Second off, the villains in the consortium decided that sites should be able to discriminate about what vaults they want to accept. This is a massive recipe for vendor lock in, and it's already been wielded as cudgel against KeypassXC for having the audacity to let users access their own keys, by threatening to add them to a blacklist. Sites ought to have ZERO say over what vault I use. If I want my vault to be a powershell script with a bunch of hard-coded values, that should have been my prerogative. Instead, you're trusting a bunch of oligopolic assholes to deign your vault acceptable.
It is much, much, much easier for non-technical people to understand the concept of "don't give strangers your passwords" than it is to get them to understand that by giving into the nagging prompts that their email is showing them every single time they log in, they've effectively locked themselves into only ever logging into their email on this computer.
Don't use passkeys, make sure your less-technical peers understand the danger of passkeys, and don't let the holier-than-thou, patronizing ghouls of the consortium spread their propaganda unopposed.
One note: Organisations can chose to have device-bound passkeys, so Bit warden would no longer be a valid passkey store.
You mean via attestation? If the company that you work for requires you to use a device-bound key, then they should also issue you a FIDO hardware token.
The company I work for requiring device-bound passkeys is the least of my concern. Once the idea of device-bound passkeys being "more secure" gets into the public consciousness as being "more secure" it'll be like the idiotic websites that don't permit pasting into password fields.
No, not via attestation. That's a different concept. Device-bound just ensures they passkey stays on the device where it was created.
Bit warden in that sense is not device-bound but synced.
For a company this may be a good idea, but for consumers this is a nightmare. It will be so easy to get locked out of your account.
People just assume that, but it's not true. If you have access to your Microsoft account, then you'll have access to your Microsoft passkeys in the cloud.
Passkeys are just passwords that require a password manager. You can login to Microsoft with a Microsoft passkey, but that's not the only way to login to your Microsoft account. You can still login to Microsoft with a password.
All password managers require just one last password outside the password manager to access your account. That's how Microsoft's password manager works, too, and that's why you'll always be able to use a password to login to your Microsoft account.
(If you're afraid of Microsoft banning you from your Microsoft account, then don't use Microsoft's password manager. Bitwarden is pretty good.)
Few observations about Passkeys after implementing them for a client...
First, what surprised me is that during the enrollment process, the client is not required to sign a challenge and the server is not required to check it. There's some irony here. Adding this to the flow would be simple layered security, instead of complete reliance on the TLS channel. Something for the Internet Standards people to take into consideration.
Next, passkeys are annoying the way most major websites use them. You can in fact, make a great login experience using passkeys, but not that way capitalone.com Google does (Sorry to pick on you two guys, but it's pretty bad). I won't even mention statefarm.com because their entire website is in a constant state of being javascriptastically broken. Websites treat Passkeys as an accessory, when really it should be the other way around. Passwords, and... sigh, sms, need to be treated as unwelcome accessories.
To make a better user experience:
1: When enrolling a passkey, use the consumers name and permanent business key on your side. Something like `John Doe - PK501867` where PK501867 is an external customer identifier.
2: Lose passwords. Make this a secondary login method on your website, hidden.
3: Don't require SMS "2fA" if they use their passkey. You shouldn't be doing SMS anyway, so stop.
4: Don't use the "well known endpoints" for passkeys or anything related. It's an annoying and confusing consumer experience. Let the user initiate the login. Don't be clever.
5: Instead, just put a button called "Login with Passkey". When they click it, begin the auth flow in the browser. Use async RESTful calls with proper verbs (POST) and correct http signalling. If they authenticate, then redirect. If they don't, update the page but don't cause a navigation.
This by far, keeps the browser 100% functional and follows a natural user experience. It pushes users to use their passkey.
wordy ad
Good point.
whatever it takes to kill sms mfa.
[dead]