Bitwarden adds support for passkeys
bitwarden.comFrom 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?
I 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.
I see this common refrain from people. How is writing something down so that you don't have to remember it a "thing you know"? You literally don't know it. A "thing you know" never leaves your brain, otherwise it becomes a "thing you have".
It comes from the fact there are three fundamental ways to authenticate: a thing you know, a thing you have, a thing you are. You may not "know" a passkey or a TOTP token, but you are using computers in their most fundamental role as bicycles for the mind to "know" them for you. This means they still fit into "thing you know".
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.
Yep. Thing you have is a passkey that can't be copied at all, like a yuibikey, some physical manifestation that can't be easily cloned. Arguably TOTP is "have" due to being linked to a phone when doing push to a single device.
Nit: TOTP doesn't include push methods of 2FA, it specifically refers to the algorithm for producing one-time passcodes from the current time and a secret key.
TOTP is just PAKE with a funny way of writing the password.
We tricked people into using actually secure passwords and password managers by calling it 2FA and devising a scheme where the human does the challenge and the server necessarily must keep that part of the password in plaintext, but in exchange the user doesn't have to type out the long part of the password every time.
No, TOTP is a weaker version challenge-response authentication (with the challenge being time-based and not provided by the verifying/challenging party).
PAKEs do significantly more; in particular, they are MITM resistant (unlike TOTPs) and provide mutual authentication.
"like a yuibikey, some physical manifestation that can't be easily cloned"
And this is what I referred to by the "things you have" being just "things you know" wrapped in obscurity in practice. If you know the contents of a yubikey, you could store those in your password manager and use the password manager to emulate it.
Mind you, it can be good, solid obscurity. It's fun and educational to read about all the security in your yubikey, and certainly to me in practice it is a "thing I have" because I'm thousands of dollar's worth of hardware and weeks/months/years short of the requisite skills to penetrate one.
But there is still a sense in which it fails to be the platonic manifestation of a true "thing you have" because underneath the hood it's still a thing you know. At scale this matters.
At scale, biometrics also has the problem of becoming a thing you know. Again, in the platonically perfect world where, I dunno, authentication mechanisms have access to Star Trek transporters and can analyze you down to the atomic level to be sure you are you (though even Star Trek had trouble with the shapeshifters in Deep Space 9!), then, yes, it would be truly a "thing you are". But in the real world, where a biometric auth still involves presenting a sensor with some sort of input that it will agree is you, it still degenerates into a "thing you know" as you try to scale the system up. You can make it more and more difficult to fool the sensor, but then, that raises the price of the sensor and the risk of false negatives, both of which make it hard as you scale up. Which is why I think biometrics authentication is very powerful, but generally should be reserved for very important things and used as a mix of other methods, or, alternatively, used for things that hardly matter at all, but I think it's quite dangerous in the vast middle. I would be very concerned if my bank account could have arbitrary operations done on it just by presenting my fingerprint.
I don't actually mean this as "criticism" of things you know and things you are, because, like I've said in both cases, they do have their uses in the real world. I just think if you want to deeply understand the question of authentication, as they scale up, they all turn into a "thing you know" for a sufficiently motivated attacker, and in the discussions we have on HN we are generally talking about the largest possible scales, so this matters. I think that's an important aspect of understanding these systems, using them for security, understanding the attack surfaces and likelihoods, and properly modeling them. I see a lot of people making bad cost/benefit analyses because, for instance, they don't realize that biometrics are in the end a "thing you know" and that fingerprints can be faked, faces can be faked, etc., and that you can't model them as what you'd really like a platonic "thing you are" to be. They degenerate into "thing you know" at quite practical scales, depending on what goodies you are keeping behind those authentication barriers.
> there are three fundamental ways to authenticate: a thing you know, a thing you have, a thing you are.
Rather observations of each of those things. A "thing you are" is in practice just a "thing you have". You have a finger, with a fingerprint on it. That gets measured, and that measurement can be faked or your finger can be taken from you.
And of course "things you have" can usually be duplicated with sufficient effort. Even "physically unclonable functions" just rely on process variation in semiconductor manufacturing, with sufficient effort (FIB workstation for manual trimming) it's likely possible to clone even those.
Any half decent sophisticated user on the internet has not remembered passwords for half a decade at least.
Nearly everyone is storing it in password managers.
So has that changed passwords into not being “thing you know”?
Yes? If you write your password down on a piece of paper it becomes something you have, no?So has that changed passwords into not being “thing you know”?Protocol-wise the difference is that a TYH* requires an interaction by the user.
An app generating OTP codes is a TYH while the secret used to generate the token is a TYK.
A password manager is a TYH while the passwords inside are TYK
In general every (non-quantum) TYH possess some kind of TYK that can be used to duplicate the TYH.
In the name of security sometimes there are locks around the TYK, sometimes physical other times software.
In the case of passkeys the inability to export them makes them TYH.
* "Thing you have" is too long
The server is not checking if you have a piece of paper. It is checking if you can produce a piece of information.
If someone steals your paper, copies the password to their phone, and then returns your paper, then the attacker can log in without that piece of paper. In a true "something you have" if you have that something then it is impossible for someone to login to your account.
I agree with the general sentiment but every non-quantum "thing you have" can be duplicated.
PS: I suspect that you could make a 2FA protocol capable of detecting duplication of the thing you have by having the app generate signed codes like "this is the n-th code I have generated" and have the server remember the n as a logical clock to detect duplicates and "time travel".
AFAIK only bank-type apps would use something this sophisticated
>but every non-quantum "thing you have" can be duplicated.
Not easily. Extracting keys from hardware keys is very hard to do.
I agree, what I was trying to say is that not offering a key export is an attempt to gain some of the type of security provided by hardware keys: Difficulty to access the secret
Password database is often protected with a master password, so accessing it requires a thing you know.
Agreed. unless its stored in a tpm module or on an actual piece of hardware like a yubikey, no amount of software (especially a browser plugin written in javascript let alone low level drivers for an OS) can turn a "thing i know" into a "thing i have".
It 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.
Some 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?
> What happens if I have 500 passkeys backed by keys in a TPM and I get a new computer?
In theory the same thing that happens today with a yubikey - you have multiple devices with valid keys.
A big part of passkeys is that they are (often) not in hardware, so they can be synced.
If it is just a pointer a hardware, even more reason to let you export it.
The 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.
From: https://bitwarden.com/help/storing-passkeys/
> 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.
You'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.
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.
> 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.
> "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.
>This doesn't seem materially different from "please go to your emails and find the six-digit code we just sent you".
Exactly, that's the problem lxgr is pointing out. Those six-digit codes can (and often are) phished by e.g. tech support scam attackers. lxgr is pointing out the same exact attack could be done against an exported passkey.
So you’re saying this phishing attack:
We have to rename and re-enroll your device token so your laptop can still log in.
Click “I registered this credential” when you get the alert about it so your old credential that you added before will still work.
Is harder to pull off than:
Go to your password manager and export the entire database locally stored passwords. Now, print it out and read this 200 character string to me over the phone, or just email the file to me.
Can't we just put a 100px blinking red text that says "Do not share this with anyone or it's your own fault" and be done with it?
It would be great if that were actually 100% effective, but unfortunately phishing still happens despite such warnings.
In a situation where a message on a screen tells a person to do x, and a person on the phone tells them to disregard it because it’s a computer error or whatever and do y, some percentage of people will do y.
The only way to prevent that is for there to be only one option – the safe one. Sometimes that has unacceptable other implications of course; this might well be such a case.
> In a situation where a message on a screen tells a person to do x, and a person on the phone tells them to disregard it because it’s a computer error or whatever and do y, some percentage of people will do y.
It's the human version of prompt injection attack.
Rename "export passkey" to "backup passkey". Or backup whole database.
Maybe the authors saw this comment because the page you link to says, "A: Passkeys imports and exports will be included in a future release."
That'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#issu...
> 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.
I hate attestation with a passion. But luckily Apple has not implemented it and nobody wants to lock all Apple users out. So at least right now it's not a thing in practice.
Apple used to support it for their non-synced platform credentials. They fortunately got rid of it for synchronized passkeys.
Yep. The end game of this is that web applications will, either through laziness or a sense of 'better security', only accept passkeys attested by Google/Apple/MS and/or those backed by TPM with non-exportable keys. You have to register with the FIDO Alliance to obtain an attestation GUID, and unsurprisingly, only the big guys are on the list: https://github.com/passkeydeveloper/passkey-authenticator-aa...
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.
My government's e-signing web application (which stores private keys on the vendor's servers for all citizens, but that's another story) already does 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...
The repo README for the link you provided says "This is a community-driven list of known passkey provider AAGUIDs to assist with naming passkeys in end user passkey management interfaces (e.g. account settings)."
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 does say it will come in a future version now. The FAQ has been edited since the comment with the original quote.
> 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.
It does seem like a real "lock-in" move.
But. If you run your own vaultwarden there must be a way to export it.
Vaultwarden never sees the unencrypted vault contents though, does it? The way to export would be in the client applications, not the storage implementation.
Oh good point yes.
At least the clients are open source so it should be possible to write an exporter.
It'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.
+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.
In which way did you get burned while using Bitwarden?
I think they meant they were burned by Lastpass and are now less trustful of password manager services.
Is this true for all of the incumbent password managers? If so, it seems like the worst of software lock-in.
what's the phishing risk if bitwarden autofills only on the correct domains stored in the vault?
Mobile apps, slightly tweaky domain names (which happens normally), much less fancy xss type attacks, plus general data exfil.
Mobile BW app also wouldn't fill a password for a different domain
Can 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.
There not even being an extra step is still much safer, no?
If 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?"
Or you can add another domain, saving users from easy buttons "yes, phish me anyway" is also useful
> 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.
Silly 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?
If 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.
You 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.
It 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).
The question was about the password alternative the op was describing
What stops anyone from forking their client and adding an "Export" button?
export 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
Bitwarden is underrated. Passwords run everything in our digital life. I will gladly take a UI compromise here and there for more trustworthiness.
I don’t even mind the UI honestly. It works. Some annoying UX here and there, but I can live with that. I happily pay for a subscription to support them.
My biggest peeve is that if you search for a password and you happen to be in the "Card" category for example, it will return 0 results. A good alternative would be to show No Results for the category you are in, but then provide results for other categories below.
My biggest issue is when having to copy multiple fields from an entry into the webpage and having to use the search (because the entry is for a different domain or just a note or a card) you have to search for the entry again and again because the search key doesn't persist
Yeah that gets me somewhat frequently too, and second the request you have.
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
another is that if you do a search then click on an entry and do another search, the entry details displayed and what's in the search box don't match and it's not clear unless you're paying attention.
I moved over from Lastpass, I find the experience of filling in a password in Bitwarden more jarring/slow than in Lastpass. I'm not sure what it is, maybe Lastpass had longer timeouts to require FaceID when filling a password? Bitwarden requires it every time.
This is configurable in the settings. The default timeout is indeed too low and very annoying, but you can set it up to 4h I believe.
> Bitwarden requires it every time.
This is configurable - not sure what the default is but every time does sound annoying.
Can you compare to 1Password?
1Password is very trustworthy too. They get audited frequently, and their db file format is open source (meaning you can write a 3rd party tool to decrypt them).
With UI/UX they are lightyears ahead of Bitwarden. I want to like Bitwarden, but when your application doesn’t even support extremely basic stuff like drag ‘n drop, I’m gone.
In general they also support newer tech much faster. And their secret key system is more secure than Bitwarden’s password-only method.
> With UI/UX they are lightyears ahead of Bitwarden.
1Password is arguably moving backwards these days, UI-wise.
I don't know if it's caused by the Electron update or just coincided with it, but I've been finding the keyboard autofill shortcut as well as keyboard navigation for selecting a given login on a page very unreliable lately.
That said, 1Password's "auto-rotate password" feature is still ahead of the competition, though. Bitwarden doesn't even seem to try, but that's still better than LastPass, which reliably used to lock me out by irrevocably overwriting the old stored password before the website confirms the new one as having been accepted.
> their secret key system is more secure than Bitwarden’s password-only method.
I don't know, their security key mechanism seems to be getting weakened in the interest of convenience as well. I was recently very surprised to notice that the iOS client apparently synchronizes the security key for any logged-in vault to iCloud Keychain, with no way to opt out – even for enterprise vaults!
Bitwarden will also soon support the WebAuthN/CTAP2 "PRF" extension, which is even better than a static security key since it rotates with every vault unlock.
> > their secret key system is more secure than Bitwarden’s password-only method.
> I don't know, their security key mechanism seems to be getting weakened in the interest of convenience as well. I was recently very surprised to notice that the iOS client apparently synchronizes the security key for any logged-in vault to iCloud Keychain, with no way to opt out – even for enterprise vaults!
In their defense, they document that the point of the Secret Key is that it remains secret from them/AgileBits/1Password, and that it is expected to be present on-device. It used to be called the Account Key, but the reason the name was changed was because far too many people were referencing it in emails to support, which undermined the design.
In your defense, while they started syncing the Secret Key in iCloud Keychain all the way back at v7.0, they had then and have had sense gotten plenty of feedback saying this should be optional. They have just refused to make it optional.
sorry, no experience with 1password
Same here. We use 1Password at work and the braindead UI choices continuously surprise me compared to Bitwarden's simplicity.
Bitwarden's UI is far from perfect but I find it better than any competitors I've tried (LP & 1Pass).
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?
I can't speak for the other password managers, but I find Bitwarden's organization management to be pretty terrible. As a personal password manager it's pretty good, but as an organization password manager, not so much.
Having to manually type a folder path to create nested folders is horribly archaic.
/ Paying Bitwarden user
I think they fixed that. Can't verify at the moment.
Apparently there is two different things, Collections and Folders. Folders exist for personal vaults and collections for organizations. No idea why you can't use folders in organizations.
Yeah you're right. I think folders are more like a "tag" in that it's not actually a container (I think you can even put stuff from an Organization's collections in your personal folders).
Anyway, with Collections, you used to have to create a collection and enter the name as Some/Thing, to get a hierarchy going. But I think they improved that so that you can just create that hierarchy of collections int he web gui as if they were folders in folders.
Nothing beats www.enpass.io but they charge now. I still ran the free version (free version not available for download anymore).
> store and sync passwords wherever is best for you
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 find Enpass to be great for personal use at least. I've never tried it for business use. Luckily I paid for it when the Android app was $6.95 and got you lifetime usage on all platforms. They recently added passkey support.
I never installed it on Android. I use it only on my computer. But I use it also a lot as an organizer since it is so flexible. Has also my ID scans, Degree scans etc.
I have to use bitwarden at my company laptop and don't enjoy it at all. Weird UX with unlocking the vault via touch id on a Mac (this is literally the most common UI interaction, please make it nice). On top of that, weird rare syncs/bugs, but this could also be coming from my employer.
And with the Premium upgrade at only $10 a year, it's outstanding. I wouldn't mind paying 10x that.
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.
Why is it underrated? In my personal bubble everyone is using it. Most of them self-hosted. My hole family and some friends use my instance. Besides pass (low non tech approval factor) there is nothing that comes close.
Tends to be used by a tech audience, it's nowhere near as widely adopted as e.g. last pass for normal consumers.
For hackers there is a CLI and with that also JS libs etc. to get it into anything you might want. For anyone else the UI is already miles ahead of Lastpass so there is no big compromise.
I pay for family, and I like it. The only thing I don't like is that 50% of the time it would not recognize that I created a new user/pass combination.
I am very happy to pay for a family plan. The price of one coffee per month. Thank you Bitwarden.
The coffee is really expensive where you live lol. Here is around €1. But it's a decent price for a password manager yes. And the personal one is even better.
One of the nicest thing about bitwarden is the ability to selfhost it. I don't think there is anything like it.
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.
I've been incredibly happy with https://www.passwordstore.org/ for years. The data store is a file hierarchy, with the files themselves encrypted with GPG. Sync is via git. TOTP support with a plugin.
The one major feature `pass` lacks is sharing. I used it for years, but moving to (self-hosted) bitwarden has made life a lot easier in that respect.
I share my vault with my partner. You can specify multiple gpg IDs in the `.gpg-id` file at the root of the store and passwords will be encrypted for both. You can do this on a per-directory basis too.
I'd use pass if there was an easy way to use it on mobile.
Do you get the same features self-hosting as you do paying for their cloud offering?
Some features require paying. For example: TOTP. But if you want just for passwords it is free.
You can use vaultwarden and get everything for free
Yes.
You’re not really “trusting a company with the keys to your digital life”.
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)
You realize that trust is not just about privacy the day your vault disappears from all your devices with no option whatsoever for recovery[1].
[1] https://1password.community/discussion/120403/delete-family-...
But you have to trust them that the secret key never gets transmitted, unless you compiled it yourself.
Also, malicious code can be pushed to the website if you are logging in through that. You have to trust that their infrastructure is safe.
One of the benefits we saw moving from lastpass to bitwarden is it allow us to much more easily reduce duplicate entries for the same site/account.
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.
What would be the purpose of having multiple passkeys for the same account stored in the same BitWarden vault? You're going to have a backup key and store it in the exact same place as the primary key?
The idea of passkeys is that they can be synced so you don't lose them when you lose a device. So there's a lot less need to have two
Multiple passkeys backed by different sources (password manager, iCloud, Yubikey, etc.) can serve as a backup in the case you lost access to your password manager, for example.
If a service provides the option for more than one passkey, I always configure several.
But that doesn't explain why you'd want multiple keys all in the same password manager. That seems to miss the point of the redundancy, like keeping an "offsite" backup onsite.
I can see the point of having multiple passkeys (e.g. backed by different passkey managers, like 1Password in addition to Bitwarden, or a combination of physical security keys and passkeys), as well as the point of being able to store multiple passkeys for different accounts in a single Bitwarden profile (e.g. for work and personal Google accounts).
But when would anyone need multiple passkeys for the same site account in the same Bitwarden vault?
> Especially when it's standard to register a backup key for any service that uses passkeys.
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?
Looks like the new version isn't approved for the firefox addons repository just yet... So haven't been able to try it out, but very happy with bitwarden (self-hosting a server using vaultwarden)
Doesn't appear to be available yet for Chrome in the Chrome Web Store or for Android in the Google Play Store, either. :(
Looks like it not really released yet. I still have 2023.9.x everywhere, and 2023.10 is the version with passkey support.
It's definitely out (https://github.com/bitwarden/clients/releases/tag/browser-v2... just looks like browsers haven't approved it yet.
I don't want to start a philosphical discussion. But I still can't install the browser extension to use it, so I wouldn't consider it being "out".
So it's browser extension only? I can't use the android app to login with a passkey I stored from my desktop browser? Hopefully they'll add that support soon enough, because password access on my mobile is a big pain point.
From the website:
> Passkeys support for mobile applications is planned for a future release.
Looks like they're planning for export of passkeys.
Q: Are stored passkeys included in Bitwarden imports and exports?
A: Passkeys imports and exports will be included in a future release.
perhaps a better link? https://bitwarden.com/help/storing-passkeys/
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.
Given the title of this post being about Bitwarden adding passkeys; I would think linking directly to the specific release note would be the best link.
I may be stupid, but I just cant get this to work. Ive tried in both Safari and Chrome.
Anyone have any luck so far?
No, I didn't get the update yet (Firefox, Chrome, iOS). Everything is still at 2023.9 and 2023.10 is the version with passkey support.
I'm missing something.
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?
> Webauthn puts a private key into a firewalled section of hardware
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.
I've experienced this on my phone IIRC...if I register a webauthn key on chrome on iphone, it shows up on safari; but the reverse is not true.
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?
The situation with Chrome and Apple devices is currently quite confusing.
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.
> The situation with Chrome and Apple devices is currently quite confusing.
As someone who's used 1Password, Apple's password/passkey manager, and Chrome's password/passkey manager while checking out the passkey user experience of these respective solutions, I didn't find it more confusing than the ability to choose your preferred password manager. That is, I didn't find it confusing.
Is that on iOS or macOS?
Maybe the onboarding experience is better now, but when I last looked into this, 1Password and Chrome were fighting over who gets to store newly generated passkeys in my browser. At the same time, Chrome's ability to use Apple/iCloud passkeys is brand new; before macOS Sonoma, this wasn't possible at all.
Not sure about managed vs. unmanaged devices, but Apple used to support attestation before they started synchronizing passkeys via iCloud.
Does the code in Vaultwarden mimic the code in the self hosted version of Bitwarden?
Or a code audit in Bitwarden has no bearing on vaultwarden?
In theory the Bitwarden server (and Vaultwarden) shouldn't have any access to the passwords, so a data breach of the server should never disclose any contents of the vault. Vaultwarden "feels" safe to me, but I would also be interested if there is some possibility it could introduce some degraded security compared to the official Bitwarden server.
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.
1. If an attacker got your credentials, they'll probably also have the server URL. Reasoning: They probably infected your machine with infostealer malware and keylogged the password. Or are you using the exact same credentials someplace else?
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.
I know it's not really secure, it's just hidden to some extent. In a way that an average attacker probably wouldn't find it right away. If someone is really looking for it, it can be found.
A VPN would provide better security for sure. But also make it harder to use (VPN needed on all devices).
AFAIK if you type something in the browser's omnibar, the search provider such as google will receive the autocomplete query, so google will at least know your secret domain. If you're using letsencrypt, your subdomain will show up in the public CT log, which is probably being mined by some data or security companies. Your dns providers will also know this secret subdomain as well and and some data companies might be able to obtain them.
Firefox seems to be moderately conservative about what it does search autocompletion on. Type in the full URL, protocol and all, and it doesn’t look like it leaks anything after the colon.
As for CT logs, this leak is avoided by using a wildcard certificate, which Let’s Encrypt supports.
Good point actually, the passwords are encrypted with official Bitwarden client apps (unless using web app).
I think even the web app does the encryption in the browser.
The bitwarden windows app and the browser extension are more or less just the web app inside a webview.
How do you hide subdomain ?
You don’t, and they’re not really hiding anything from anybody who has any knowledge in the security space.
Vaultwarden is unaffiliated with Bitwarden. Vaultwarden is a hobbyist re-implementation of the Bitwarden server API. Anything the frontends (extensions, web ui, apps, etc) need to function properly, must would need to be re-implemented in Vaultwarden.
What's the story with passkeys and broken/lost devices?
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
You can still have a password, but think of it as a backup. Or you rely solely on the lost password process to reaccess your account.
I have been self hosting bitwarden/vaultwarden for 4 years now and my setup is hosted behind two self hosted vpns(openvpn and wireguard where one acts as backup vpn).
This ability to self host in itself is worth so much.
I feel I may have made a mistake going all in on keepasscx. Been looking for something without a subscription and ideally open source. Keepassxc looks like it has a much nicer UI.
KeepassXC will have passkey support soon: https://github.com/keepassxreboot/keepassxc/issues/1870
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.
Very cool, thanks for the tip. I use KeePassXC together with Syncthing, so now I just need a compatible android client.
I recommend KeepassDX.
https://f-droid.org/en/packages/com.kunzisoft.keepass.libre/
Pair it with mailpass.io and you have PassKeys all round, and real phishing protection than using gmail/ms/icloud emails as the communication method. Using a pw manager works well with it since the manager quickly stores the unique alias assigned to the service (ie instead of the same persistent email each time)
There's no pricing information for mailpass.io. There isn't even a contact email address or form. I'm hesitant to trust services that do not list the pricing (or future plans for pricing) transparently. Same for not having a support contact either. The help page here shows Slack as the only way to connect, but that's not convenient for people who don't use it or don't want to use it.
Thanks for your points - the product is in early beta and it is fully appreciated we are asking to be trusted with inbound messages which is a higher bar than a lot of products. Pricing will be transparent and detailed soon - however the service is currently free for up to 10 services/aliases (noted on the landing page) as we determine the user cohort that gets the most value from the product in general.
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.
iOS inhibits solving the cross platform problem, due to lack of browser extensions for all browsers.
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.
Third party apps can integrate with iOS’s native password autofill, just like how keychain works. Bitwarden supports this as well. I’ve been using Bitwarden seamlessly on all my devices, iOS included, for a while now. It works in apps other than safari too. Anywhere where the native iOS password manager would appear, my Bitwarden passwords appear as well.
I don’t think apps can turn on autofill automatically, you might have to manually turn it on in Settings->Passwords->Password Options
Great news. This is my favourite (and now only) password manager.
I've been waiting for this ever since Apple locked passkey support behind their existing (and infuriating) password autofill implementation. It irritates me so much that I refuse to use passkeys on iClould anymore, which is a shame becuase I really enjoyed the UI (for passkeys) and biometric auth built in to their products.