-
Notifications
You must be signed in to change notification settings - Fork 89
Create a default "Personal" vault on signup #19
Comments
Vaults are dead. No longer relevant. |
What are you thinking to replace the Vaults? |
Vaults were too rigid. They work for companies like GitHub where people are either employees or not, but it gets weird with consulting companies and individuals, where you interact with a lot of random users that don't always fit into a bucket. I think sharing items directly with individuals or teams is the most flexible solution. For sharing with individuals, see Eventually, I want to add the concept of Teams, where you can add a user to a team, share items with that team, and any new user added to the team gets access to the items. Technically, that will involve encrypting the item key with the team key, and then encrypting the team key with each user's public key. In mongo pseudo code, here's what that persistance will look like: // Add a new team and generate a random key in memory, but don't persist it.
db.teams.add({"id": "…id…", name: "Platformatec"})
// Add the creator of the team as a member, encrypting the in-memory team key
// with the owner's private key.
db.memberships.add({"team_id": "…id…", "user_id": "…id…",
key: "[randomly generated team key encrypted with user's public key]"})
// Share an item with a team by decrypting the team key with your private key
// and using that to encrypt the item key.
db.shares.add({"item_id": "…id…", "team_id": "…id…",
key: "[item id encrypted with team key]"}) With this model, adding a member to a team is just a matter of decrypting the team key with your private key, and re-encrypting it with the user's public key. You don't have to re-encrypt the key for every item shared with the team. The team key is never persisted unencrypted, just as the item key is never persisted unencrypted. Make sense? |
So, if I understand correctly, the team will be basically a symmetric key that will be saved encrypted for every user. And this symmetric key will be responsible for encrypting the item's password. Well, that makes a lot of sense!. The only issue would be if we wanted to restrict some users to not share an item's password with anybody else. But then again, he could simply decrypted the password and send them in any other way that doesn't involve Swordfish :) I want to try to help with development, but I'm still not used to this codebase and all the crypto-stuff in it. Is there a simple feature that you recommend in order to begin? |
No description provided.
The text was updated successfully, but these errors were encountered: