1 Item - Multiple Vaults?
Comments
-
@rsberlo: Thanks for chiming in. Can you clarify what you imagine would be easier about (hypothetically) sharing a single item versus (actually) sharing a vault? Also, can you give a specific example where you "create a zillion vaults for individual passwords"? Even within fairly large companies the odds of never sharing data with the same person twice doesn't seem to be common, so I'm curious.
0 -
Maybe this is more relevant in mid-sized companies where people are wearing many hats. We are at about 200 employees.
Today for example, the Team A wanted to share edit access to our company wiki with someone from the Team B. We don't want to give Team B access to all the passwords in the Team A vault, obviously. And we don't want to duplicate the item into the Team B vault, which will then be out of sync for future password updates. So I ended up creating a vault specific to that one item, and shared it with the people team + 1.
Another example would be sharing a password between two individuals, where we have to create a "John/Susie" vault. This happens all the time, and to be frank, it's likely affecting our compliance as people are much more likely to bypass this process in favor of what's easy.
In some ways it's just the way people think. In the past (and probably still) people would send each other credentials in plain text via Slack, which we are obviously working hard to discourage. It seems there should be a secure replacement for this use case.
Hope this helps!
0 -
@rsberlo: I really appreciate it! Those are great examples.
I guess the question I have is then why doesn't sharing a vault work? It sounds like it's just a usability issue, honestly, and that making it easier to share vaults -- or create a shared vault automatically when the user tries to share (an) item(s) -- is really what is needed, not "item sharing"
If we can continue to use vaults for sharing, we keep the security and usability benefits of that. That last bit may sound absurd to you in your present situation, but hear me out:
Each vault is encrypted with unique "keys" which is how people in the team no not have access to things they should. I don't think there's no argument that that is a good thing. But the usability benefit is that it's really easy to tell who has access to a vault as a result. For example, let's say you're sharing a vault with Team A and Team B. By contrast, imagine if you had to keep track of who had access to individual items within that same vault instead. Suddenly it becomes more like trying to figure out inherited Unix permissions in nested directories, and, to be honest, that makes my eyes cross. I can't imagine that this is going to be easy for everyone on your team either, and just thinking about how to present that visually gives me a rash. In the "item sharing" future, are we going to have to view a vault's contents and scroll through long lists, sort by "person", etc. to figure this stuff out? It doesn't really scale, in a lot of ways, and it seems to me we'd just be trading one usability problem for another. So we need to consider the non-security ramifications of doing something like that as well. But it's a problem worth solving, and we'll keep brainstorming. :)
ref: b5/b5#6207
0 -
I love the idea of auto-creating a vault on sharing a single item! It could be an option in the sharing dropdown (share via 1Password).
- User clicks share button, selects share via 1password
- They select individuals or groups from their org
- Next screen prompts them to name the auto-created vault (maybe with an auto-naming feature like John/Linda)
- New vault is created and item is shared
The only issue here is that if the item is already in a shared vault, a solution is needed for this use case. Maybe the item is moved to a new vault that includes all individuals/groups with access to the former vault, with the new people added.
0 -
I'd like to throw my support behind having this capability. As we move to more dispersed/virtual teams consisting of people working at one site and lots of people clustered remotely around jobs, it becomes harder and harder to manage things using a vault abstraction.
e.g I have local Tech team that needs access to all things tech (db's, websites, AWS logins, etc.) and we also have remote developers and freelance developers. They have some overlapping needs for access and some new needs. The overlapping needs are causing issues.
We can't create a new vault for every combination of user groups. And creating groups doesn't help. Which means we now have Tech logins scattered over multiple vaults and people have to remember which vault things are in. Maybe one solution would be to have a linked account across vaults. I get the complexities with keys and encryption, but I think that could be solved with a linked list of connected logins (each login has a linked list to the matching logins) which then allows update across all linked logins that the person changing the password has access to. Sure - its not a perfect solution - if a person, who doesn't have access to the linked logins, updates the password, then the linked logins won't be updated. But that can be solved by a human process that only someone who has access to all vaults would be able to update the passwords everywhere. Not perfect I know. But enough value to make it useful.0 -
It is definitely a problem we'd like to solve @bernardof. I don't mean to make excuses, but there are a number of complexities. Some of them are on the technical side, such as the problem of keys that you alluded to, and others are more customer facing (e.g. how do we build a UI that adequately conveys this concept). There has been some recent discussion around this internally so the idea certainly hasn't been forgotten, it is just going to take a fair amount of time, elbow grease, and ingenuity to make it happen. I can't promise anything at this point, but I do have my fingers crossed.
Ben
0 -
I'd also weight in for the "linked" ressources between vaults.
It apparently was in the roadmap 5 years ago : https://discussions.agilebits.com/discussion/comment/116923/
I totally understand why it makes sense in an architectural point of view (ie: Each vault is encrypted with unique keys), but from an UX point of view you can see that it can create some issues.
We currently use Vaults as some sort of team or cross-team repositories. ie: Product / Technical / Infrastructure / Management / HR / etc..
Some services could be used cross-team, for example tools shared between Marketing and Product. This happens frequently.At the moment I have to either :
- Create ad-hoc cross-team vaults, which isn't handy to manage and doesn't really reflect our organization
- Duplicate the access in vaults, but consequently : I have watchtowers indicating that I use the same password on multiple accounts, red notifications on the item detail, increase possibility of having desynchronized informations etc.. And also it triggers my OCD quite badly ;)
From a technical/product POV, I suppose you could have some sort of "master" access in a vault, and the other vaults would just be synchronized or duplicated for that ressource, real time or asynch.
That's just a quick thought, I'm pretty sure you guys can find a lot of very cool technical solutions, as long as the link/share usecase is covered.--> As a team user, I want to link an item from a vault to another one, so that I can share an access to other teams/functions without having to handle multiple duplicated resources or messing up my vault organization
;)
0 -
Upvote
Hello, we want to migrate from OneLogin to 1Password and we are also very much missing this feature.
0 -
Welcome to the forum, @vladimir_smartsupp! Thanks for weighing in on this. I don't have anything to announce regarding it at this time, but keep your eye on updates and their associated release notes for the latest news about new features and changes. Thanks for being a 1Password user!
0 -
As the comments here attest, asking folks to use vaults for item access control is always going to blow up.
For N users (or groups with identical access needs) there are (2^N)-1 possible sharing groups (https://www.geeksforgeeks.org/number-distinct-subsets-set/). Just coming up with a suitable naming scheme for all these , and manually updating the access per vault is error-prone. Moving items around between vaults to update access rights is also clunky.
This workaround is also incompatible with the natural, intended use of vaults as a way to store related items. As soon as an item needs ‘custom’ access, it has to be removed from its ‘home’ vault.
Even on a family account with 3 users (7 permutations) I’m getting bitten by this! —this would certainly be a showstopper for me if I wanted to use 1P across a larger org.
I’m aware it’s due to a fundamental architectural choice, but it certainly is a real pain point. Some other folks on this thread have suggested workarounds involving making ‘aliases’ and doing cross-vault sync. Consider this post a (long) +1 for something like that.
Otherwise thanks for an awesome product! The usability is miles ahead of the competition and 1P is a joy to use.
0 -
Thanks very much for the detailed feedback on this @fbeisn. We certainly understand the pain. As you might imagine we run into similar situations within our own organization. That said, aliases and cross-vault sync probably wouldn't work. Imagine this scenario:
Bob has access to the Financial vault but not the Operations vault. Sue has access to the Operations vault but not the Financial vault. The Amazon login item for their organization lives in the Financial vault, but is aliased/cross-vault synced to the Operations vault because both Bob and Sue need access to it. Bob decides it is time to change the password for Amazon and updates the record in the Financial vault. Bob doesn't have the keys in order to get that item updated in the Operations vault. The only ways I can see how we could do that would be to:
- Give everyone who has the keys to the Financial vault the keys to the Operations vault (and vice versa), but have the server enforce allowing them access to only the Amazon item. I don't imagine this would be an acceptable solution in the eyes of our security team as it significantly reduces our strongest link: encryption.
- Only allow editing of the item by someone with keys to both vaults. This creates problems of its own. What do you do in a situation where nobody has access to both? And would that really be an acceptable solution anyway?
- Have the server have the keys and when it notices a change to an aliased item it would update it in both vaults. I can say for certain we will not do this. It would put us in a position where we could access customer data, and that is absolutely not a position we will put ourselves in.
We recognize the problem. The difficulty is in coming up with a good solution that would both address the problem sufficiently and does not compromise our security model. :)
Ben
0 -
Hey @Ben,
Thanks for the thoughtful reply.
I’m not a security engineer, but it seems like a 4th solution could involve a secure message-passing system between vaults. In your example above, when Bob updates the Amazon PW, a (signed) message with the (encrypted) new PW is sent to all the vaults that have a copy of that item. The next time that vault is opened (by Sue) the queue of update messages can be processed, and the PW will be updated appropriately.
(I.e. the cross-vault updates wouldn’t be synchronous, and the person doing the updating would not have to have access to any of the vaults containing a copy.)
Of course, now you have a distributed synchronization problem! (Which I will leave as an exercise to the real engineers ;) ). But since you already allow offline access from multiple devices, maybe you have already solved the sync problem... (You could mitigate the sync problem by making link-sharing read-only, but that doesn’t work in the general case because once Sue has the Amazon password she can presumably change the password with Amazon, but will have no means to update the record in 1P.)
I think this approach could mostly address the combinatorial explosion of vaults: Bob and Sue would not have to create a separate “operations+financial share” vault and manually maintain the permissions there.
It would also provides a mechanism for item-level ‘read-only’ sharing of information, in cases where that’s useful (sharing a credit card number, e.g.)Hope this is helpful! It’s kind of fun to think about in any event :)
0 -
Hope this is helpful! It’s kind of fun to think about in any event :)
Agreed! I spoke with our VP of Engineering for 1Password.com, Rick, about this, and this was his reply:
That’s a fun solution, @fbeisn. I think it can be simpler than that though. The tricky part with your solution is figuring out what keys to use for encrypting the message. Our vaults currently only have symmetric keys, so you couldn’t use that. To make it work, you’d need to have the vaults also have public private key pairs I think. Then you’d encrypt the new item with the destination vault’s pub key. But if you’re going that far I feel like you could then build a system that doesn’t require a message queue at all and just have items in the vault be encrypted by the key pair. I might be missing something though.
A lot of solutions to this problem aren’t conceptually difficult. The challenge lies in how to implement it on top of what we already have and to do so in a manner that causes the least problems with older apps that don’t understand the new way of thinking.Rick
I hope that helps. Should you have any other questions or concerns, please feel free to ask.
Ben
0 -
I would like to have this feature as well. Just to throw in my 2 cents on the matter... I assume that each item in a vault has a unique identifier of sorts. Would it be possible to establish a multi-vault identifier? If it's present, that value is used for items across vaults, and if a change is made to an item that has that, it informs the other vaults on the same system that use the same multi-vault identifier. I believe that UUIDs grant us enough security in their distribution to avoid a collision.
Now, there's a problem that was mentioned previously, if we suppose:
- user A only has access to vaults 1 and 2
- user B has access to vaults 2 and 3
- user C only has access to vault 3
What happens when user A updates the password? Since it's a singular item in their 1Password UI, let's assume that the software knows to look for this multi-vault identifier and update the item in both vaults 1 and 2 (using the symmetric keys that are already available / stored in memory). Then, when user B next syncs the data in vault 2, 1Password could detect a change has occurred in vault 2, but as it is a linked item, the same change did not seem to come across in vault 3 (or maybe it did, then it stops there). From this point, it could automatically update the data in vault 3 as well, which then further propagate to user C. In this manner, there's no additional syncing architecture required other than the handling of a multi-vault identifier and ensuring consistency across items with the same identifier.
I very much like the idea of sharing an item across vaults just as a security measure for myself - I want to make sure that I retain a given credential even if I lose access to a certain vault (i.e. I'm sharing a vault with a business partner and we decide to part ways, what's to prevent that person from deleting the entire vault?), and while I know there are some additional risks in this that are present in any situation, I think it would be very beneficial to the community to allow some sort of linking of items - of course with a discretionary warning to alert the user to the security implications of this choice.
0 -
What you're describing is an option we've looked at with some seriousness. It has some big benefits in the simple case (userA knows to update vault 1 and 2), but the additional complexity of user B's device also knowing that it's responsible for propagating a change isn't as simple as it might seem (sync is hard). We haven't convinced ourselves that this is the way to go.
It's a feature that I'd really like us to build, and I think if we could go back in time we would have made sure to design our original vault system such that building this would be trivial. I suspect that one of the changes we'd have done was to keep a design decision from our old OPVault format where each item is encrypted with its own key instead of sharing a vault key. I feel like there's a good chance that this would have bought us a lot for this problem. It's often difficult to retrofit stuff like that into an existing system, especially since everything is client-side encrypted and we can't run any mass migrations on our server end to help with much.
Rick
0 -
If I may continue this dialogue, how do you guys implement sync? From my personal experience, I think the "physical" vault is stored on a syncable storage device (Dropbox, iCloud, Google Drive, whatever). Does 1Password keep an index in memory? How does it actually know that an update was made to an item? Or does it not matter, as long as the underlying storage reflects the current state of truth?
Thinking about this further, I do see how adding a "hook" to a sync event could be complicated, but I do wonder if "hooks" would be possible at all - and that depends on the answer to the above questions.
Would the OPVault have allowed you to make a symbolic link across physical vaults? Since each item had it's own key, you would therefore be able to share the key between the two vaults that reference this item?
Thanks for your time, by the way, I do appreciate the insight into the inner workings of 1Password :chuffed:
0 -
If I may continue this dialogue, how do you guys implement sync?
Probably my favorite question ever asked. I enjoy talking (writing?) about this stuff way too much. I'll do my best not to bore you with irrelevant details.
From my personal experience, I think the "physical" vault is stored on a syncable storage device (Dropbox, iCloud, Google Drive, whatever). Does 1Password keep an index in memory? How does it actually know that an update was made to an item? Or does it not matter, as long as the underlying storage reflects the current state of truth?
The complexity of sync stems from the fact that you've got multiple representations of the "same" data. 1Password is meant to be usable completely offline, so it needs a complete offline cache of everything. We treat that as the primary datastore. On all nearly all platforms that's a sqlite database. Then you've got the sync database.
Before 1Password.com, there was a sync vault stored on the syncable storage device. We used OPVault and AgileKeychain before it as the sync vault formats (both of which are publicly documented). We were heavily dependent on the syncable storage provider to help us do the right thing, as otherwise it would have been too easy for device 1 to overwrite device 2's changes. Dropbox handled this by creating "conflict files" which was a copy of the file you tried to write if two devices tried to write to the same file without first coordinating things. It was good, but never quite 100%. It especially problematic as the number of devices syncing to the same file grew. It was a major contributing factor to us deciding to design 1Password.com: we wanted to own the experience end to end.
Now with 1Password.com things are simpler and more in our control. Each item has a version number, and each vault has a content version number. For the most part (at least this discussion), the item's version number isn't relevant so let's ignore it. A vault starts its life at content version 1 and is empty. A client will add the item to its local database and mark itself as dirty (it's more than just a dirty flag, but again, irrelevant). Eventually sync gets triggered. The first thing that happens is that the client asks the server for a lay of the land. In this lay of the land (what we call the sync overview call), the server will reply with a list of vaults and include the current content version. The 1Password.com server is the source of truth, so if the server says current content version is 3 that's the truth. The client sees that 3 is greater than 1, so it knows that there's data it should fetch. So it will pull down the changes, in batches if needed. Each batch will get the client all of the data needed to get to content version X. The client will pull down batches until the server says there's no more work. While pulling down each batch, it'll write the data into the local database but it'll be careful not to overwrite any local changes. If an item has a local change that would be overwritten by the server then the client needs to decide how to proceed. In most of our apps this means doing "conflict resolution" which means we analyze both the local changes and the server's changes and see if they can be merged together or if both sets are conflicting. If it's conflicting the client creates a special custom section in the item and puts the conflicting data in there. Once the client is done pulling down local changes, it'll then look to see if it has any local changes (dirty flags) that need to be pushed up. To do this it gathers (and batches) the changes and will make a request to the server to say "here are some changes that I'd like to apply on top of content version X". The server will check to see if the provided content version is still the current content version, if not it returns an error and the client knows that it needs to go back to pulling down changes before trying to push any changes. Eventually the client will have the correct latest content version (and its contents) and will be allowed to push its changes to the server. The server writes those changes, increments the content version and reports success back to the client allowing it to dismiss the dirty flags and set its own content version to the new value.
Going back to your proposed solution, you're right we'd need a hook such that every time the client downloads new content from the server it would need to look and see if it's an item that's shared across multiple vaults. If so it would need to go find the associated items and propagate the changes. This sounds relatively easy but the devil is always in the details. You would want to make sure that either two devices don't do the propagation work needlessly, or more likely would need to make sure that two devices that do the propagation don't end up getting in each others' hair. This could be done by adding some kind of versioning to uniquely identify the propagation. You'd then need to make sure that the conflict resolvers look to see if the changes match based on that versioning and if so dismiss some local changes (I've never put thought towards dismissing dirty flags like that, so I'd have to think longer about how confidently that could be done).
Would the OPVault have allowed you to make a symbolic link across physical vaults? Since each item had it's own key, you would therefore be able to share the key between the two vaults that reference this item?
Right, that's where my head is going. If each item has its own key then the vault isn't protecting the vault items, it's protecting the vault item keys. If you know that (vaultA, item1) and (vaultB, item2) are effectively tied at the hip and share the same key, then when a client posts an update vault A with an updated item1 then the server could take that exact same data and update item2, incrementing vaultB's content version. I'm sure it'd be a little more complicated than that, cause as i mentioned above we put a lot of work into coordinating writes to a vault based on content versions and what i described there is pretty shoot-from-the-hip from vaultB's perspective.
I hope that helps shed a bit of light on things.
Cheers.
Rick
0 -
Same issue here - looking to migrate away from Passpack v7 - 1Password was checking all the boxes until i hit this weird roadblock. UI-wise, passpack v7 makes it very simple. You can view passwords shared per group or per person. You can select in each password which group/person combination to share it with.
Looks like we might have to pass on 1Password - too bad.
0 -
Hi Ben, thanks for the answer! Here's the reply i got from the business team. It seems like they would think this use case goes against other use cases, whereas i think a good product design could make them complementary and allow different orgs to use different schemes. Thank you for your help!
Thank you for your email and your feedback. We appreciate you taking the time to write this.
We are very aware that this is an often requested feature and our developers are considering options for adding something like it. If you read the thread starting here, you'll see the responses from Rick Fillion, our head of platform development: https://discussions.agilebits.com/discussion/comment/557108/#Comment_557108
One thing you may want to consider in your deliberations is that we have no small number of customers switching to 1Password because this feature doesn't exists. In many cases and particularly for two of the companies you've mentioned, having the ability to keep an item in multiple places, all with different degrees of access for any number of people, has caused immense management overhead, loss of data, and access violations to the point where a more closed-off approach with clearly defined and transparent access privileges was more sensible and allowed the implementation and enforcement of the principle of least privilege.
I'm fully aware that this is quite specific to the needs of an organisation and could possibly be solved by a matching UX/UI on our end but it's hard to deny that keeping items in multiple places can add a high degree of complexity for the admins and the end user.
I hope that in the future we're going to find a satisfying solution for this.
0 -
+1 for really wanting this feature. It is huge for me.
0 -
I wanted to add my own +1 to the idea of having shared items across vaults. We're only ~120 users but we are already experiencing vault proliferation (over 50 vaults, most of which have only a couple of items) because we have to create a vault for every conceivable combination of needs.
Despite this, we are still running into issues where items have been duplicated across multiple vaults without people realizing it. This causes everything to go understandably pear-shaped when one of them updates the password.
Being able to have the same items shared between multiple vaults would eliminate these issues.
0 -
I would also like to see the following being solved by 1Password, it would be really useful.
Being able to have the same items shared between multiple vaults would eliminate these issues.
0 -
Hey! I am also very interested within this feature. Any clue on when this is scheduled for development @Ben ? :)
0
