[the_af]

Agreed that you absolutely cannot store sensitive passwords in your source code repo.

Your proposed solution, however, has its own share of problems for some deployment scenarios. Where do you get this file from? Assuming you are meant to place it by hand each time you deploy your application... what about autoscaling? What if you want unattended deployment of apps?

[joseph]

There are lots of ways to handle those scenarios.

Deciding where to store your secrets is extra easy if you're in the cloud. In AWS you can use KMS to store it if it's 4kb or less. A cli command or API call can decrypt it for you. If it's larger, you can use a tool such as credstash which lets KMS manage the keys.

If you're in an environment that's using Chef, it can handle them. Ansible has a solution as well.

Or you can use something like Hashicorp Vault, though it requires setting up servers for that purpose.

Once you've decided on one of these tools, it's no problem to script the retrieval of a secret into your deployment mechanism. It will work fine for autoscaling or any other unattended deployment.

[the_af]

Oh, yes, I didn't mean there wasn't a solution. We use Hashicorp Vault, for example. I simply meant that "store passwords in a file" (as mentioned in the post I replied to) is too simplistic to cover all scenarios.

[joseph]

Files are good because virtually anything can read and write them, so they are very portable. I used to work with a really great security guy who created a good system for handling secrets. He had us write them to files, but only to a tmpfs mount, so that they were written to memory and not disk. We also didn't write them to regular files, we used named pipes. This way the application on initialization would read a secret from the pipe and would block waiting for it to be available if it hadn't been written yet. There was a separate process in place to handle the retrieval of the secret and the writing of it to the pipe. As soon as it was written, the application would finish reading and continue its initialization. This ensured things happened in the correct order, and also made the file to be one-time-use.

[grogenaut]

Kms doesn't have a size limit if used right. You should use kms to store a key and store the data on s3 encrypted.

[joseph]

Sure, which is why I said to use e.g. credstash in such cases. It stores the secrets in DynamoDB while using KMS to handle the keys. I guess you are talking about using S3 server side encryption, which is another approach.

[grogenaut]

No I'm literally talking about taking the row key and using it as the lookup from kms for the crypto key. Then you take the plaintext, the crypto key, encrypt the plain text and store it whereever. It's 1 additional aws api call over storing the stuff unencrypted, and about 5 lines of code in java that can be turned into a 1 line library call. Not sure why you need credstash.

[acejam]

+1 Upvote for credstash

[jrowley]

I'm curious of cases for when people are running into size limitations for storing secrets... what type of secrets are > 4kb? I could imagine some example but I'm wondering about real world examples...

[grogenaut]

Every file or message you want to send encrypted through AWS or store permanently in S3. I often use crypto as signing as well, since it mostly comes for free code wise at my job.

[ComputerGuru]

You totally can store sensitive passwords in your source code repo, just so long as they're encrypted. Here's how we do it: https://neosmart.net/blog/2017/securestore-a-net-secrets-man...

SecureStore is designed to be repo-friendly, it purposely avoids needless IV/payload regeneration, is based in plain text, and preserves element order to avoid driving source code managers crazy.