Secure Password Sharing

When you create a shared vault, your browser generates a random 256-bit AES vault key. The key wraps to your own RSA public key so you can decrypt it later. When you invite a member, your client fetches their public key from our directory, wraps the vault key to them, and uploads the wrapped copy. We store opaque wrapped keys; we never see the underlying AES key.

On their device, the invitee unwraps the vault key with their private key (which never leaves their device, encrypted at rest under their master password). From then on, they can decrypt every item in the vault locally. Encryption is symmetric; sharing the key is asymmetric. The plaintext path is end-to-end.

When you revoke a member, the client generates a new vault key, re-encrypts every item in the vault to the new key, re-wraps the new key to remaining members, and deletes the revoked member's wrapped copy. The whole rotation happens in your browser; we just store the new wrapped blobs.

The revoked member retains any data they already exfiltrated (we can't un-show a password they already saw), but they cannot decrypt anything written after revocation. For high-value credentials, rotate the upstream password (e.g., reset the Stripe API key) in addition to revoking — same as you would with any other shared secret.

One shared vault per project. Members assigned per-project, not per-credential. Audit logs grouped by vault for easy review.

Personal vault stays personal. Shared vaults are clearly labelled in the UI so you don't accidentally save a banking login to the team vault.

Rotate credentials when a member leaves a project, even if they're staying in the company. Same principle as code-access revocation.