1

We have an application that holds a bunch of passwords in an encrypted vault for various purposes. What is the best practice for storing the key for that vault? There feels like there's a bootstrapping problem where the master key needs to be in our source code or accessible unencrypted somewhere, hence the bootstrapping issue.

The application is accessed by many different users who each have their own passwords, managed the normal hash+salt protected database way. I thought a sneak for this could be to store the password on each user encrypted with their password, but that also feels insecure, leaking too much information, and is also problematic when creating new users.

Try as I might, I can't find any best practices on this, turns out googleing "vault" gets a lot of Azure answers, but I'd like a platform-agnostic answer.

3
  • Welcome to the community. You're trying to protect a password vault? Research what methods existing password managers already use and then ask the question please. If you don't know of any I may recommend to take a look at Bitwarden for example Commented Feb 2 at 16:41
  • 1
    My first question is: why did you design it that way (with a single key) when you needed to share access? This sounds like a design issue, not a security issue. Many secrets vaults have design patterns that you can look to to solve this issue and allow multiple people to access the vault and still be able to revoke that access. I'm also thinking that you have not shared enough about how the application works and how access to the vault works.
    – schroeder
    Commented Feb 2 at 17:16
  • Rather than a password manager, it stores passwords for integrations with other systems, that any given user might fire off. The structure of a password vault for these has been handed down from on high, and from the history of it's development. I assumed that there was an established literature on bootstrapping, but I've not found anything in the month on and off researching this.
    – Hovestar
    Commented Feb 2 at 20:00

1 Answer 1

0

Asymmetric encryption could work here. For every user, you can create a public-private key pair and encrypt the private key with the user's password. This should be done on the user’s device, so within the mobile app, or with JS in the browser, so the password is not exposed to you, nor their unencrypted private key. You can then transmit their public key to your server.

To give the user access to the vault, you can encrypt the master key with the user's public key. You transmit that back to the use and only the user can decrypt the master key using their private key.

You should not keep the master password in the source code. Rather you should have a secure host that has a secure user account under which the random master password is created. To add a new user to the vault the new user’s public key can be sent to the secure host. It can then encrypt the master with the new users private key then send the encrypted master key back to the user.

There are different ways to securely backup the host that controls the master key. Else Shamir’s Secret Sharing can be used to backup the key in case the secure host is destroyed.

3
  • The more I've pondered this, the more needed that secondary service is. And if I have that secondary service, I might as well move authentication to that.
    – Hovestar
    Commented Feb 6 at 13:05
  • authentication isn't authorization, and authorization isn't encryption :-) mixing all those concerns into one service is dangerous. the secure host/service holds the master encryption key. you should generate that master key once at startup within that host/service and never export it from that secure location. that service should ideally only do the one task of encrypting the master key with the users public key. then try to use mature, hardened and dedicated authentication and authorization services. have your vault encryption service depend upon them. then you will be more secure.
    – simbo1905
    Commented Feb 6 at 17:30
  • you mention hash+salt for your authentication. you could look to use Secure Remote Password protocol (SRP) so that the user never has to transmit their password to you. there are a number of opensource libraries out there see en.wikipedia.org/wiki/Secure_Remote_Password_protocol
    – simbo1905
    Commented Feb 6 at 17:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .