Keep shared passwords organized

I’ve just started evaluating Bitwarden, so it’s possible that I haven’t figured out the correct way to handle some things yet.

I discovered that folders can only be used for the personal vault, while shared items should be stored in Organizations and Collections, which, however, are used to assign permissions, not to create an organized storage structure.

So I’m wondering how I can keep shared passwords organized.

In our current vault, there are nearly 200 shared business passwords, organized with many levels of subfolders. Even with a few collections, users would no longer have a well-organized folder and subfolder structure to retrieve specific data/password; they’d be faced with dozens of passwords, one beneath the other (many of which would be labeled “Admin” or “Administrator” after the initial import).

Even accepting this compromise, the only way I can think of to maintain some logical order is to establish a “taxonomy” to use to construct the name of each password, such as [Area] / [Subject] / [Service] / [Account], but I’m afraid of my colleagues’ reaction! :slight_smile:

I’d love to know how you solved this problem.

I have found taxonomy is less important than I initially imagined due the magic of autofill. Properly configured autofill will only show the one (or few) vault entries that belong to the web page or mobile app you are accessing.

Much more important to me is carefully naming vault entries (“Item name”). For example, I have three vault entries for Google.com. I have named them:

  • me - Google
  • spouse - Google
  • kid - Google

They all have a their url set to “https://accounts.google.com/” with exact match detection. When I am on the google login page, these three entries (and only these three entries) show up in autofill menu. Since the most significant word (to me) is first, it is easy to select the entry I want. And because the list is sorted most-recently-used, often times I am looking for the first entry. The missing bit is windows/mac native apps. “Autotype” (similar to autofill) is reportedly in development.

Nowadays, I only use folders for vault maintenance. For example, one folder for my accounts at my employer, one for the non-profit I donate time to, one for a group of accounts that share a common password, etc.

The primary problem with a name like “[Area] / [Subject] / [Service] / [Account]” is truncation. Much easier is to reverse it and then use “search” when one wants to narrow down the field.

Hi @DenBesten and thanks for your reply.

I have found taxonomy is less important than I initially imagined due the magic of autofill
8<
Much more important to me is carefully naming vault entries (“Item name”)

I agree, but I could list many secrets that aren’t linked/retrieved via URL:

  • human user account on a PC or application account on the server
  • SSH keys and passphrases
  • VPN account
  • Wi-Fi password
  • PIN for SIM/cards/…
  • Network protocol (SMTP, IMAP, SNMP, etc.)
  • Data encryption keys/passphrase (BitLocker, LUKS, …)
  • Product key/license

And in some cases, even if you’ve set up autofill correctly, it’s not enough. The following scenarios come to mind:

  • When the data is present but you’ve forgotten about it (“Which site did we use last year to buy that rare spare part?”)
  • When the site changes its login URL (if I’m not mistaken, this happened several times last year with the ChatGPT authentication URL)

I think a password manager is also a great tool for organizing secrets. Folders are a very effective tool for this purpose (especially since we’re all used to file systems…). For example, even assuming there were no truncation problems, to reconstruct a “sorting logic” that would help you find the SSH password for user USR1 on server SRV1 in hypervisor PVE1 of data center DC1 on hosting HST1 (ok, maybe I’m exaggerating :slight_smile: but the purpose is just to make the point …), I would use a name like “HST1 > DC1 > HYP1 > SRV1 - USR1”… This might allow you to alphabetically group secrets related to the same context, but I think it would quickly become unmanageable.

Hi @DenBesten! I was hoping to get your feedback on my answer :slight_smile: In particular, I’d like to understand how you handle keys that aren’t associated with a URL.

For non-URL secrets, I try to find a corresponding vault entry and add it to the “Notes” field. . For example, a SIM PIN goes in the vault entry for their billing portal, the hospital’s WiFi creds are on my vault entry for their customer portal (and saved in my device’s network config), and if the IMAP password differs, it is in the vault entry for their webmail.

I do use secure notes for things completely divorced from a vault entry like product keys, drivers license numbers, national identifiers, etc. And then, I focus on making the name include words I am likely to eventually use in a search.

I have found that tight match rules do cause a certain amount of maintenance. Generally speaking, it is a pretty easy fix and a good opportunity to ensure that the change is intentional (e.g. by double-checking that the old URL is gone). And, when this happens, it is pretty easy to search for the intended entry and manually force an autofill, which will then pop up something like this:

That said, I suspect your response will be “but how do I get in front of my users and do this for them”, to which my only response is that users do need to understand a bit about vault maintenance because we allow them to visit websites that we don’t necessarily use regularly.

Not sure if my suggestion will be helpful to OP in any way, but when the item name does not include terms that I would be likely to use in a future search, I create a custom text field labeled Keywords, and then enter a list of potential search terms (separated by space characters); and because searching in custom fields does not automatically insert wildcards, my list may include a sequence like se sec secr secre secret (if I believe that I am likely to use the term “secret” when searching for that vault item in the future).

Thanks @DenBesten @grb for your replies.

The problem isn’t personal secrets, for which folders can be used, but shared ones: imagining a group of people able to define and share general rules for managing the creation and retrieval of shared secrets without using a folder-subfolder structure is still very difficult for me at the moment.

Let me give you the example of the company I’m working for: they use KeePassXC (not very suitable for multiple users) and their password archive is organized as shown in this image.

It’s easy to see that with an archive organized this way (in addition to the search function, which obviously remains available), it’s very easy for anyone to retrieve an existing secret or enter a new one, even without having shared any rules with the rest of the group (even newcomers usually just have to look at how the keys are entered to figure out how to create a new one)…

I’ll think about it some more, and thank you very much for your insights!