We have code (in git) together with configuration/deployment/build scripts (fabfile.py, circle.yml, Dockerfile etc) which result in a pretty seamless automatic build/deploy process. The one part which is not seamless is where to store credentials of various kinds. These are things like ssh keys, code signing certificates, aws access keys, ssl certificates... Currently the process is to copy the needed keys/certs from a flash drive and then (eg) run fabric.
It seems like storing credentials like this in git (alongside code) is not the best place, but what is the best place? Is there a recommended best practice for where to store information like this for devops? Is there a reference that discusses different options with their pros and cons?
The problem of secrets management is still something that hasn't exactly been "solved" by the use of any tool.
You can use any of the various Secrets Management Tools (each offers different types of benefits / integrations).
I personally prefer Hashicorp Vault. Cyberark is another good one.
The way you use these tools in your solution however, there are some common use patterns.
1) You can store your secrets in code in your SCM IF they are encrypted... But this still results in the same problem, you still need to deliver a secret securely at deploy time (or have it available at startup) to be able to decrypt the secrets (password, credentials, secrets, certs) that have been deployed. That is where the Secrets Management Tool (such a Vault) comes in. The tool will allow you to securely retrieve your secret for use in decryption of the secrets when it's needed.
2) The other way as mentioned above is. Is to actually store all secrets, certs etc. outside of the SCM in the Secret Management Tool itself and retrieve them at deploy / startup time.
Obviously there are pros and cons to doing things either way. i.e. the first approach reduces complexity as you only manage one or two secrets at any given time. On the other hand, if you store all secrets in a vault, the potential for compromises associated with your entire ecosystem is reduced, as access to a single secret doesn't allow someone access to every other secret.
At the end of the day it all comes down to your use case / the security constructs available and of course the people you are surrounded with. Because at the end of the day, someone, somewhere needs to know a secret...
Yes. There is a recommendation. It is the usage of Cloud Vault. Take a look on some good examples:
https://www.hashicorp.com/blog/vault.html
https://blog.keepersecurity.com/2016/08/16/keeper-for-devops-more-than-just-passwords/
It's a kind of best practice to use a proper Security when it comes to credentials. As it can lead to Web Hack and other potential loss to the company.
Best way to do it to use Kind of Vault.
https://www.vaultproject.io/
https://docs.ansible.com/ansible/2.4/vault.html
AWS KMS
Related
I want to know what is the best secure way to share and use Service Account key on python .
I share the service account key "JSON File" by email and this not a secured way In addition users use the key in their code which is something not recommenced by security
while your question doesn't exactly point out your use case, generally, the google cloud secrets is where most secrets can be stored and retrieved.
If you go through this codelabs
https://codelabs.developers.google.com/codelabs/secret-manager-python#0
this will provide you with approach to using the secrets manager and accessing it in python code.
This is one of preferred approaches in python, however to answer if its is best secure way is based on different use cases - see best practices here
https://cloud.google.com/iam/docs/best-practices-service-accounts
I know API keys need to be stored securely and should not be accessible client side. That being said, I also know that a lot of Wordpress plugins/ custom sites/ and such allow users to copy paste the API key into a text input on the admin panel.
My question is how do you do this securely? Do they hash it and save it to their database?
Say for example I made a react app or wordpress plugin that allowed users to do something with the Google Maps API. I know I can go get their API key and just hard code it in... but if I wanted to let the user update the key on their own - What would be the reccomended steps?
Thanks!
If I understand you correctly, you want your application to process secrets of third party APIs. A bit scary, but if you get the user consent - why not? First thing first - make sure the user understands what he is doing. Point out exactly what you will do with the API keys, what you will not do with the API keys and how will they be protected.
Personally I would never want to store such secrets in my own database, as this would be a single point of failure. When you are hacked, everyone is hacked. Why not put such secrets in - say - local storage so it never touches one of your servers?
Ok, in case it is your server that needs to do something, you could get the API key passed in a request, do something, but never log or persistently store the secret anywhere.
In case it is enough for the Java Script to do the job, local storage is even better solution.
One could think about encrypting the keys in the local storage, but I don't believe this would improve security a lot. I mean this would be security through obscurity and could by bypassed by someone with physical access to the machine/browser/user agent. But if someone would have such access, then probably some of the API keys would be one of the smaller problems.
I have a webapp that uses keys and credentials to call API endpoints from external services like payment gateways, database providers, and such.
I have these options in mind to keep these values:
Set environmental variables before app start and load them when the app runs. If required values are not available, e.g. not set, exit the app.
On app start, ask user (myself or an administrator) to enter the credentials. If required fields are empty, exit, otherwise continue loading the app.
Keep them in a config file as plain values. This is the least preferable way as to me.
Which of these should I use if I want to keep keys as safe and secure as possible?
I would go with user environment variables, as it is recommended by both google and amazon.
If you go for storing in plain text files, remember to not keep them in your app's source tree (if you use some version control, you may end up exposing them to public).
Also, remember to regenerate your keys periodically.
I think you should, as you said, use configuration files. And maybe encrypt it ?
If you have lots of keys to manage, environment variables get clumsy. A hybrid approach works for me: encrypt the secrets and put them all in config (typically as base64). Use the same encryption key for all of them, and pass it in as an environment variable.
So you only need to make one environment variable to secure as many other secrets as you need.
I am working on a project where two parties can each make API requests to each other and are authenticating using a shared secret. The other party wants the shared secret to be the same both ways, but I don't understand how that would work. So I'm either looking for an explanation of how to do this securely, or to find out if this is not something that is possible and that the shared secrets should be different based on the direction of the request.
If the API request were just going in one direction, I would salt the password using a key defined function, and store the hash and salt, then I can authenticate the user by generating and matching the hash on each request. But if I need to use that same shared secret to make requests to the other API, then it seems like I would need to store the password in a way that it can be decrypted, which seems wrong/not possible.
Is there a way of doing this, or should the shared secret be different depending on which direction the request is going?
Your analysis is correct. If both side can be the caller, then both sides need to know the secret (not just be able to verify it).
Having two separate keys (one for each caller, you might as well call them "passwords" in this use case) seems to be a reasonable default setup.
It is always good to think of "parties" and give each their own credentials, especially if more parties will be involved later. Makes it much easier to revoke individual access rights later on, to enforce fine-grained access control, and minimizes the impact of leaked credentials (an attacker can only impersonate that one party, not anyone else in the system).
Having just one may appear slightly easier to manage, but then you become responsible for not leaking the other guy's key (in addition to your own). I would try to avoid that extra burden.
I have to start a new project where user authentication/management will be required.
A lot of websites use existing authentication mechanisms like facebook/twitter/openID/google/etc (even SO).
While I might understand that they are used to simplify some parts of this workflow can someone enumerate the pluses and minuses of using one of these authentication mechanisms vs. an usual user creation and what should I look for when I do this?
Thanks in advance!
Here are a few:
Advantages of using external auth (like openId)
For the user, fewer account names/passwords to keep track of
For you, don't have to manage password resets etc.
Disadvantages
Ties you to an external service (if google/facebook is down, so are you)
Your site is only as secure as the external site(s) you trust as id providers