@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.
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!
@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.
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).
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.
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.
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.
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 :
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
Thanks for sharing @alexisd. I don't have anything further to add beyond what I said above, but we do appreciate the continued feedback on the subject.