Programs like KeyPass and 1Password store password database files encrypted by a single password. If someone knows the protecting password ("Vault Key"), they can read the entire database ("secrets").
Being part of a family, I sometimes share passwords with my wife and others for bank accounts or Netflix which we manage jointly or personal accounts which another might need access to if one were incapacitated.
With a software like DropBox, password databases might be synchronized among family members. For different permutations of sharing, different databases might be used each with different Vault Keys. But as particiation or sharing complexity increases, the number of databases and keys grows more quickly (1 user => 1 database, 2 users => 3 databases, 3 users => 12 databases!). Even if multiple Vault Keys are supported in a single database, concurrent edits among users could cause problems for DropBox and similar.
I envision a scheme whereby each user has their own single database file, protected by a private Vault Key. Part of the database file format allows publication of selected secrets from the private list to be shared with other members. I could, for example, share my Netflix password with my wife by including it in the shared list of my database.
To enable the scheme, a private key which rarely changes would be protected by my Vault Key, which can change often. My public key is available in the clear. Each secret record in the database gets its own symmetric key which is encrypted and signed by the keys of the owner, and the secret record key is also encrypted once each by the visible public keys of anyone (any other member's database file's public key) with whom the owner chooses to share the secret record.
If my wife wants to see my Netflix password, she reads my database from our shared dropbox folder and gets the list of records and encrypted record keys. She decrypts any record shared with her using her own Vault Key-protected private key. She can't change the record because I've signed it.
So, I write to my database my own secrets. I have a list of trusted targets (each family member's public key read from /their/ database file). Each of my secrets' keys are encrypted using my own public key, but also (separately) by the public keys of each share target that I have chosen. They can read from this file and decrypt the shared secrets' keys with their private key.
She or anyone else could mangle the file, but the version control in DropBox protects against that. The encrypted database files are to be considered semi-public, since any user with access to it might have a breach.
- Are there any implementations of this concept?
- What are the security problems with this scheme?
- What security gotchas await in a more complete description of this scheme?
- Is it terrible, for example, to keep a pk/PK pair even when changing the Vault Key? Or must it change every time? Changing the public key would invalidate the shares from others' databases. I guess we can keep a history of our key pairs until the others have had a chance to update their own databases for my latest key.
(Yes, Passpack allows such sharing perhaps with a different scheme, but frankly, it frightens me.)
Update: I appreciate the answers so far, but they were from a forum with a different lean. I'm more interested in the security-implementation critique of the scheme rather than getting recommendations of products that approximate it.
