Add unshare option

You say it as if unsharing by moving an item from an organization back to an Admin or Owner is equivalently or less privileged than deleting an item. Whilst this is true on a technical level, it’s not on a social level (and password management is as much about the social as the technical).

If this functionality was implemented, then Admins/Owners would unshare items and then carry on using them as personal credentials. But of course, once credentials have been shared to an organization, you have to assume that anybody in the organization could have access to them. This is dangerous. Whereas deleting an item has a completely different use case - it’s for when an item is null, void, no longer needed. If the account for the deleted item remains, then it is self-evident that the credentials must be changed before the item is deleted. But for unsharing, this is not the case and would cause issues.

For some people and organizations, the way that Bitwarden handles this is preferable. For others, it is not. The only way that Bitwarden will accommodate both viewpoints is with a deeper toolset of enforcement policies and access controls that enables both workflows to be achieved.

But guess what, at this point it becomes another CyberArk or Password Manager Pro. Is this what Bitwarden is supposed to be? Enterprise bloatware with a gazillion options to configure before you can even get started? I don’t think so.

3 Likes

@d.b Geat reply! Thank you for taking the time lay it out for me in this depth. I was totally only thinking about the technical implications. But you are absolutely right about the social context. You changed my mind.

@tgreer I was exactly thinking of a shortcut for the clone & delete routine. But @d.b has definitely changed my mind on unsharing in general. Just does not make sense in a password manager.

1 Like

I disagree on the above. I don’t see any difference from social context.

In both cases, it is self-evident that collection credentials are “public/shared” and if you want to move it back to your own “private” vault or to delete simply it from the “public/shared” collection, then you should change the already “public/shared” password. In fact, if you allow items to be copied/duplicated from collections to private vault, it’s even clearer to the end user that anyone can do this.

I’m not clear how, by forcing users to manually copy the credentials then deleting them from the collection, will help with social level usage of the application. I personally think that a popup/warning when migrating or deleting items from public collection to private vault would make it even more evident to the end user.

At a more fundamental level, I disagree with the intentional crippling of the export/copy of the collection. This gives a false sense of security and does nothing to improve security and results in unnecessary hindrance to the end user experience all in the name of security. Once transferred to the collection, the information should be treated as public information, to the extent of the users of the collection, and hence users should just treat the information as such accordingly. i.e. when you transfer a password from collection to private, its just like getting a preassigned pin from your bank, you change it the first opportunity you get.

You must have a lot more trust in your users than I do, because I tend to work under the assumption that users are quite unintelligent, and this certainly would not be self-evident to such a user.

But in fairness, this is something that is also dependent on environment - different organisations will have different types of employees, and some will be more versed in security best practices than others. Which is why I said this behavior will be desirable to some, and undesirable to others.

Is this why Bitwarden are doing it though? I provided my own reasoning, but the official word from Bitwarden (further up this thread) does not cite an increase in security. It seems their argument is more that the logistics are too messy to implement (which I don’t agree with).

Hey folks - there are a couple of items going on in this thread:

  1. Share/“un-share” UI/UX. There is a request to make sharing via collections more point+click and less visually confusing, as well as making it easier to manage who has access to what data. This is good feedback, and we are always looking to make things as easy for end users as possible, within the scope of security and our architecture’s purpose.

We handle sharing the way we do currently (from a UI/UX standpoint) with a leaning towards enterprise-group-usage moreso than many individual user-user shares

  1. Request to actually “un-share” data. This is where it gets tricky and opinionated. Data can’t be truly unshared, as @d.b described - and the best practice is to remove the credentials & change them.

In regard to product functions, the guise of “un-sharing” can be had by doing one of 2 things:

  1. The org admin / owner can clone the item and delete the shared item
  2. The item in question can simply be unassigned from any collections, or to a collection available only to a specific user-group (perhaps one that handles password changes?)

Hopefully this answers more questions than it creates :slight_smile:

2 Likes

Taking already shared credentials from an organization and placing them into a private vault essentially implies them to have been compromised—as far as private utility is concerned—even if it’s sometimes only a theoretical risk. This is the “data can’t be truly unshared” issue.

To help solve that, after “unsharing”, these credentials could be visually “attention needed” flagged as being compromised, as a reminder and means of tracking whether they’ve yet been changed.

Each unshared item could have a single flag, or Bitwarden could specifically and granularly track the last change date of their secrets (passwords, TOTP keys and hidden fields). Unflagging can also either be manual, or automatic after changing the relevant values.

(I posted a much more extensive, organization-vault version of such flagging in another feature request, but you don’t have to go there for details relevant to personal-vault unshare flagging.)

1 Like

I think there should at least be a Clone/Copy option as a short term solution. Deleting and recreating means I lose my custom fields, URL settings, notes, and other important data with that site. The password isn’t the only important thing.

Cloning is currently available :slight_smile: - you just need to be an admin/owner of the vault item to perform the process.

1 Like

Looks like a step in the right direction. Will play with the feature a bit.

Thanks!

Hey folks - there are a couple of items going on in this thread:

  1. Share/“un-share” UI/UX. There is a request to make sharing via collections more point+click and less visually confusing, as well as making it easier to manage who has access to what data. This is good feedback, and we are always looking to make things as easy for end users as possible, within the scope of security and our architecture’s purpose.

We handle sharing the way we do currently (from a UI/UX standpoint) with a leaning towards enterprise-group-usage moreso than many individual user-user shares

  1. Request to actually “un-share” data . This is where it gets tricky and opinionated. Data can’t be truly unshared, as @d.b described - and the best practice is to remove the credentials & change them.

In regard to product functions, the guise of “un-sharing” can be had by doing one of 2 things:

  1. The org admin / owner can clone the item and delete the shared item
  2. The item in question can simply be unassigned from any collections, or to a collection available only to a specific user-group (perhaps one that handles password changes?)

Hopefully this answers more questions than it creates

@tgreer I have one question: what has been done in 2 years towards solving the problem that has been clearly stated more than 2 years ago?

Please don’t tell us that all that has happened is that you folks took 2 year to understand the issue, you are surely well above and beyond, so it’s reasonable that we expect some sort of concrete solution on this by now.

Wow this does seem to be a mountain out of a molehill.

I tried Bitwarden a year or two ago for family sharing and dismissed it because of these issues. I’m giving it another go now as there aren’t too many good options, but I really can’t believe this is still an issue.

I disagree with the argument that transfer into a private vault shouldn’t be allowed as it’s a security risk (as the password could be widely known) - these are 2 separate things - changing the password is what actually takes the resource back to private ownership - completely irrespective of whatever happens to our records in Bitwarden. What we want to transfer in Bitwarden is the data associated with a resource (which is often more than just a password: notes, other fields etc) to reflect the fact this information is no longer relevant to other users in the organisation.

I’m a developer and if I was going to solve this (within their current sharing architecture) I would:

  • Add a setting on the organisation so owners can set whether or not “Unshare/Take Ownership” (or whatever you want to call it) is available. That should appease the people who prefer how it works now.
  • If that’s ticked, any item in that organisation that you can delete, you also get the option to “Take”. This simply transfers into your personal vault and deletes the org item - ie reverse of a transfer into the org. If the item has a password associated, the UI would warn that others in the organisation may know this password and you should change it.
  • The vault health report could identify any items where the password hasn’t been changed since they were taken from an organisation

That should be a pretty simple change, is there any reason we can’t do that?

Personally I’d also favour changing terminology “folders” to “tags” and “share” to “transfer” - that would make things more intuitive for new users, but if that’s going to bother existing users, I don’t think it’s a big deal to make that mental adjustment once you understand how it works.

4 Likes

@thewarden - sorry for the delay on your question. The 2 years has been spent improving other aspects of the platform, adding enterprise functions, etc. - and the reality is that the UI for share/unshare was not a high priority item. It’s also important to remember that Bitwarden was an incredibly tiny team until the beginning of 2020 - so only the most critical items were the focus.

@madz - I think this would be a great idea to toss into the contribution category, and we can see what options there may be for you to help solve this :slight_smile:

Hello tgreer,

The clone function does not help to solve the ownership issue because the original ownership is always transferred to the clone copy.

I went into my personal vault to make a copy of a shared item as the owner of the associated organization. The clone copy also belonged to the organization. Furthermore the Bitwarden pieces of software refused to make the clone copy when I ticked off all the collections. It HAD TO be associated to a collection. I tried in the Linux application and in the Web interface to no avail.

I played around with Bitwarden functions and parameters for a very long time without finding a simple way to “unshare” an item, i.e., to transfer ownership from an organization to the owner of the organization. The only two ways I found were (i) to open two instances of a Bitwarden interface and to manually copy all the item fields from the original item to a newly created one in the personal vault; (ii) to export the organization vault in json, manually delete everything but the target item, and update its ownership in a text editor to import the file in the personal vault. Two error-prone ways, specially the second one.

Since you seemed to announce the clone function as a way to solve the ownership issue, did I misuse it or the function does not help?

Thanks for your constant help in the forum.

Hi @mpiter! Thanks and welcome!

If you’re an organization owner, inside your organization web vault when you clone an item, you should see an option at the bottom to select who owns the item. You can change from the org name > your email address and then the clone will belong to your user only.

Though, probably the easiest (from a management standpoint) to “un-share” is to have a collection that no one but the owners/admins have access to, and simply assign the item to only that collection.

3 Likes

Thank you very much. That was exactly what I needed. I cannot believe that I was so blind that I missed the right field when I cloned an item.

I showed Bitwarden to a friend yesterday. He tried it and liked it a lot. I think he will also buy a family plan. I have just gone premium to support Bitwarden.

Thanks again for your quick help.

2 Likes

@mpiter - glad to help! And thanks for not un-sharing Bitwarden! :sweat_smile:

1 Like

Deleted my reply about how stupid this decision is, great!

You’re free to voice your thoughts in a polite manner.

You’re also more than welcome to disagree with mine or anyone else’s opinion - politely.

1 Like

I agree the lack of an unshare feature is unintuitive, and I hope it will be implemented (with appropriate warnings and/or checks as suggested). Meanwhile, I’m relieved to have found a usable enough workaround (based on tgreers’ suggestion above – thank you!):

As the “owner” of an “organization” representing a two-person family, I’ve made two collections, one called “Shared” (available to both of us) and the other called “Unshared” (available only to me). To unshare a login, I edit it so that it belongs only to the Unshared collection.

(Since I trust my wife, I don’t bother to change the password after unsharing. I only unshare it to avoid the confusion of having two autofills available for a given site.)

One thing that makes even this workaround confusing is the fact that in the Web Vault, the Edit Item screen lacks Collections information.

Thankfully, Collections can be edited in various other ways: from a list of logins in the Web Vault (click the gear icon to the right of a login), from the browser extension (Edit Item), from the mobile apps (Edit Item).

2 Likes

Hello Everyone,
building on this, I thought how one could implement this. For 2FA authentications there is a possibility to implement it. Therefore I Wrote a new feature request since it is not exact the same … .

Maybe this implementation is also useful for you :smiley: :