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.
Related
I'm new to vue .env. I looked everywhere for a straight answer till I got lost. According to VueJS documentation that if we have .env.local file that will be loaded in all cases but will be ignored by git which exactly what we want to hide secret API keys from the public. But it also says that if we add VUE_APP before the key name in .env.local that will make our key load to the public.
My question is. How to securely hide API key from the public and still be able to use it in production and in development without any security risks?
my .env.local file
VUE_APP_DEEPGRAM_KEY=some_API_key_that_is_secret
the above works if I log it to the console from my app. but if i removed VUE_APP It won't work so is it safe to leave it like this?
Anothe thing, in Laravel we used to save API keys in .env and refer to them from config file and then call them in app from config. So is Vue different? if not, then how to do the same here?
To answer my own question, documentation is actually pretty obvious but I got a bit confused. it simply has to start with VUE_APP_ for it to work in Vue CLI
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/
I've got an Appveyor project setup and working awesomely. Now, I want to upload artifacts S3 for easy hosting. This seems fairly easy as outlined in the documentation. My question is, where do I put the secret with write permission? I don't want to push it to my public repo for obvious reasons. On travis I could put it in an environment variable that was never logged. How would I go about this in Appveyor?
I assume you need to store this in YAML. You can use secure variables. Or you can simple put your secrets in clear text to S3 deployment configuration in UI, then save and press Export YAML and you will have YAML section with secrets encrypted.
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.