people say to put pwds in envariables instead of config files
can a hacker access env vars through a trojan?
if I put my pwds in a .php file, it will be interpreted and nothing goes to client
the file sys security is old and tested so I trust .php
but what about env vars?
Environment variables are even older, and more tested than PHP.
Putting passwords in PHP is a terrible idea because you probably have multiple copies of your PHP files around (e.g. in source control, or in backups etc) which become alternate attack vectors.
Putting a password in the environment is preferable, because it's a different kind of system that the attacker has to penetrate first.
Even better yet, would be to put your passwords in a config file that is read by your PHP application, but exists in a vault or configuration repository that is only accessible to your operations team (who presumably has a need-to-know).
Of course, this is all moot if you don't have a strong secrutiy posture on your server or development environments.
That depends on the security of the cloud service provider you are using (AWS, GCP, etc), most of whom are pretty secure. If you are talking about local development server, and pushing your code to an github, just make sure to add .env to your .gitignore, and you should be good.
Related
I need to use encryption on private/personal user data. I am going to use the following encryption library.
RbNaCL
I need a way to store the KEY outside of version control so I can run the app locally. When pushing the code to our hosting company I can put the KEY in the server env variables. Just not sure how and the best way to do it locally.
I should note that all developers working on the project use the same database so we all need the same KEY for development and staging environment.
https://www.happybearsoftware.com/how-to-actually-do-a-cryptography-in-ruby
I think what you are asking is how to keep a .env out of version control while in the repository, people collaborating should know about the what are the enviroment variables. Normally .env-sample (which is a dumy in which all variables are kept without values) is tracked and while .env is ignored (by adding it in .gitignore in case of git)
Typically, secrets never get committed to repositories. Just put them in a config file (like config.yaml or secrets.xml or env.sh or similar); copy the file (to something like config.yaml.example or secrets-skel.xml or env.sh.sample); put the first one into .gitignore (or equivalent, if you're a non-Git heretic), and replace all the secrets in the second one with placeholders. Commit the second one so that everyone who checks out the project will know the format that they should have; but the secret one never touches the repository. If you need to share keys between developers, do it in another way (from IRC/Slack/Email to encrypted USB storage device, depending on how confidential the stuff is).
If you go with YAML-ish kind of solution, in code you can try to find the file, if it is absent then use environment, or vice versa - look up environment, if no variable is there look for the config file to read from (and possibly even stuff it into ENV so you don't need another config object; you might do it in config/application.rb kind of thing. If you go with env.sh kind of approach, you can declare environment variables directly; when you need to start developing, you can source env.sh (or shorter . env.sh) to set them up.
I should note that all developers working on the project use the same database so we all need the same KEY for development and staging environment.
Store the key, and any other shared secrets, in a secure shared vault. Many password managers provide shared vaults, such as 1Password or LastPass.
Then each developer can copy the key from the shared vault and set it in their development environment.
Let's say I want to store URL and token for accessing API to configuration file. I have 3 environment, those are development, staging and production. They have different configuration value for each environment. I am using source control too. For sure, I don't want to share production environment configuration file to source control. So is there a best practice to manage this problem ?
Best thing you can do is Ignore that file in svn when committing. It will never be committed to repository.
How do I ignore files in Subversion?
A configuration file (.yml) is being used for a rest api developed with Dropwizard (0.9.2 - latest release). Most of the credentials needed by the api such as database password secret key etc., are stored in the configuration file.
We have implemented most of the things based on the items mentioned in the reference found at dropwizard configuration reference .
The question is clear. How secure is it (storing these information in a configuration file as plain text.)? If not, what is the proper way of doing this?
Yes, it's not secure indeed. Even worse if the configuration file is committed to a public repository or for that matter any repository (version control). One way which I follow is to maintain a local copy (not to be committed to any repository) of the config (.yml) file which has all the sensitive keys & details etc and maintain another example config file which has the sensitive details masked (some dummy strings instead of actual values). This example config can be committed to your repository as it has sensitive details masked.
For all purposes of running your code locally or elsewhere use the local config file. This way you don't risk it to exposing sensitive data on a repository. There is an overhead though in keeping your example config in sync with your local copy whenever you make any modifications.
I just looked for the solution for the similar issue. I want to find an solution to not include the keystore password in the config file. Finally I got an solution for it.
Just stored credential keys in the config file. And then use a substitutor to replace the keys with it's related values. But this need a secure key value services to get the values of the keys.
Overriding server connector config with env variables with dropwizard
How do you deal with host-specific configuration for docker containers?
Most importantly production passwords. They can't be put to container for security reasons. Also, they need to be changed on regular basis w/o redeploying anything.
I mostly use Volume containers if I really want to avoid making an image for that: http://docs.docker.com/userguide/dockervolumes/
however, I have done things like
FROM myapp
ADD password.file /etc
RUN do some cfg
to make specific images with password baked in.
That way the specific configuration list passwords is not in the general images which are re-used and known, but they are in an image that is build for and on the host that is running it. (this approach is not really very different to using puppet/chef etc to customise the files on a vm/server - it eventually needs to hit the filesystem in a safe, but repeatable way)
As one comment says, use environment variables you can pass via -e pass=abcdef. You can also save them in a fig.yml config file to avoid having to type them every time.
I would like to backup my rails app usig a private git repo. I've decided to use Dropbox but I've already deployed to heroku, setup DNS for a custom domain name without backing up and would hate for something to go wrong by transferring my project.
Does anyone have experience with this or knows if something will go wrong? Should I reconfigure any files before transferring to a private dropbox folder?
Heroku's addons (i.e. custom domain) configurations are located on their server, not on your computer. Typically configs appear in ENV variables. Type heroku config to see what you have.
So yes, you are free to copy your code anywhere you like, and be sure to copy your dotfiles as well.
Personally, I use github for my code backups.
bitbucket now has private git repos. Unfuddle had them for a while too. These are all free, BTW.
In short - don't reconfigure or setup anything - have fun of some coding instead :)
If you just want your repo to stay safely in the "cloud" then:
Bundle (for git or mercurial)
Gmail the bundle to yourself as a reply to the same "pull" message". Or, in case you have a fellow coder, then gmail to him/her. Double-backup.
Done and forgotten. There is plenty of room in you gmail inbox and sent-items for the source-code of several projects.
IMHO it is:
fast
platform-neutral
shareable via smart-phone within 5 minutes maximum
pull/push/work anywhere
secure
easy
a natural habit