> 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?
I back up at the Vaultwarden backend store level anyhow. Probably shouldn't give me that sort of advantage over the commercial option.
Clearly a TOTP token is not a thing you are.
Less clearly, it is not a thing you have. Passkeys and TOTP tokens "want" to be a thing you have, but in the end they aren't. My little proof in my parent post may be small, but I'm quite serious... if you can store it in a password manager, that is proof that it is a thing you know, not a thing you have.
It turns out making a "thing you have" be a true thing you have is very difficult. It may even be impossible, in some sense. Everything that is a "thing you have" seems to be a thing you know masquerading as a thing you have through some security-through-obscurity.
Between that and the fact that "thing you are" has incredibly poor, if not outright dangerous characteristics if you try to scale it up, I'm actually not on board with the "passwords suck because things-you-know suck and we must replace them immediately!" I think they whole argument stinks of a classic engineering mistake of considering only the pros of one option and only the cons of another. I think when you take a holistic view, "thing you know" is the only practical, scalable option of the three basic options. If passkeys make it easier, fine, I'm up for some improvement, but I'm not on board the "passkeys must be a thing you have" and I fully intend to use them as things I know as much as I can and have no intention of letting anyone make my passkeys into objects.
Nearly everyone is storing it in password managers.
So has that changed passwords into not being “thing you know”?
> 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?
> Saving and using passkeys are a feature of the Bitwarden browser extension. Other Bitwarden clients can be used to view the saved passkey.
So sadly, like TOTP I can't trust bitwarden to only keep my keys in an HSM on the server.
I really wish exporting would be impossible. Today, I need to add my primary and backup passkey devices whenever I signup for a service.
If keys were only stored on the server, then I could use it as a level of indirection.
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.
> It is also, as currently implemented, one of the most effective platform lock-ins I've ever seen.
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.
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.
EDIT: According to the pr[1] it does support import/export
---
0: https://github.com/keepassxreboot/keepassxc/issues/1870#issu...
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.
This move by Bitwarden clearly shows that they believe products that allow you to export/backup your keys will be blackballed, so they played it safe and blocked that.
It used to not even accept Yubikeys, only a fairly unknown other brand; now they finally do support Yubikeys, but only the "FIDO L2" certified kind, i.e. the FIDO and "security key" models, but not the most common plain Yubikey ones...
It also says: "It is not intended to be used for any other purpose and could go away at any time."
Finally it looks like anyone can contribute attached to an implementation according to the Readme
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.
It was a benefit that keys were device locked until the brain trust told you it was user hostile.
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.
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).
Another silly one is adding custom fields, you can’t change the type between visible/hidden once it’s created, so if you mess up, you have to delete the custom field and add it with the desired visibility. Ughhh
This is configurable - not sure what the default is but every time does sound annoying.
1Password feels cleaner, more integrated & polished but in practice the UX is inferior to BW - most regular actions take more clicks & discoverability is lower. And the password generator is even worse than LP's.
Lastpass UI is well known to be poor - Bitwarden's is far less worse by every metric.
Bitwarden's not perfect but what's significantly better UI-wise?
/ Paying Bitwarden user
So, how would you access that cloud account in the first place? Unless you remember the password and disable 2FA for that cloud account, unless of course you add another 2FA manager which is just an extra non-needed complexity.
I introduced it at work to manage all our company credentials, and loved the fact that all users also get free premium for their personal account.
1password seems to have the best UX in the field. But you always have to trust some company with the keys to your digital life.
Self hosting password managers is not as big of a deal as it should be.
The vault is encrypted with a password that never gets transmitted, and even if your password and vault gets stolen, without the additional “secret key” that also never leaves your device (and you should probably print and store somewhere safe), an attacker won’t be able to do much with it.
The inclusion of an additional secret key makes a huge difference in this setup. but yes, it would be much nicer if I could use my own sync store like in the past… (looking at EnPass currently which also has a secret key setup and own sync store)
[1] https://1password.community/discussion/120403/delete-family-...
So it's pretty annoying to see in the docs for this passkey feature that they just expect you to make a duplicate bitwarden entry for every additional passkey you need to add to an account. Especially when it's standard to register a backup key for any service that uses passkeys.
If a service provides the option for more than one passkey, I always configure several.
But when would anyone need multiple passkeys for the same site account in the same Bitwarden vault?
I’ve never heard of this for Passkeys, only for hardware keys.
Passkeys are meant to be something “that you have”, similar to one hardware key, why would you want to store 2 within the same password manager? What would that give you?
> Passkeys support for mobile applications is planned for a future release.
Q: Are stored passkeys included in Bitwarden imports and exports?
A: Passkeys imports and exports will be included in a future release.
Not sure if passkeys are supported on iOS or Android (only the browser extension is explicitly mentioned) and also they cannot be imported or exported according to the page.
Webauthn puts a private key into a firewalled section of hardware onto your device - which is extremely prickly to work with in my experience - for your security.
For passkeys to be transferable the private key cannot be locked to your device.
Is bitwarden somehow able to "spoof" this hardware and have your browser generate private keys in it instead?
This is not true. In general, Webauthn doesn’t care where and how the keys are stored. There is attestation feature, but AFAIK e.g. Apple intentionally doesn’t implement it for unmanaged devices.
Im assuming this is because apple uses a software based TPM that isn't tied to the device. This lets those private keys sync between devices.
Is the future state for bitwarden to be able to perform the same trick somehow? Have you create keys in it and not your devices tpm?
Apple has only recently introduced the necessary APIs to allow for third-party passkey providers (i.e. other apps acting as a passkey storage) and users (i.e. other apps using passkeys stored in iCloud and in other third-party provider apps).
But it's not easy as passkeys being supported on the latest versions; at least Google used to support a non-synchronizing platform authenticator implementation of WebAuthN using the system keychain and Touch ID (or the login password as a fallback) as well. So there is also a chance you were using that, at least on macOS.
> Is the future state for bitwarden to be able to perform the same trick somehow?
For web browsers, I believe the current approach of 1Password and presumably also Bitwarden is to inject a custom implementation of WebAuthN into every page's context. This doesn't require any WebAuthN/passkey support on the browser's side.
On macOS, they could also act as a system-level passkey provider though; this should then allow all passkey consumers (such as Safari and other browsers) to use these passkeys natively, i.e. without a JavaScript shim. And on iOS, given how web extensions are notoriously tricky there and all browsers are kind of Safari under the hood anyway, that might even be the only option.
Or a code audit in Bitwarden has no bearing on vaultwarden?
My Vaultwarden instance is "hidden" on a subdomain that probably nobody would ever guess (or scan for), so at least there is some added security by obscurity. If someone would know my credentials and master password, they probably won't find where to use them. In this case the reverse proxy in front of it also serves other content, just be hitting the IP nobody would ever know there is a Vaultwarden running on this server.
Edit: the subdomain is behind a wildcard DNS, so it's also not listed in the zone file. Although it will show in DNS logs of the ISP when I'm using it.
2. If they can figure out your domain name, they can check crt.sh for "mysecrectvaultwarden.domain.tld". If that only reveals wildcard certs and they're really interested in you or your company, they could try bruteforcing the DNS name.
3. If they breach the vaultwarden server and in case you're using the web UI, they can try to inject some JS to steal the credentials.
What I do to mitigate this: 1. Vaultwarden only reachable via VPN (e.g. wireguard on OpnSense) 2. Custom CA on all devices (e.g. step-ca with name constraints and local ACME [careful to put DHCP clients on a subdomain!]) 3. DNS for my LAN+VPN is not public. This massively reduces the external attack surface, compared to having a bunch of services available behind traefik.
A VPN would provide better security for sure. But also make it harder to use (VPN needed on all devices).
As for CT logs, this leak is avoided by using a wildcard certificate, which Let’s Encrypt supports.
The bitwarden windows app and the browser extension are more or less just the web app inside a webview.
I'm a bit out of touch here, and I assume adding support to password managers like bitwardon mitigates this risk similar to using them to store MFA seeds, or apps like authy over Google authenticator
This ability to self host in itself is worth so much.
Don't get FOMO; both seem to support export and import, and they seem to be compatible formats, but you may need to lightly modify the CSV from Bitwarden.
https://f-droid.org/en/packages/com.kunzisoft.keepass.libre/
We thought a Slack community was a more authentic way for users to contact / chat to those actually building the product, but please reach out to gregor@mailpass.io if you need support or just would like to ask some questions.
I get to use iOS built-in password manager, sync only on Apple devices and then no where else; or I get to use Bitwarden everywhere but on iOS no browser integration, I have to copy and paste (separately) user and password. Or even more lovely, maintain separate managers.
I don’t think apps can turn on autofill automatically, you might have to manually turn it on in Settings->Passwords->Password Options
