5 ms·

Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.) Bitwarden is one of the few that

Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.) Bitwarden is one of the few that don’t - you can export passkeys, although for now, there’s nothing to import them to unless you want to run a roll your own open source solution.

growse 2y ago
> Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.) Does this mean that any HSM where inability to export the private key is a feature is also doing it for "vendor lockin" reasons?
- redserk 2y ago
  If you’re buying and implementing a HSM, you really ought to understand this concept. After all, you’re getting paid to. I do not expect random consumers to understand this concept. It’s grossly irresponsible and is simply user abuse. I love Passkeys. They’re fantastic. I do not love how unportable the implementations for Average Joe and Jane are.
- fireflash38 2y ago
  It's both. Most of those vendors have ways to backup those keys securely to same vendor backup product. But they won't let you export them via a wrap or whatever. It functions both as a security feature and a vendor lock in.
  - EvanAnderson 2y ago
    It's absolutely vendor lock-in, first and foremost. It happens to align with security. I did a project 10 years ago to sign firmware for embedded devices w/ a planned 25 year product life. I spoke with two different HSM vendors. Both said the Customer would be able to backup and transfer keys from one HSM to another. Both also said that was applicable within their products only. There was no mechanism to switch to another HSM vendor (and neither offered a contingency to get the keys out if the vendor ceased business operations). Apparently this situation has gotten no better in the last 10 years: https://www.icann.org/en/system/files/files/hardware-security-module-replacement-2024-28feb24-en.pdf https://www.icann.org/en/system/files/files/hardware-securit... > In April 2023, IANA became aware of the decision by the manufacturer of the Keyper PLUS HSM – the equipment used to store private key materials for the Root Zone KSK – to cease its production of the device. Furthermore, the manufacturer will offer no successor product. That's ridiculous. There should be a standards-based protocol to transfer key material between HSMs. It should be tied to physical access using physical tokens. Make the protocol baroque and difficult. Heck, even make it a requirement the source HSM has to to be physically destroyed to complete the process (to prevent "cloning" attacks). For USB authentication keys this level of cloak-and-dagger LARPing is stupid. There should be a method to export and encrypted copy of the contents of my USB token and, worst case, import it into another token manufactured by the same provider. ("But cloning!" Fine-- tie it to registering the token with the manufacturer along with real-world identity verification. Make it a premium service with an associated cost, if that's what it takes.)
- 2OEH8eoCRo0 2y ago
  A YubiKey is not an HSM
  - trollbridge 2y ago
    A YubiKey is a tiny computer that runs Linux and a built in app… much like most HSMs.
- croes 2y ago
  It’s one of the reasons
eigenspace 2y ago
Import and export of passkeys is coming "soon" to 1Password (as of October): https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/ https://blog.1password.com/fido-alliance-import-export-passk... I think some vendors do have intentions of locking in users with passkeys (*cough* Apple *cough*), but I also think it's also not the only explanation for why import and export isn't supported by most managers. A more charitable explanation would be that since passkeys are 'new', there's less people demanding import/export since they have very few passkeys to move around, and at least some vendors wanted to take time to develop a good solution for it / focus resources on actually getting the daily usage of passkeys working.
thugcee 2y ago
KeePassXC imports passkeys from Bitwarden: https://github.com/keepassxreboot/keepassxc/pull/11401/files https://github.com/keepassxreboot/keepassxc/pull/11401/files
- trollbridge 2y ago
  KeePassXC and BitWarden win the award for the only open platforms, then. (And BitWarden isn’t even “free software”!)
batata_frita 2y ago
Vendor Locking-In should be classified as an anti competitive practice. The year is 2025 (almost), and we're still suffering with companies closed garden syndrome.
criddell 2y ago
Don't most sites let you create multiple passkeys which would avoid lockin?
- croes 2y ago
  Imagine you switch from iOS to Android, now you need to create a new one for every site that need uses passkeys. Not to mention the hassle if you forgot one.
  - WorldMaker 2y ago
    In most cases it is as simple as: Download the Apple Passwords app on Windows and use it to login to that site on Chrome and then add a new "Google Passkey" in Chrome. It is a hassle, and the UX isn't entirely there today to make it feel "easy" or "seamless", but it is a simple hassle, relatively.
    - recursive 2y ago
      So you have to get a windows machine to switch to android? That doesn't sound like a solution.
      - WorldMaker 2y ago
        No that's just assuming the 70%+ case "average part of the bell curve" where a user switching iOS to Android already has a Windows machine somewhere. Remove the install step of the Apple Passwords app in the rarer case that the user has a Mac or iPad as their primary "other device". (If the hypothetical user was using Linux machines already by that point, they wouldn't have been using iOS Keychain for their Passkeys in the first place and probably would have the necessary skills or tech guru friend to load up Apple Passwords in a WINE session or in a Windows VM/dual boot.) All else fails, there's always most sites will continue to (forever) fallback to email-based recovery because we should all face it that email accounts have been the average user's primary password manager for decades anyway.
jamesboehmer 2y ago
It may partially be because of vendor lock-in, but I think the real reason is security. For example with Apple's Secure Enclave hardware, you give secret-generation responsibility to this chip, and can never see the value. I use it for SSH private keys, which are meant to be disposable/changeable. As much as I want to own and control all my data, I personally think this is pretty good footgun protection, and I'm ok with being unable to export my passkeys from 1password (and for the record, 1password does not prohibit TOTP exports).
- deleted 2y ago
  [deleted]
- trollbridge 2y ago
  If the private key is actually stored in an unbeatable enclave, then fine. Apple’s implementation puts them in your iCloud account, which whilst it is overall locked via the Secure Enclave, the passkeys are most certainly not. I don’t have a need for a level of security where exporting my private key to, say, Best Buy is impossible.
Borealid 2y ago
This is extremely obvious in the new FIDO specification for key export, where they neglect to specify the format in which the private keys are encoded. In other words, it's a "standard" designed to let Apple, Google, and Microsoft enable portability between each other, but to keep software like KeePass out of the mix.
- lxgr 2y ago
  This really is the least problem. As long as the key export API isn't actually gated (e.g. by only working over a backend-to-backend API with a mandatory "security audit" to gain access, by wrapping exported keys using vendor-specific keys and requiring a similar audit to be included as an export target etc.), everything else can be figured out. There's only so many ways you can encode an ECDSA key.
- comex 2y ago
  Isn’t that here? https://fidoalliance.org/specs/cx/cxf-v1.0-wd-20241003.html#dict-passkey https://fidoalliance.org/specs/cx/cxf-v1.0-wd-20241003.html#... The private key is specified as being a “PKCS#8 formatted byte string which is then Base64url encoded”. Is that insufficient?
daft_pink 2y ago
I believe they are trying to make a common import/export mechanism to prevent vendor lock in.
cchance 2y ago
I mean... i register in my most common one, and if i cant use that passkey store on another pc like at work... i just ... register another passkey there, you do it once an your done, once at home and once at work,
Groxx 2y ago
Not just "most passkey stores". The spec has nothing about export/sync, so they've been working around it by hand. There is a process of drafting a decision to put before the committee to change this ~now[1], but tbh I think the omission from v1 is a strong sign that the omission is literally intentional. I'm sure spec authors will disagree, as I am sure that many are well-meaning... but there are very strong incentives for the current giga-corps to impede and complicate it during design phases, as they are now doing to the UX. If backups and device-loss considerations for such intensely personal data is not baked in, simply, and mandated from day 1, it's intentional by someone. [1]: https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/ https://blog.1password.com/fido-alliance-import-export-passk...
Nekit1234007 2y ago
One of the Passkeys/WebAuthn spec people made a huge fuss over how KeePassXC did their export function https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407
- deleted 2y ago
  [deleted]

growse 2y ago

> Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.) Does this mean that any HSM where inability to export the private key is a feature is also doing it for "vendor lockin" reasons?

redserk 2y ago
If you’re buying and implementing a HSM, you really ought to understand this concept. After all, you’re getting paid to. I do not expect random consumers to understand this concept. It’s grossly irresponsible and is simply user abuse. I love Passkeys. They’re fantastic. I do not love how unportable the implementations for Average Joe and Jane are.
fireflash38 2y ago
It's both. Most of those vendors have ways to backup those keys securely to same vendor backup product. But they won't let you export them via a wrap or whatever. It functions both as a security feature and a vendor lock in.
- EvanAnderson 2y ago
  It's absolutely vendor lock-in, first and foremost. It happens to align with security. I did a project 10 years ago to sign firmware for embedded devices w/ a planned 25 year product life. I spoke with two different HSM vendors. Both said the Customer would be able to backup and transfer keys from one HSM to another. Both also said that was applicable within their products only. There was no mechanism to switch to another HSM vendor (and neither offered a contingency to get the keys out if the vendor ceased business operations). Apparently this situation has gotten no better in the last 10 years: https://www.icann.org/en/system/files/files/hardware-security-module-replacement-2024-28feb24-en.pdf https://www.icann.org/en/system/files/files/hardware-securit... > In April 2023, IANA became aware of the decision by the manufacturer of the Keyper PLUS HSM – the equipment used to store private key materials for the Root Zone KSK – to cease its production of the device. Furthermore, the manufacturer will offer no successor product. That's ridiculous. There should be a standards-based protocol to transfer key material between HSMs. It should be tied to physical access using physical tokens. Make the protocol baroque and difficult. Heck, even make it a requirement the source HSM has to to be physically destroyed to complete the process (to prevent "cloning" attacks). For USB authentication keys this level of cloak-and-dagger LARPing is stupid. There should be a method to export and encrypted copy of the contents of my USB token and, worst case, import it into another token manufactured by the same provider. ("But cloning!" Fine-- tie it to registering the token with the manufacturer along with real-world identity verification. Make it a premium service with an associated cost, if that's what it takes.)
2OEH8eoCRo0 2y ago
A YubiKey is not an HSM
- trollbridge 2y ago
  A YubiKey is a tiny computer that runs Linux and a built in app… much like most HSMs.
croes 2y ago
It’s one of the reasons

eigenspace 2y ago

Import and export of passkeys is coming "soon" to 1Password (as of October): https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/ https://blog.1password.com/fido-alliance-import-export-passk... I think some vendors do have intentions of locking in users with passkeys (*cough* Apple *cough*), but I also think it's also not the only explanation for why import and export isn't supported by most managers. A more charitable explanation would be that since passkeys are 'new', there's less people demanding import/export since they have very few passkeys to move around, and at least some vendors wanted to take time to develop a good solution for it / focus resources on actually getting the daily usage of passkeys working.

thugcee 2y ago

KeePassXC imports passkeys from Bitwarden: https://github.com/keepassxreboot/keepassxc/pull/11401/files https://github.com/keepassxreboot/keepassxc/pull/11401/files

trollbridge 2y ago
KeePassXC and BitWarden win the award for the only open platforms, then. (And BitWarden isn’t even “free software”!)

batata_frita 2y ago

Vendor Locking-In should be classified as an anti competitive practice. The year is 2025 (almost), and we're still suffering with companies closed garden syndrome.

criddell 2y ago

Don't most sites let you create multiple passkeys which would avoid lockin?

croes 2y ago
Imagine you switch from iOS to Android, now you need to create a new one for every site that need uses passkeys. Not to mention the hassle if you forgot one.
- WorldMaker 2y ago
  In most cases it is as simple as: Download the Apple Passwords app on Windows and use it to login to that site on Chrome and then add a new "Google Passkey" in Chrome. It is a hassle, and the UX isn't entirely there today to make it feel "easy" or "seamless", but it is a simple hassle, relatively.
  - recursive 2y ago
    So you have to get a windows machine to switch to android? That doesn't sound like a solution.
    - WorldMaker 2y ago
      No that's just assuming the 70%+ case "average part of the bell curve" where a user switching iOS to Android already has a Windows machine somewhere. Remove the install step of the Apple Passwords app in the rarer case that the user has a Mac or iPad as their primary "other device". (If the hypothetical user was using Linux machines already by that point, they wouldn't have been using iOS Keychain for their Passkeys in the first place and probably would have the necessary skills or tech guru friend to load up Apple Passwords in a WINE session or in a Windows VM/dual boot.) All else fails, there's always most sites will continue to (forever) fallback to email-based recovery because we should all face it that email accounts have been the average user's primary password manager for decades anyway.

jamesboehmer 2y ago

It may partially be because of vendor lock-in, but I think the real reason is security. For example with Apple's Secure Enclave hardware, you give secret-generation responsibility to this chip, and can never see the value. I use it for SSH private keys, which are meant to be disposable/changeable. As much as I want to own and control all my data, I personally think this is pretty good footgun protection, and I'm ok with being unable to export my passkeys from 1password (and for the record, 1password does not prohibit TOTP exports).

deleted 2y ago
[deleted]
trollbridge 2y ago
If the private key is actually stored in an unbeatable enclave, then fine. Apple’s implementation puts them in your iCloud account, which whilst it is overall locked via the Secure Enclave, the passkeys are most certainly not. I don’t have a need for a level of security where exporting my private key to, say, Best Buy is impossible.

Borealid 2y ago

This is extremely obvious in the new FIDO specification for key export, where they neglect to specify the format in which the private keys are encoded. In other words, it's a "standard" designed to let Apple, Google, and Microsoft enable portability between each other, but to keep software like KeePass out of the mix.

lxgr 2y ago
This really is the least problem. As long as the key export API isn't actually gated (e.g. by only working over a backend-to-backend API with a mandatory "security audit" to gain access, by wrapping exported keys using vendor-specific keys and requiring a similar audit to be included as an export target etc.), everything else can be figured out. There's only so many ways you can encode an ECDSA key.
comex 2y ago
Isn’t that here? https://fidoalliance.org/specs/cx/cxf-v1.0-wd-20241003.html#dict-passkey https://fidoalliance.org/specs/cx/cxf-v1.0-wd-20241003.html#... The private key is specified as being a “PKCS#8 formatted byte string which is then Base64url encoded”. Is that insufficient?

daft_pink 2y ago

I believe they are trying to make a common import/export mechanism to prevent vendor lock in.

cchance 2y ago

I mean... i register in my most common one, and if i cant use that passkey store on another pc like at work... i just ... register another passkey there, you do it once an your done, once at home and once at work,

Groxx 2y ago

Not just "most passkey stores". The spec has nothing about export/sync, so they've been working around it by hand. There is a process of drafting a decision to put before the committee to change this ~now[1], but tbh I think the omission from v1 is a strong sign that the omission is literally intentional. I'm sure spec authors will disagree, as I am sure that many are well-meaning... but there are very strong incentives for the current giga-corps to impede and complicate it during design phases, as they are now doing to the UX. If backups and device-loss considerations for such intensely personal data is not baked in, simply, and mandated from day 1, it's intentional by someone. [1]: https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/ https://blog.1password.com/fido-alliance-import-export-passk...

Nekit1234007 2y ago

One of the Passkeys/WebAuthn spec people made a huge fuss over how KeePassXC did their export function https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407

deleted 2y ago
[deleted]