# Security considerations for partially shared password databases

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.

-
LastPass is the only solution I'm aware of. It's web-based. However, it's a "freemium" service, so you do have to pay for certain features. I'm actually working on exactly the same sort of idea, except as a client/server app for commercial environments that require shared passwords. Obviously, it could be used at home, too. I aim to make it open source. –  Polynomial Aug 22 '12 at 5:55
That would be a jar in the kitchen, with passwords in it. Seriously, using mobile phone or pc is just too unpractical and also requires access to other information like SMS. –  Andrew Smith Aug 22 '12 at 10:23
@AndrewSmith - what in blue blazes are you talking about? –  uosɐſ Aug 22 '12 at 10:52
Cross-posting is frowned upon on Stack Exchange. Please pick one site to focus on, and ask the moderators to close the other one by using the "flag" button. Thank you! –  D.W. Aug 24 '12 at 4:11
I have been suggesting, that additional security layers at this level are not practical because passwords in case of emergency have to be available, hence the jar is the very best option. Also, it's one of the cheapest and easy to implement, especially kitchens already have many of them so you can refurbish some. –  Andrew Smith Aug 24 '12 at 16:05

What you are looking for is an authentication and access service on top of a password management system. There are a couple of solutions in this space, but they are corporate and expensive:

1. http://www.liebsoft.com/privileged_identity_management/
2. http://www.cyber-ark.com/digital-vault-products/pim-suite/index.asp
4. There are about 10 other companies and products in this space.

There are also some web based versions of keepass which may fit your needs, but then you'll need to secure the HTTPS, etc.

-
Great links. Thanks. Yeah, I'd like to avoid domain-specific services. I see value in a scheme that doesn't require a server or many moving parts. Just a file that you can store on a shared network folder, etc. KeyPass desktop with the ability to share one of your secrets with someone else's database. –  uosɐſ Aug 22 '12 at 13:39
If you want concurrent access, you may have issues with a regular file on system. –  Eric G Aug 22 '12 at 13:41
It's not concurrent write access - that's the point of one file per user. 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). 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. –  uosɐſ Aug 22 '12 at 13:48

If you wanted to do it yourself then I think something like this is what you would want to implement with a low threshold..and then write your own KeyPass....?

http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing


You would definitely have to build a Secret Sharing Password Vault by yourself. No well known software (that I know of) exists like what you are describing...but its possible....but I think you would need multiple layers of shared secrets to be managed....Sounds fun actually.

-
Yes, KeyPass with the ability to share one of your secrets with someone else's database. What multiple layers of shared secrets do you mean? –  uosɐſ Aug 22 '12 at 13:48
Using Sharmir's secret sharing scheme. If you want to share your Netflix password with your wife but not your security.stackexchange password with her then you may need to two different instances of the Secret Sharing Algorithm. One for each rule. A rule being, your wife is allowed and you are allowed, your wife is not allowed and you are allowed, your wife is allowed and you are not allowed, etc. –  Rell3oT Aug 22 '12 at 13:54
Also, Shamir's Secret Sharing is when I'd want /some or all/ of the members to be necessary to decrypt the key. This is not good for my intended use. –  uosɐſ Aug 22 '12 at 13:54
I don't understand. If you set it so 1 of your members must be present to decrypt...then either you or your wife could decrypt, but you know better than I do about your needs. –  Rell3oT Aug 22 '12 at 13:57
Ok, I guess that could work, setting it to 1. But that particular algorithm is intended for a different purpose of dividing the secret - not just sharing it. I think the same benefit can be achieved with more common algorithms, is all. –  uosɐſ Aug 22 '12 at 13:58