Example: I have many accounts that are tied to my MS account and its credentials. However, I also have many accounts that use the same email as my MS account but are not tied to its credentials. So I can search for person@domain.com, but I still must remember which ones have a generated password and which do not.
I now realize that I could just add new URIs to the accounts that are synced with the MS account, instead of having a separate entry for each site. But that still leaves me in the “which of these are which” boat, since I can’t just look for all the accounts that are currently using the MS password.
I am for this. I’ve found exposed passwords with other services, which bitwarden does not detect in its own vault reporting tools. I think implementing a password search is critical and highly beneficial.
Search by password would definitely provide some additional use cases over exposed password or vault health reports. For example before using a password manager i used a very bad way of creating a password i.e Full-Name + an incremental string of 3-4 digits on each new website.Unfortunately a few days back i got to know that one of my passwords were exposed and that password too had the same type of pattern i used earlier.This certainly increases the risk of my other website logins getting compromised.
So it would be good to have a feature where i could directly search by a string starting with “…” in the password field without needing to manually export an unencrypted copy and searching for the required password.
I just added my vote to this request. It is a good idea, for reasons already stated. The suggested work-around involving a plain-text CSV export introduces security risks, and while I’m happy to see that there is a solution available using the CLI (thanks @dh024!), this method will probably be intimidating for many.
Even if an advanced search query of the form >login.password:MyLeakedPassword were required, this would be a very helpful feature.
I had a need just today to look for an exposed password. I have no idea which account it is from and there is no easy way for me to find it. This is one of the first shortcomings I’ve found with this app.
Thank you and yes I am aware of that report. The password wasn’t exposed on the internet, rather it was physically exposed, but I don’t have a clue for which account so it will be very difficult for me to find the account and change the password.
Yes I did. I was just adding my 2 cent comment that I agree the feature would be useful and easier than the work arounds. I do appreciate your thoroughness
I want to add my voice to a better way to do this. I had Microsoft Defender report a breach to me, but only my email and password, not the associated website. To search by the password I had to export my entire vault and search the csv file.
Yes and this is a big security risk in terms of having a plaintext file with passwords which might accidentally get uploaded to dropbox, backups, or stay in fragments on the harddisk even after deleting.
I think it is a rather unusual case but I also needed this as I realized that one char of my import from my old pwd manager was broken, maybe due to different encoding so I would have needed a function to search an replace a substring in all passwords
Voted for this…just here to say I’m a bit shocked this feature request is over 3 years old and still not implemented. Since your vault is already decrypted when you’re in it, seems like it should be trivial to search the password field in addition to the other fields when searching your vault.
Any enterprising developers want to try their hand at this? I would if I was a capable developer.
I have to say that I can’t believe that this isn’t a feature yet.
The workaround for finding these ‘weak’ passwords or whatever others want to use this feature for is to export your entire vault to a .csv and look at that in Excel which is not really safe or secure.
It must be pretty easy for Bitwarden to implement this feature too, so it is quite surprising that 3 years after the request it hasn’t been actioned yet.