8 ms·
From the FAQ [1]: > Q: Are stored passkeys included in Bitwarden imports and exports? > A: Passkeys are not included in imports and exports. I think it's the
by yonixw 3y ago
From the FAQ [1]:
> Q: Are stored passkeys included in Bitwarden imports and exports?
> A: Passkeys are not included in imports and exports.
I think it's the same for iCloud [2]. That is why I don't love it. I prefer a very long password, and Bitwarden "Device login" that will prompt in my iPhone that will require FaceID (So essentially I have bio login). And 2FA to lower hacking chances. I'm aware I'm still vulnerable to phishing but because there is no export, this is a marriage to Bitwarden. And as much as I love them... I'm not ready yet.
But essentially it's a certificate... so I wonder why no private key export? Maybe because current implementation uses some CA that binds you to the issuer?
[1] https://bitwarden.com/help/storing-passkeys/ https://bitwarden.com/help/storing-passkeys/
[2] https://redd.it/143acl5 https://redd.it/143acl5
- emptysongglass 3y agoIs this true for all of the incumbent password managers? If so, it seems like the worst of software lock-in.
- camkego 3y agoIt does seem like a real "lock-in" move.
- eviks 3y agowhat's the phishing risk if bitwarden autofills only on the correct domains stored in the vault?
- vorpalhex 3y agoMobile apps, slightly tweaky domain names (which happens normally), much less fancy xss type attacks, plus general data exfil.
- eviks 3y agoMobile BW app also wouldn't fill a password for a different domain
- deleted 3y ago[deleted]
- kiwijamo 3y agoCan confirm this. Additionally, the Bitwarden app on mobiles also checks the app name (i.e. the 'com.company.appname' not the 'user friendly' name). It takes an extra step to 'force' Bitwarden to use a username/password if the name/domain does not match the name/domain(s) recorded against the username/password which adds a nice bit of friction.
- lxgr 3y agoThere not even being an extra step is still much safer, no?
- vorpalhex 3y agoIf I can't get my password thing to autofill on a mobile app (because the mobile app is on a different domain) then it's just annoying because I have to copy and paste over secrets. That's the wrong thing twice over. The password app should be as useful to me as a user as it can while still helping me be safe. "Hey, we can't confirm these creds are correct for this app. Do you still want to proceed?"
- eviks 3y agoOr you can add another domain, saving users from easy buttons "yes, phish me anyway" is also useful
- josteink 3y ago> what's the phishing risk if bitwarden autofills only on the correct domains stored in the vault? The whole point of passkeys is that they should be tied to a specific domain, and thus be nonphisable. If Bitwarden allows reuse for different domains, that would be (as I understand it) a violation of the spec and a bug in their implementation.
- eviks 3y agoThe question was about the password alternative the op was describing
- kiwijamo 3y agoSilly question perhaps, but what happens if a certain website changes to a different domain. E.g. a takeover of Company B by Company A who then decides to migrate all Company B passkeys to Company A and removes assets hosted under the Company B domain. This is easily sorted with existing tools but with passkeys... how?
- pests 3y agoIf they had time to prepare I'm sure they could develop a flow to get you a passkey on the new domain first. Similar to how YouTube used to do a bunch of cross-domain redirects (to plant cookies) to get Google+ login support back in the day.
- neurostimulant 3y agoYou might not get a head up when you're forced to change your domain though. For example, recently a huge number of .ml domains are dead and people that used them must scramble to migrate to another domain. The problem is some apps like mastodon (and now passkey) don't support changing domains unless the old domain is still accessible.
- lxgr 3y agoIt still wouldn't be a security problem, since WebAuthN includes the hash of the visited domain in the signature. So even if Bitwarden would go blatantly out of spec and allow usage of a passkey created on and scoped to a.com on b.com, the assertion signature would effectively say "I want to login to b.com", which a.com would simply reject. That's what makes it so much harder to phish than auto-filled passwords (which could still be MITMed e.g. through usage of attacker-installed TLS certificates).
- imran-iq 3y agoThat's really a shame, I know keepassxc has (recently) added support for passkeys, but does it also support import/exporting them? I only found this comment[0] in the github issue. EDIT: According to the pr[1] it does support import/export --- 0: https://github.com/keepassxreboot/keepassxc/issues/1870#issuecomment-1295812344 https://github.com/keepassxreboot/keepassxc/issues/1870#issu... 1: https://github.com/keepassxreboot/keepassxc/pull/8825 https://github.com/keepassxreboot/keepassxc/pull/8825
- jerf 3y agoI hope they get over that. It's a blob of data. It's no more special than a TOTP secret or a conventional password, and I am completely uninterested in pretending otherwise because of a slick marketing campaign. It's a "thing I know" whether anybody likes it or not and you can't turn it into a "thing I have" just because you won't let me export it from this particular software. (Proof that it is a "thing I know": It fits into Bitwarden, which is a "thing I know" storage mechanism. Anything that can be stored by BitWarden is a thing-I-know.) As long as it's a thing I know you might as well give me the benefits of being a thing I know, since I'm paying the costs of it anyhow. I back up at the Vaultwarden backend store level anyhow. Probably shouldn't give me that sort of advantage over the commercial option.
- SheinhardtWigCo 3y agoIt is special - it should be a reference to an asymmetric key stored in hardware. But it's not clear whether they are actually doing this.
- SV_BubbleTime 3y agoIf it is just a pointer a hardware, even more reason to let you export it.
- m-p-3 3y agoThe idea is that the key never, EVER leave the hardware or password manager. What you do is have multiple Passkeys on separate devices per account. Kind of like how you should generate SSH private keys on the local machine and never leave this particular system, and you then add their public keys to the server you will connect to. You can them revoke access to each machine independently.
- ryan29 3y agoSome snippets from the FAQ [1]. > The public key is stored on the website and the private key is stored on your device or in your passkey provider, e.g. your Bitwarden Vault. > Passkeys are often able to sync across your devices, however not all platforms support this yet. So it sounds like it's not stored in hardware. It'll be interesting to see how it works if solutions that use a TPM or similar start to emerge. I have nearly 1000 passwords and many of them are shared with colleagues, parents, siblings, etc.. I can't even imagine a way you could make that work if the private key is owned by a TPM (aka a hardware bound key) and needs to be enrolled somehow prior to becoming usable. What happens if I have 500 passkeys backed by keys in a TPM and I get a new computer? 1. https://bitwarden.com/resources/passkeys-faq/ https://bitwarden.com/resources/passkeys-faq/
- SheinhardtWigCo 3y agoYou're not really vulnerable to phishing if you use a password manager with a browser extension. Cross-platform import/export for passkeys is considered a "nice-to-have" because you can always just add a new device via other established factors (email/SMS). So, what's the point, then? Why can't passkeys just be strings that I can extract via biometric authentication? The answer: everyone pushing this has a significant interest in making it harder to migrate between operating systems and password managers. It's a land grab.
- jiveturkey 3y agohttps://matduggan.com/passkeys-as-a-tool-for-user-retention/ https://matduggan.com/passkeys-as-a-tool-for-user-retention/ > It is also, as currently implemented, one of the most effective platform lock-ins I've ever seen.
- lxgr 3y ago> Why can't passkeys just be strings that I can extract via biometric authentication? As much as that lock-in annoys me personally – I could absolutely see this become a tech support scam attack vector. "Please share your passkey with us for authentication by going to your device's settings and selecting the 'export passkey' option"... > you can always just add a new device via other established factors (email/SMS) That gives the relying party some agency about requiring additional authentication to add devices though, of treating devices added under dubious circumstances as less trusted, or simply of sending a security notification to the customer. Exporting a passkey leaves no relying-party-side traces.
- SheinhardtWigCo 3y ago> "Please share your passkey with us for authentication by going to your device's settings and selecting the 'export passkey' option" This doesn't seem materially different from "please go to your emails and find the six-digit code we just sent you". > Exporting a passkey leaves no relying-party-side traces. Not if it's only useful for getting a device-bound session token. Everything you listed is already commonplace.
- Racing0461 3y ago+1. Lastpass was the love child until they got sold and sold out. I switched over to bitwarden but after being burned, keeping it basic with no lock in for now.
- rstuart4133 3y ago> But essentially it's a certificate... I'll put upfront that I'm no expert in any of this, but ... unlike passwords and certificates, attestation is a thing for passkeys. The thing being attested to is "the private key of this cert is being secured by X". X might be YubiKey in the case of a FIDO2 key, or Google or Apple in the case of passkeys. This aspect of passkeys made me uncomfortable with them. If Google is going to attest they manage your passkey, then it follows the aren't giving a copy to anybody, including you. That means if you lose your Google account you've lost control of your ID. But note: that's control, not the keys themselves. You probably will have a copy of them on a phone, so you can still use them until that phone dies. But when it does you've in a world of pain because you can't backup / transfer / copy them - only Google can do that. In effect you don't own your Google passkey - Google does. I don't know if Bitwarden does attestation now, or if the are planning to implement it in the future. But if either of those things are true they can't give you a copy of the key, ever. This still makes me uncomfortable. But I can see why it is so. You and I may be capable of protecting a private key, but my mother and 99% of the rest of the planet aren't. Your bank or whoever trusting me on my say so isn't going to work, so the end result of us never being able to manage our own keys is inevitable. We have to put them in the hands of a 3rd party the bank or whoever can trust. And it is ameliorated by another aspect of FIDO2 / passkeys: unlike passwords where you can only have one per site, sites are expected to support many FIDO2 keys for the same person. And, you are expected to keep several of them and authenticate each of them at every site you use. So you might have a Google one, and a Bitwarden one, and maybe even a Keypass one. If you did you solve the "Google owns my ID" problem, but it's such a pain in the arse to do I don't see it happening. We've seen several iterations of this concept: FIDO, WebAuthn/FIDO2, and now passkeys. I'd like to see one more: some way of bundling up a whole pile of passkeys from different providers, so when I establish a new account on a web site, I register all of them. That would make maintaining a bunch of PassKeys trackable. Right now, the reality is bugger all people are going to do it. And as a consequence, a good chunk of the planet is going to end up with Apple / Google / whoever owning their identities. And of course some of them are going to lose their relationship they had with there ID manager, and wake up one day to discover themselves wiped from the digital planet.
- wkat4242 3y ago
- wkat4242 3y agoBut. If you run your own vaultwarden there must be a way to export it.
- nsokolsky 3y agoWhat stops anyone from forking their client and adding an "Export" button?
- blibble 3y agoexport doesn't help if it's a TPM wrapped key and websites can check the attestation on the registration to make sure it came from an apple/infineon/titan TPM
- cheriot 3y agoMaybe the authors saw this comment because the page you link to says, "A: Passkeys imports and exports will be included in a future release."
- lxgr 3y ago> But essentially it's a certificate... so I wonder why no private key export? Maybe because current implementation uses some CA that binds you to the issuer? It's a private key, not a certificate (at least not without using attestation). But there is currently no portable specification of WebAuthN credentials; each authenticator is free to implement its own storage backend, and in fact some hardware authenticators deterministically re-derive the private key from an internal secret and the key handle before each signature. Others store a randomly generated key in local storage, indexed by the key handle; yet others encrypt a randomly generated key and make that encrypted key part of the key handle. The point being: Not all implementations can even support key imports, and there's no standardized serialization format for key exports yet.
- halJordan 3y agoIt's just a false issue. You generate more key pairs when you have more devices. You get a new pw manager? Revoke the old ones and generate new ones. You get a new device? Revoke the old ones and generate new ones. Passkeys are a commodity. It was a benefit that keys were device locked until the brain trust told you it was user hostile.