I would like to create a shared "password wallet" where I encrypt several instances of a username/password and store it in a common location.

I don't expect all key/value pairs to have the same encryption key; in fact I'd prefer that most usernames and passwords were encrypted using a different key.

What is the ideal crypto technology to use in this case?

  • Is there still one password/passphrase to open the wallet (and use anything within)? – Matthew Flaschen Mar 25 '11 at 17:54
  • @Matthew - I'd like to have more than one person have access to sections of the wallet. That is why I said each username/password might have a different key. Another way of phrasing this is that I have many many wallets, but not every user has access to every wallet. Some have none; some have access to one or more. – goodguys_activate Mar 25 '11 at 18:36
  • 1
    It would help to clarify your goal and context first. And what do you mean by "several instances of a username/password". Do you mean many distinct username/password pairs, or one u/p encrypted with different keys? – nealmcb Mar 25 '11 at 18:45
  • @nealmcb I'm implementation agnostic at this point... but I functionally want to share a single u/p blob with many consumers. If I were to encrypt a u/p with (say 100) keys and all those keys were required for decryption, then that is something I don't want. – goodguys_activate Mar 25 '11 at 18:53

There are two simple ways to do this.

  1. The simplest is to have one wallet per individual. If both Alice and Bob should be allowed to view a particular username/password combination, no problem, you just add it to both their wallets. Each individual's wallet is encrypted using the passphrase that individual uses to open their wallet.

    This is a very simple scheme. Before you object that it requires storing multiple copies of some entries, I want to remind you that space is cheap. The extra storage required is absolutely trivial.

  2. Here is a slightly more clever, and slightly less simple, solution. For each username/password combination, you pick a new random symmetric key K. You encrypt the username and password under K. Then, for each user who is authorized to read this username/password, you append an encryption of K under that user's passphrase.

    For instance, suppose Alice and Bob are authorized to read the username/password "bloggerdude/fye7wi". Suppose the passphrase that Alice uses for opening his wallet is PA, and the passphrase that Bob uses for opening his wallet is PB. Then you might store the following entry in your wallet:

    Encrypt(K, "bloggerdude/fye7wi"), Encrypt(PA, K), Encrypt(PB, K).

    I don't think this has any strong advantages over the first scheme, but I thought I'd mention it for completeness.

Lastly, I'd like to mention a few other considerations you may want to keep in mind, as you design your wallet:

  • I suggest you use some mechanism to slow down dictionary attacks on people's passwords. For instance, you might use PBKDF or the bcrypt password hash.

  • Use a random salt. Never store any deterministic function of just a user password; that is vulnerable to time-memory tradeoffs ("rainbow tables", in the popular venacular, though it's broader than that).

  • You might consider providing an easy way for users to generate a new strong password, to add to the wallet, when they create an account on a new site and need a password to go with it.

| improve this answer | |

One idea based on key slots similar to LUKS:

Each person can have their own passphrase that derives to what we'll call the passphrase key. Then, when they try to open a section, iterate over the section key slots (of which there can be an arbitrary number) until you find one the passphrase key can decrypt to the section key. The section key decrypts the passwords in that section.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.