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.
Related
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.
When store owner installs my app I save access tokens into database for later use. Having access tokens from store is huge security responsibility because anybody with these tokens can modify stores from any domain/address, there is no ip or domain lock.
What method could I use to make this more secure? I was thinking to save tokens offline and then upload it only when needed (in case I need to make some global updates for all stores), then delete it again. In case when merchant access app configuration within admin, I would just save it into session. Is there any better method?
Good question.
I save them in a database as well but I encode them with a separate key from the Shopify App password. That way even if someone have access to the database because of some backdoor entrance he won't be able to use them. That said if someone have access to the code he will be able to figure out how to decrypt it since he will have access to the key.
That said I make sure that each and every request is authenticated before I show any response from the server. Since I'm using NodeJS as the back-end I make sure that there are no global variables that can be accessed or modified from different stores. Everything is neatly scoped in separated functions so that the session is scoped for the current store and no other ones will be able to dirty the other store session.
In addition I make sure that there is a webhook that fires when the client uninstall his app in order to clear my database from any information regrading his store.
I know some people are using sessions for this ( online method ) but they pose other problems that I didn't like so I stuck with a database ( offline ) since that is the quicker way to access the App instead of multiply redirects in order to save the session.
As for proposals I can give you a few tips that I learn on my way while building a few basic Apps. ( I'm not an expert on the subject by any means )
don't rely on any cookies when it comes to sensible information
authenticate every request that comes from the front-end
don't trust the user and validate any input that comes from the front-end
don't over-complicate your setup, while it's good to have high security it's bad if it makes your app slow for the user and you lose customers
look to other ready to use popular solutions that can guide you to the correct path
don't get greedy with the App scopes, only request the scopes that you need for you app
remember to clean up after yourself when it's possible but don't over do it ( too many Apps modify the code of customers and break it only to prevent any way to clean it afterwards ) Example use the ScriptTag API instead of a liquid snippet using the Asset API. If you have to use the Asset API add only the parts that you know that won't break a site. Creating a variable is ok if you are using var if the site supports IE11 creating a variable using const or let is not OK or using vanilla JS is OK but using jQuery without knowing for sure that the site has it installed globally is not OK.
More insights on the matter can be seen here:
https://help.shopify.com/en/api/getting-started/authentication/oauth/api-access-modes
https://community.shopify.com/c/Shopify-APIs-SDKs/Best-way-to-store-shops-that-have-installed-my-app-and-their/m-p/402972
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
Let's say I have a program written in VB.Net with encryption code that relies on a key being set to encrypt and decrypt. How do I securely store the key in the program? If it's plain text in the code, it could be reverse engineered. If it's a setting, then it is stored as plain text in the x.exe.config file and even easier to find.
Can the x.exe.config file be set to encypt? If not, what's the safest way of hard coding the key into the program?
The method I've used is encrypted using a different method, then encode that (as it's non-ascii text) and store that in the settings, but that in turn could be decoded if the program is reverse engineered.
What do other people do in this situation?
You've set to an impossible task. The problem is that by hardcoding the key into the program, as you've noted, the user can still get the key by reverse engineering. If you put it in a file somewhere, the program needs to be able to read it, and therefore the user can also access it in the same way.
The fundamental problem you have is that the software needs to access the key, and for that, the key must be stored somewhere it's reachable by the user too. It can be within the binary or in the computer, but the binary can be analyzed and the file system can be inspected. Encrypting a file protects the key, but just recreates the problem with the new key.
This is also the very same problem that all DRM schemes face. They give users access to the the full software but want to limit it in some ways, but the user has everything in his computer to run the software. That's why it's always possible to pirate every desktop software, if enough effort is put towards it. You only can make it more difficult by obfuscating the key.
But what can you do then?
An alternative approach is to not have the user to have the DB credentials at all. Or make them useless for anything significant. I can think of two approaches here:
Have the system communicate with a webservice and never to the DB directly. This way, the user only knows the address of the server and the WS can request any authentication as needed, before going to the DB. The WS is then the only one to ever touch the DB. This is what all websites do in practice, the visitor doesn't ever sees the DB, but interacts with it though the web server.
Another option would be to give the user direct DB access, but those credentials only give permission to call some stored procedures (or access views without sensitive data) and those in turn request some sort of authentication before proceeding. This way the DB credential becomes not that sensitive as long as its permissions are kept to the bare minimum and privileged actions are properly validated before proceeding.
How can I store a configuration property such that its value can't be read anytime with bees config:list? We use a master password as a System property (although we are open to other options there) that allows us to decrypt other passwords. However, we realized that any user with CB SDK access can easily list that value. What are our options here to store it encrypted or other ideas for a solution?
Unfortunately, no encryption option available yet, unless you were to bake it yourself in a ClickStack, for example.
Still, this would be an interesting feature, and I will talk about this possibility with my colleagues.