I have a react-native app that communicates with a server that makes calls to stripe for payment processing/customer creation. I want to ensure that requests are coming only from my app. so i figured i could create a token of sorts on the client, and encrypt it with a special key using b-crypt, then on the server side when the request comes in with the encrypted token as a parameter, i can decrypt that token with the same special key.
i understand the optimal place to store this key is in the env variables server-side, but how do you manage security of a secret key client-side in a react-native app?
There are several ways to store keys on the client side.
The easiest way is to use the Async storage which stores data in a key value pair.
The problem with Async storage is that its nor encrypted so it wont suit your requirement.
The other option is to use the react-native-keychain library which stores the passwords or keys in the securely in the keychain of IOS and keystore in Android. The security part will be managed by the operating system. So this is an approach that can be recommended for your requirement.
There are multiple ways to do this, these are just two options.
After further research, I ended up revoking the accepted status of #GuruparanGiritharan. his solution (react-native-keychain) dealt with storing passwords in an OS's keychain implementation. this ended up not being the solution for my question. as my question deals with storing secrets keys in a way they wouldn't be visible in binary, de-compiling situation.
What I did was research key management services. I found this:
Handling secrets with dotenv
In Node.js secrets are usually loaded from env files using the dotenv
module. This is done in order to separate the secrets from source
code. For example an env file might look like this (reference below):
DB_HOST=localhost
DB_USER=root
DB_PASS=s1mpl3
Now doing this in a context (potentially development) where you dont need to implement continuous integration, it's referred to a "manual provisioning"
My issue (admittedly, I did not specify a production environment in my question) is when it comes to a production environment, in my case, with visual studio app center (a CI option for React-Native apps)
Continuing on this site for an option for key management services:
While this removes hardcoded secrets from source code, it doesn’t
solve your problem completely; Now you need to find a way to provision
your app with the .env file.
This guide will show how you can remove the secrets from the .env file
altogether, so that it can be safely checked into source control and
shipped with your application.
This guide is discussing how to implement key management in the context of a production environment with continuous integration. This approach is relatively simple and straightforward, as all you need to do is create an .env file, add the keys with a variable, and add (in this tool's case) an additional run script to your main node.js start script.
Tool mentioned: SecretHub
https://secrethub.io/docs/guides/nodejs/
Related
I have a program which looks for a config.json file where it reads needed sensitive infos like DB creds, different APIs creds, etc. I don't upload the config file to the git repository because I understand it's a bad approach, although it's a private repository. Now I'm starting to fear the case that I by accident delete this file, or due to a failure in my machine, I could permanently lose it. My question is - what is the best approach I could use to have a constant secured backup for this file, considering that it may contain very sensitive informations?
Also I would like to specify that this config file is frequently changed (and may increase in size...).
Select, implement, and test a backup system that meets your requirements for securing sensitive data. Access controls to the backup system, encrypting backup media, and logging jobs run are fundamental features to manage data.
Storing secrets in version control like git is tempting. But beware, a git repo may be cloned to many places, and every copy contains your credentials forever. Deleting them permanently requires rewriting history. Possibly easier to change any creds that got committed, leave the old ones in history, and don't commit secrets in the future.
Think about how you want to manage secrets. Secrets management software exists that wraps creds and keys in strong authentication and encryption. Building the application server could involve installing the application, and retrieving the API creds via the secret server. It may suit your needs to have different systems to store automation scripts, secrets, and backups.
I read the documentation on Vue CLI and I wanted to make sure if I understand it correctly.
The documentation says,
Note that only NODE_ENV, BASE_URL, and variables that start with VUE_APP_ will be statically embedded into the client bundle with webpack.DefinePlugin. It is to avoid accidentally exposing a private key on the machine that could have the same name.
So does that mean I should store my private key without the prefix VUE_APP? For example,
VUE_APP_NOT_SECRET_KEY=not_secret_key
SECRET_KEY=secret_key
Is it correct way to store my secret key?
You can store your key either in VUE_APP_NOT_SECRET_KEY=not_secret_key or SECRET_KEY=secret_key, there is no difference from security point of view, any one with a minimal front end skill get read this values from the browser.
The only difference is that if you use the VUE_APP_* prefix your variable will be in the process.env, and will be replaced by Vue in compile time using the DefinePluing.
cli.vuejs.org/guide/mode-and-env.html#environment-variables –
NOTE WELL: Anything you store in the Vue app is not secret.
You can create a .env file in the root of the project, next to package.json
In that file, you can create your environment variables as
VUE_APP_SOME_KEY="someValue"
Make sure the name starts with VUE_APP_
Then where ever you want to use it you can do
process.env.VUE_APP_SOME_KEY
Also don't forget to add .env file to .gitignore
Keys should not be stored in environment variables as they will be accessible on the client
You should be using a product like Key Vault from Microsoft. Key Vault is part of Azure services.
Best practice in the industry is to store your secrets on another server.
Microsoft provides such a way through key vault and can be easily implemented.
There are other products out there. See the azure keyvault competitor's list
Edit : I also forgot to mention, you cannot at this time use KeyVault per example directly on frontend app (single page app). You need to split the backend and frontend for it to work, otherwise you will not be able to hit the keyvault client.
ASP.NET Core has a great feature to store user settings securely.
It works great on OSX (and Linux, Windows), stores data in JSON:
~/.microsoft/usersecrets/<userSecretsId>/secrets.json
Is it working in the cloud (Cloud Foundry) too? If yes, then were are the values stored?
Secrets exists for safe storage during development by helping prevent sensitive data from being storing in code / checked into source control.
The Secret Manager tool does not encrypt the stored secrets and should not be treated as a trusted store. It is for development purposes only. The keys and values are stored in a JSON configuration file in the user profile directory.
In Cloud you can directly use Environment Variables for that.
I am using database connector component, with vault component to store the database credentials. Now as per the documentation of both components i have created different properties file for each environment to store the encrypted credentials for diff env.
Following is the structure of my mule project
Now the problem with this structure is that i have to build new deployable zip file whenever i have to update the database credentials for any environment.
I need a solution where i can keep all credentials encrypted and centralized and i don't have to create a build every time after updated the credentials, We can afford to restart the server, but building new zip and deploying is really cumbersome.
Second problem we have this approach is a developer needs to know the production db to update it in properties file, this is also a security issue.
Please suggest alternate approach for credentials management for mule projects.
I'm going to recommend you do NOT try to change the secure solution provided to you by MuleSoft. To alleviate the need for packaging and deployment, you would have to extract the properties files outside of the deployment and this would be a huge risk. Regardless of where you store the property files within the deployment if you change the files, you have to package and re-deploy. I see the only solution to your problem as moving the files outside of the deployment and securely storing them. Mule has provided a solution while it may be cumbersome, they are securing these files first with encryption and secondly within the server container. You can move out the property files but you have to provide a custom implementation and you will be assuming great risk to your protected resources.
Set a VM arguement e.g. environment.type=local for local machine on your anypoint studio.
Read this variable in wherever you are reading your properties file in a way that environment type is read dynamically such as below.
" location="classpath:properties/sample-app-${environment.type}.properties" doc:name="Secure Property Placeholder"/>
In order to set the environment type on your production server(or wherever you are using mule runtime), open \conf\wrapper.conf and add the arguement wrapper.java.additional.=-Dserver.type=production. If you already have any property in this file, you may need to set the value of n appropriately. For example 13 or 14.
This way you don't need to generate different deployment artefacts for different environment because correct properties file is picked by using environment specific VM arguement.
So, a common practice these days is to put connection strings & passwords as environment variables to avoid their being placed into a file. This is all fine and dandy, but I'm not sure how to make this work when trying to set up a continuous deployment workflow with some configuration management tool such as Salt/Ansible or Chef/Puppet.
Specifically, I have the following questions in environments using the above mentioned configuration management tools:
Where do you store connection strings/passwords/keys separate from codebases?
Do you keep those items in a code-repo of some type (git, etc.)?
Do you use some structure built-in to your tool?
How do you keep those same items secure?
Do you track changes/back-up these items, and if so, how?
In Chef you can
store passwords or API tokens in either encrypted data bags or using chef-vault. They are then decrypted while chef does the provisioning (with encrypted data bags using a shared secret, with chef-vault using the existing PKI of Chef client).
set environment variables when calling external software using the environment parameter of e.g. the execute resource.
not sure, what to write here -- I'd say you don't really manage them. This way you set the variables only for the command that needs it, not e.g. for the whole chef run.
With puppet, the preferred way is probably to store the secrets in Hiera files, which are just plain YAML files. That means that all secrets are stored on the master, separate from the manifest files.
truecrypt virtual encrypted disks are cross-platform and independent of tooling. Mount it read-write to change the secrets in the files it contains, unmount it and then commit/push the encrypted disk image into version control. Mount read-only for automation.
ansible-vault can be used to encrypt sensitive data files. A CI server like Jenkins however is not the safest place to store access credentials. If you add Hashicorp Vault and Ansible Tower/AWX, then you can provide a secure solution for several teams.