12 ms·

the solution is to store the password and any other sensitive information in a text file that you read when your program starts up. And don't forget to add that

• shimo5037 10y ago
  It can be slightly more complex than that if you use a package manager to publish your work. I once accidentally leaked a password due to having both a .gitignore and an .npmignore, and forgetting to include my .env file in the latter. Fortunately, I realized what had happened almost immediately and was able to change the password. Now I tend to `tar tf` everything before publishing.
  • gkya 10y ago
    I believe that it's better to not have that kind of sensitive files be dotfiles.
  • matt_kantor 10y ago
    Because of issues like this I tend to set up my deploy scripts to first `git clone` into a temporary directory, then do the rest of the work from there.
• lloydde 10y ago
  Or environmental variables loaded at provisioning though this just moves the target. But these options do not themselves have the "in motion" characteristics that provide the best reliability, scalability and security. If your needs are more sophisticated this means keyservers where hardware security module (HSM) might by part of the equation.
• the_af 10y ago
  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 10y ago
    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.
    • grogenaut 10y ago
      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 10y ago
        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.
        • acejam 10y ago
          +1 Upvote for credstash
        • grogenaut 10y ago
          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.
      • 10y ago
• okreallywtf 10y ago
  I think its as important to make it "hard to do the wrong thing" as "easy to do the right thing". In this case having to explicitly exclude a file containing passwords from being deployed would fail that rule of thumb. The Azure Key Vault is a good solution that so far seems easy to work with (I've only just started using it though) and it can make the storage of secrets easier to secure but you still have the issue of storing the credentials to the key vault, so its difficult to fully get rid of the problem although you can definitely isolate access to your passwords that way and then have a more limited number of credentials to secure.
  • corndoge 10y ago
    Somehow I doubt Azure Key Vault is easier than a gitignore line and a text file
    • bluebeard 10y ago
      .gitignore is easy but the pw is still naked. Probably a good practice to hash it.
      • slrz 10y ago
        Probably not as the result would be useless for authenticating against another service.
    • RussianCow 10y ago
      Probably not, but it's a lot easier to accidentally commit (or otherwise expose) a text file.
    • okreallywtf 10y ago
      Its not easier for sure, but it is more reliable and harder to mess up by making a single character mistake.
  • ekingr 10y ago
    As you say, the Azure Key Vault helps making things more secure (by allowing to control, log and revoke keys usage), but it does not help at all with the problem of API keys in the source code - it's just another set of keys that you need in your config.
• ComputerGuru 10y ago
  Shamless plug: SecureStore, our .NET secrets manager: https://neosmart.net/blog/2017/securestore-a-net-secrets-manager/ https://neosmart.net/blog/2017/securestore-a-net-secrets-man... I'm drafting a writeup and will post it to HN when that's ready. Other secrets managers I've seen posted to HN seem far too overcomplicated, at least for our company's needs. This is a step up from reading secrets from a plain text file, but not so complicated that you need a separate docker image running a service dealing out passwords to your webapps or similar. EDIT: rationale for use, as requested: Using this approach, you can better manage your secrets since you can actually commit the passwords file in your code base, and the API lends itself to easily switching between dev and production ids/secrets. You can track revisions to the secrets file, rolling back your commits rolls back the secrets as well. You can also include the deployment of secrets in your deployment script - typically, the encryption key for your vault is only generated and distributed to the production servers once, while secrets may be added, changed, and removed continuously during the development and product lifecycles. Using a simple secrets manager like NeoSmart's SecureStore lets you embrace the benefits of deployment automation, revision control, and more, without sacrificing safety and security in the name of productivity or ease-of-use. EDIT2: what the heck, just took 10 minutes off to write it up and publish it: https://news.ycombinator.com/item?id=13654005 https://news.ycombinator.com/item?id=13654005
  • javajosh 10y ago
    I think you need to add a sentence giving one good reason to use anything other than a plain text file.
    • ComputerGuru 10y ago
      Thanks, good idea. I just did, though I may have gone overboard as it is more of a paragraph than a sentence. We developed SecureStore out of necessity, believe me, KISS all the way.
      • javajosh 10y ago
        The fundamental trade-off for any new tool is that devs have finite capacity to learn new tools. That's why we like to learn a few tools really well and then reuse the heck out of them. However, we are open to warning-stories - that if you do it the naive way, at some point you'll get bitten by X, Y and Z. And even then we might not acre until we actually get bitten!
• spurgu 10y ago
  Agreed that is good practice. Oftentimes though when you're prototyping something you aren't really thinking that much about the structure of the project, and then you end up accidentally committing passwords. But yeah, would be a good practice to have this deeply ingrained and just do it automatically for every similar situation.