There are lots of reasons to like passkeys from a technical/enterprise standpoint, but I do think you’re missing the critical issue the article is speaking to: digital sovereignty.
Passkeys, while more secure in the average usecase, shift the balance of control over your access to services. Yes, you can no longer write your password down on a post-it and leak it in a photo—thats’s a good property. But trading that at the expense of your freedom to run software as you see fit on hardware you bought and paid for? For many people, myself included, that’s not an acceptable tradeoff. There are plenty of tools and systems around passwords that folks can use to make passwords+2FA match or even exceed the security properties of passkeys.
The thing that should chill everyone is the fact that built into the standard is a switch (given to service providers, not users) that locks out the people that do want to have control of their digital infrastructure. Not everyone can or should be expected to run like that, but they should not be blocked from doing so. Similar with the Right to Repair; not everyone can exercise that right on their own, but no one should be prevented from repairing what they bought.
Similary, I do believe it’s my neighbor’s right to practice a religion of their choosing. So if the government tries to prevent them from doing that, I’m going to go grab my pitchfork, not because I share their religion, but because they should be able to make that choice. Likewise, while I might not want to exert control over how my credentials are backed up, I still reserve the right to do it, and support anyone else’s ability to do it.
And to address the slippery slope objection, I have to point out that this is not particularly theoretical. When Big Tech has provided service providers with the opportunity to enforce restrictions on your device, service providers have used it. Widevine DRM, Google Play Protect, etc… It’s why my LineageOS phone can’t use banking apps, which is a shame since some features like Zelle payments are specifically a mobile-only feature, and so I cannot use it anymore. I either run my phone to the exact specs and settings that my bank and Google prefer, or I’m denied access to basic banking anywhere but my desktop (and who knows how long until the block my access there, I run Linux afterall).
I do not trust Big Tech with my devices, and passkeys increase their capability to deny anyone who doesn’t buy into their ecosystem, and further entrenches those who already are. I for one find that despicable, and an unacceptable tradeoff. There’s no reason it has to be this way though, passkeys could have been the best of both worlds. However, they’ve been compromised with features that serve platforms at the expense of user freedom. It’s the kind of disempowerment that happens when you give the reins to power-hungry, profit-seeking corporations.
There are plenty of tools and systems around passwords that folks can use to make passwords+2FA match or even exceed the security properties of passkeys.
Likewise, while I might not want to exert control over how my credentials are backed up, I still reserve the right to do it, and support anyone else’s ability to do it.
Widevine DRM, Google Play Protect, etc…
I do not trust Big Tech with my devices, and passkeys increase their capability to deny anyone who doesn’t buy into their ecosystem
I can only speak for myself, but I hold all of those values you claim. I see no evidence, technical or otherwise, that passkeys are subverting or acting counter to any of these principles. Frankly, it’s a baseless claim that passkeys lock people out of their own control/infrastructure. I think people conflate non-transferable, TPM passkeys with passkeys. Just don’t use that if you don’t want to.
FWIW, passwords were never “yours”, they are PSK (Pre-Shared Key) with a service. Maybe you invented the credential, but it’s not yours. You have historically enjoyed being able to bulk export credentials, and if that property is important to you, then you should be using transferable passkeys. Passkeys have a well-defined transferable format – if they are the type that can be exported.
I can only continue repeating that the passkey spec is public and transparent. If the service is not supporting passkeys in a way that you want to use them, then complain to that service. I don’t decide that service X doesn’t support transferable passkeys, but they should.
DRM and other gate keeping efforts, IMO, are tangential to passkey support. Passkeys are fine, vendor-locking and walled gardens are not.
I see no evidence, technical or otherwise, that passkeys are subverting or acting counter to any of these principles. Frankly, it’s a baseless claim that passkeys lock people out of their own control/infrastructure.
The evidence is in the fact that the passkey standard provides the means to deny service to anyone whose passkeys do not match the service provider’s preferences. This is a non-issue with passwords, since there’s no way for a provider to tell whether or not, for example, a password is simply remembered, stored in your password manager, backed up, shared, etc… The threat model of the user can inform what choices they make there. The platform may require certain things of the password, like length requirments or another factor, but it ends there.
You’re correct in that the standard supports passkeys with similar data sovereignty properties; however, the standard includes controls that allow service providers to dictate that those properties be configured to the provider’s preferences, not the user’s.
Just don’t use [locked down passkeys] if you don’t want to.
It would all be well and good if that were actually entirely my choice, but it’s not. The standard specifically includes a trump card for the service provider in the form of remote attestation. You seem to think that’s tangential, but I reject that. It’s kinda the whole point.
Authenticating based on a shared secret is an interface with a special property: there’s no way for a service provider to know how you remember a secret. That guarantee is extremely important. Service providers accepting password based authentication are guaranteed to not be able to enforce requirements on how you remember your password.
The Passkey standard removes that critical protection by explicitly supporting remote attestation in the standard. It does not matter that the standard is public if it does not preserve that guarantee.
Passkeys are fine, vendor-locking and walled gardens are not.
If you’re not a fan of walled gardens, I would recommend against giving corporations the mortar, bricks, gates, and locks with which they use to build them. Maybe they won’t use them in ways you don’t like, but you’ll never have a guarantee that they won’t.
means to deny service to anyone whose passkeys do not match the service provider’s preferences. This is a non-issue with passwords, since there’s no way for a provider to tell whe
Yes it is. I have had to work with many companies that set password specifications, and sometimes they prevented secure passwords. My bank maxed out at 11 characters for many years!
You dont own the specification for a password, the service provider does. I always wanted to use deterministic password generation (i.e. hash(servicename + memorable password), but never could because every provider has different “password rules” about different character types, etc.
IMO you’re reading way too much into the value proposition of passwords. Services can “deny service” for arbitrary reasons already with zero consequences, but your idea is that they will ban based on… passkeys? You’ve got people banned from youtube for arbitrary comments. You’ve got MS locking out non-profits for arbitrary reasons. But in your mind, those all pale in comparison to what will happen if we all start using passkeys? I’m not buying what you’re selling.
You seem to think that’s tangential, but I reject that. It’s kinda the whole point.
I didn’t say it was tangential. Attestation is for very specific purpose. Non-attested credentials are not sufficient for government and corporate security. I cannot allow BYO hardware to authenticate my users on my services. I highly doubt any public service would require attested passkeys. I doubt passwords will stop being allowed, almost ever, so you probably have nothing to fear. Maybe you can throw that comment back in my face in 20+ years, heh.
Here’s another counter-point: Google, Apple, et. al already implement proprietary authentication mechanisms. Sign-in prompts on recent devices, email codes, etc. are all proprietary. None of these companies killed passwords despite having implemented the tools to do exactly that with vendor lock-in. All the evidence is the opposite. This is one of the first times we’re even getting an open standard authentication, the exact opposite of “walled garden”.
Authenticating based on a shared secret is an interface with a special property: there’s no way for a service provider to know how you remember a secret.
The same special property that allows rampant attacks on the public. I deal with so many people with compromised email inboxes, malware installs, stolen credentials, etc. Passwords are not the end solution to end user security, and I welcome improvements that also simplify UX.
I think we’ve probably hashed out enough of the sides of the argument. Good luck to you.
But in your mind, those all pale in comparison to what will happen if we all start using passkeys? I’m not buying what you’re selling.
Because you appear to be misunderstand what I’m saying. Be careful to not put words in my mouth. I said nothing regarding bans.
I am, however, arguing that a service provider can reject your passkey if they dont like how you manage it, (e.g make it copiable). To access that service using a passkey, you’ll have to accept storing your credential on their terms.
And to be clear, I’m in no way blind to the issues with passwords. We’ve had to tack on a bunch of extras to have password based security keep up, like TOTP, password hashing, recovery methods, phishing resistant tokens, security questions, and so on. I’m not arguing that passwords are perfect; I’m arguing that they preserve the users ultimate control over the credential. I’m totally open and hopeful for improvements to authentication as long as they similarly preserve the user’s freedom to manage their credentials as they see fit.
And this may be where the difference in our values shows, since it appears that you view the user’s freedom as more of a problem than a boon:
The same special property that allows rampant attacks on the public. I deal with so many people with compromised email inboxes, malware installs, stolen credentials, etc. Passwords are not the end solution to end user security, and I welcome improvements that also simplify UX.
I’m sorry you’ve had to deal with that, but I simply don’t think some users making mistakes justifies allowing a service provider to remove a critical freedom from the user. I dont believe that improved UX and security has to come at the cost of user freedom, but that’s what passkeys explicitly allow for by design. I fundamentally disagree with that.
I didn’t say [attestation] was tangential. Attestation is for very specific purpose.
Fair enough, I tend to thow it in the same category as “DRM and other gate-keeping technologies” which you did call “tangential.” At the end of the day, for the purposes of my argument, they are the same: a service wishes to exert control over how a client runs, and I object to such limitions broadly speaking. The computers I own work for me, not the service. (Of course this changes in enterprises that own their own clients, like the workstations used by their workforce. But even in those situations, however, I would argue that there are generally more effective measures than remote attestation. But I digress…)
I highly doubt any public service would require attested passkeys.
Ah, but how can you be sure? You’re missing the guarentee that they can’t flip the script on you. The standard allows them to start forcing users to rotate their passwords and passkeys for ones that require attestation of their preferred settings. Maybe it’s unlikely, but “unlikely” is still a massive downgrade from “impossible.” IMO, it’s unacceptable.
Here’s another counter-point: Google, Apple, et. al already implement proprietary authentication mechanisms. …
Just because a standard is open does not mean it isn’t rigged in the favor of closed platforms. This is especially the case with passkeys, where platforms use them to further entrench you into their ecosystem, often under the guise of “look how good the UX is!” For example, MacOS really, really wants you to tie your passkeys to their keychain, so that they can control how it’s backed up, transferred, and stored. Remote attestation only makes this worse, opening the possibility that a service provider can enforce that you have to use MacOS’s keychain. Sounds like a walled garden to me.
Apologies if I miss-stated your point and conflated service’s other arbitrary decisions with what you’re suggesting may happen with passkeys.
Maybe I have one follow-up question, there are a number of websites that just don’t use passwords at all. It’s always one-time codes sent to emails. Where does this fall on your freedom spectrum?
Do you have similar arguments about HTTP 3? QUIC? Web RTC? There’s so many protocols that could be used in a way to lock in users. Just because it has some bits in the schema, doesn’t really mean much. Particularly when it’s actually supplying a very real need in other contexts. Nobody wants 30 versions of passkey-alt protocols.
FWIW, passwords were never “yours”, they are PSK (Pre-Shared Key) with a service. Maybe you invented the credential, but it’s not yours. You have historically enjoyed being able to bulk export credentials, and if that property is important to you, then you should be using transferable passkeys. Passkeys have a well-defined transferable format – if they are the type that can be exported.
This is the equivalent of Sony arguing that you never owned any games, you owned a license. Congrats. You’re the best kind of correct - technically correct.
There is no flag on a password that determines if it is transferable. There is no amount of “if you don’t like it, don’t use it” that will work out in your favor if you’re not in the majority. If you give corporations the power to limit consumption while increasing prices, they will eventually use it. Especially if they provide a product you can’t get anywhere else (and this is their goal for every product - even if they have to buy other companies to do it - even if they have to collude to offer the same service). It’s the foundation of our entire economic system.
This is the equivalent of Sony arguing that you never owned any games
It’s far from that and bad analogies pollute otherwise very simple conversations. If you want a more apt analogy, this “debate” is shaping up closer to LED vs incandescent bulbs.
It’s easy to say passwords are sufficient when you’re one person practicing good op-sec. It’s not when you’re supporting thousands of people of varying technical proficiency, thousands of machines, thousands of services, and thousands of bad-actors. It was an even simpler time when 4 digit PINs were “sufficient”, but the world you and I live in is more complicated. Certain passkeys are transferable, so you’re not even losing out on that capability. Curmudgeon arguments aren’t convincing. Passkeys aren’t “giving power away”. Using passkeys doesn’t mean your giving up freedom. Passkeys have no bearing on the “economic system” and inflation. As far as the IT ecosystem is concerned, we’ve never lived in a more open and capable time. There are so many alternatives to every service (that isn’t tightly coupled to copyright). Of course companies are trying to offer unique products people can’t get anywhere else. None of this has to do with passkeys.
There are lots of reasons to like passkeys from a technical/enterprise standpoint, but I do think you’re missing the critical issue the article is speaking to: digital sovereignty.
Passkeys, while more secure in the average usecase, shift the balance of control over your access to services. Yes, you can no longer write your password down on a post-it and leak it in a photo—thats’s a good property. But trading that at the expense of your freedom to run software as you see fit on hardware you bought and paid for? For many people, myself included, that’s not an acceptable tradeoff. There are plenty of tools and systems around passwords that folks can use to make passwords+2FA match or even exceed the security properties of passkeys.
The thing that should chill everyone is the fact that built into the standard is a switch (given to service providers, not users) that locks out the people that do want to have control of their digital infrastructure. Not everyone can or should be expected to run like that, but they should not be blocked from doing so. Similar with the Right to Repair; not everyone can exercise that right on their own, but no one should be prevented from repairing what they bought.
Similary, I do believe it’s my neighbor’s right to practice a religion of their choosing. So if the government tries to prevent them from doing that, I’m going to go grab my pitchfork, not because I share their religion, but because they should be able to make that choice. Likewise, while I might not want to exert control over how my credentials are backed up, I still reserve the right to do it, and support anyone else’s ability to do it.
And to address the slippery slope objection, I have to point out that this is not particularly theoretical. When Big Tech has provided service providers with the opportunity to enforce restrictions on your device, service providers have used it. Widevine DRM, Google Play Protect, etc… It’s why my LineageOS phone can’t use banking apps, which is a shame since some features like Zelle payments are specifically a mobile-only feature, and so I cannot use it anymore. I either run my phone to the exact specs and settings that my bank and Google prefer, or I’m denied access to basic banking anywhere but my desktop (and who knows how long until the block my access there, I run Linux afterall).
I do not trust Big Tech with my devices, and passkeys increase their capability to deny anyone who doesn’t buy into their ecosystem, and further entrenches those who already are. I for one find that despicable, and an unacceptable tradeoff. There’s no reason it has to be this way though, passkeys could have been the best of both worlds. However, they’ve been compromised with features that serve platforms at the expense of user freedom. It’s the kind of disempowerment that happens when you give the reins to power-hungry, profit-seeking corporations.
I can only speak for myself, but I hold all of those values you claim. I see no evidence, technical or otherwise, that passkeys are subverting or acting counter to any of these principles. Frankly, it’s a baseless claim that passkeys lock people out of their own control/infrastructure. I think people conflate non-transferable, TPM passkeys with passkeys. Just don’t use that if you don’t want to.
FWIW, passwords were never “yours”, they are PSK (Pre-Shared Key) with a service. Maybe you invented the credential, but it’s not yours. You have historically enjoyed being able to bulk export credentials, and if that property is important to you, then you should be using transferable passkeys. Passkeys have a well-defined transferable format – if they are the type that can be exported.
I can only continue repeating that the passkey spec is public and transparent. If the service is not supporting passkeys in a way that you want to use them, then complain to that service. I don’t decide that service X doesn’t support transferable passkeys, but they should.
DRM and other gate keeping efforts, IMO, are tangential to passkey support. Passkeys are fine, vendor-locking and walled gardens are not.
The evidence is in the fact that the passkey standard provides the means to deny service to anyone whose passkeys do not match the service provider’s preferences. This is a non-issue with passwords, since there’s no way for a provider to tell whether or not, for example, a password is simply remembered, stored in your password manager, backed up, shared, etc… The threat model of the user can inform what choices they make there. The platform may require certain things of the password, like length requirments or another factor, but it ends there.
You’re correct in that the standard supports passkeys with similar data sovereignty properties; however, the standard includes controls that allow service providers to dictate that those properties be configured to the provider’s preferences, not the user’s.
It would all be well and good if that were actually entirely my choice, but it’s not. The standard specifically includes a trump card for the service provider in the form of remote attestation. You seem to think that’s tangential, but I reject that. It’s kinda the whole point.
Authenticating based on a shared secret is an interface with a special property: there’s no way for a service provider to know how you remember a secret. That guarantee is extremely important. Service providers accepting password based authentication are guaranteed to not be able to enforce requirements on how you remember your password.
The Passkey standard removes that critical protection by explicitly supporting remote attestation in the standard. It does not matter that the standard is public if it does not preserve that guarantee.
If you’re not a fan of walled gardens, I would recommend against giving corporations the mortar, bricks, gates, and locks with which they use to build them. Maybe they won’t use them in ways you don’t like, but you’ll never have a guarantee that they won’t.
Yes it is. I have had to work with many companies that set password specifications, and sometimes they prevented secure passwords. My bank maxed out at 11 characters for many years!
You dont own the specification for a password, the service provider does. I always wanted to use deterministic password generation (i.e. hash(servicename + memorable password), but never could because every provider has different “password rules” about different character types, etc.
IMO you’re reading way too much into the value proposition of passwords. Services can “deny service” for arbitrary reasons already with zero consequences, but your idea is that they will ban based on… passkeys? You’ve got people banned from youtube for arbitrary comments. You’ve got MS locking out non-profits for arbitrary reasons. But in your mind, those all pale in comparison to what will happen if we all start using passkeys? I’m not buying what you’re selling.
I didn’t say it was tangential. Attestation is for very specific purpose. Non-attested credentials are not sufficient for government and corporate security. I cannot allow BYO hardware to authenticate my users on my services. I highly doubt any public service would require attested passkeys. I doubt passwords will stop being allowed, almost ever, so you probably have nothing to fear. Maybe you can throw that comment back in my face in 20+ years, heh.
Here’s another counter-point: Google, Apple, et. al already implement proprietary authentication mechanisms. Sign-in prompts on recent devices, email codes, etc. are all proprietary. None of these companies killed passwords despite having implemented the tools to do exactly that with vendor lock-in. All the evidence is the opposite. This is one of the first times we’re even getting an open standard authentication, the exact opposite of “walled garden”.
The same special property that allows rampant attacks on the public. I deal with so many people with compromised email inboxes, malware installs, stolen credentials, etc. Passwords are not the end solution to end user security, and I welcome improvements that also simplify UX.
I think we’ve probably hashed out enough of the sides of the argument. Good luck to you.
Because you appear to be misunderstand what I’m saying. Be careful to not put words in my mouth. I said nothing regarding bans.
I am, however, arguing that a service provider can reject your passkey if they dont like how you manage it, (e.g make it copiable). To access that service using a passkey, you’ll have to accept storing your credential on their terms.
And to be clear, I’m in no way blind to the issues with passwords. We’ve had to tack on a bunch of extras to have password based security keep up, like TOTP, password hashing, recovery methods, phishing resistant tokens, security questions, and so on. I’m not arguing that passwords are perfect; I’m arguing that they preserve the users ultimate control over the credential. I’m totally open and hopeful for improvements to authentication as long as they similarly preserve the user’s freedom to manage their credentials as they see fit.
And this may be where the difference in our values shows, since it appears that you view the user’s freedom as more of a problem than a boon:
I’m sorry you’ve had to deal with that, but I simply don’t think some users making mistakes justifies allowing a service provider to remove a critical freedom from the user. I dont believe that improved UX and security has to come at the cost of user freedom, but that’s what passkeys explicitly allow for by design. I fundamentally disagree with that.
Fair enough, I tend to thow it in the same category as “DRM and other gate-keeping technologies” which you did call “tangential.” At the end of the day, for the purposes of my argument, they are the same: a service wishes to exert control over how a client runs, and I object to such limitions broadly speaking. The computers I own work for me, not the service. (Of course this changes in enterprises that own their own clients, like the workstations used by their workforce. But even in those situations, however, I would argue that there are generally more effective measures than remote attestation. But I digress…)
Ah, but how can you be sure? You’re missing the guarentee that they can’t flip the script on you. The standard allows them to start forcing users to rotate their passwords and passkeys for ones that require attestation of their preferred settings. Maybe it’s unlikely, but “unlikely” is still a massive downgrade from “impossible.” IMO, it’s unacceptable.
Just because a standard is open does not mean it isn’t rigged in the favor of closed platforms. This is especially the case with passkeys, where platforms use them to further entrench you into their ecosystem, often under the guise of “look how good the UX is!” For example, MacOS really, really wants you to tie your passkeys to their keychain, so that they can control how it’s backed up, transferred, and stored. Remote attestation only makes this worse, opening the possibility that a service provider can enforce that you have to use MacOS’s keychain. Sounds like a walled garden to me.
Apologies if I miss-stated your point and conflated service’s other arbitrary decisions with what you’re suggesting may happen with passkeys.
Maybe I have one follow-up question, there are a number of websites that just don’t use passwords at all. It’s always one-time codes sent to emails. Where does this fall on your freedom spectrum?
Do you have similar arguments about HTTP 3? QUIC? Web RTC? There’s so many protocols that could be used in a way to lock in users. Just because it has some bits in the schema, doesn’t really mean much. Particularly when it’s actually supplying a very real need in other contexts. Nobody wants 30 versions of passkey-alt protocols.
Cheers
This is the equivalent of Sony arguing that you never owned any games, you owned a license. Congrats. You’re the best kind of correct - technically correct.
There is no flag on a password that determines if it is transferable. There is no amount of “if you don’t like it, don’t use it” that will work out in your favor if you’re not in the majority. If you give corporations the power to limit consumption while increasing prices, they will eventually use it. Especially if they provide a product you can’t get anywhere else (and this is their goal for every product - even if they have to buy other companies to do it - even if they have to collude to offer the same service). It’s the foundation of our entire economic system.
It’s far from that and bad analogies pollute otherwise very simple conversations. If you want a more apt analogy, this “debate” is shaping up closer to LED vs incandescent bulbs.
It’s easy to say passwords are sufficient when you’re one person practicing good op-sec. It’s not when you’re supporting thousands of people of varying technical proficiency, thousands of machines, thousands of services, and thousands of bad-actors. It was an even simpler time when 4 digit PINs were “sufficient”, but the world you and I live in is more complicated. Certain passkeys are transferable, so you’re not even losing out on that capability. Curmudgeon arguments aren’t convincing. Passkeys aren’t “giving power away”. Using passkeys doesn’t mean your giving up freedom. Passkeys have no bearing on the “economic system” and inflation. As far as the IT ecosystem is concerned, we’ve never lived in a more open and capable time. There are so many alternatives to every service (that isn’t tightly coupled to copyright). Of course companies are trying to offer unique products people can’t get anywhere else. None of this has to do with passkeys.