111–120 of 214 posts
Earlier quoted context omitted.
Environment variables are the best and easiest way that I know of. You can supply those anyway you want to, and any programming language can easily get their values.
I'm surprised this isn't higher up. Are there any arguments against ENV variables in favor of something else?
Earlier quoted context omitted.
Wrong lesson. Don't put secret keys in your repository. Someone getting a copy of your code should be a big annoyance at worst.
Where is the right place to store db passwords, api keys, etc? What is best practice in this area?
Imagine you implement every type of possible security... Keeping your entire server-stack up-to-date, making sure you have SSL, using strong encryption for logging-in, hashing the passwords, making sure your server can only be reached via SSH, adding firewalls, filters, etc. etc. Then some hacker in Eastern Europe comes along (or some beginner at the NSA/GCHQ) and finds out that your .git is exposed and somehow gains…
Wrong lesson. Don't put secret keys in your repository. Someone getting a copy of your code should be a big annoyance at worst.
The right lesson is: Know where your secret keys are and take the appropriate steps to secure them. Whether that's in the codebase, a properties/ini/conf/whatever file, environment variables, whatever - know where they are and make sure you understand possible threats against them.
This story could just as easily have been written about how easy it is to download ALL_THE_SECRETS.txt. Don't feel smugly secure just because you don't store passwords in git.
So far a few people have requested my .git/ directory but none have attempted to plunder the riches they think they'll find within.
Earlier quoted context omitted.
Environment variables are the best and easiest way that I know of. You can supply those anyway you want to, and any programming language can easily get their values.
I'm surprised this isn't higher up. Are there any arguments against ENV variables in favor of something else?
DB_USER=scott DB_PASSWORD=b3withm3pl3aze /usr/bin/python webapp.py
That could be troublesome if an attacker figured out a way to run remote commands on your server even as an unprivileged user.
Earlier quoted context omitted.
FWIW I have a /private directory in the root of all vhosts, so it looks like: /srv/www/domain.com/public_html/ |--------->/private/ |--------->/logs/ |--------->/tmp/ Anything stored in /private/ is not publicly accessible by the web server process, but can be read or written by anything running under the user's username. It's specifically for storing things like configuration files. I think this should be standard p…
Why do you store such stuff under /public_html anyway? One level higher would be more appropriate I think.
Imagine you implement every type of possible security... Keeping your entire server-stack up-to-date, making sure you have SSL, using strong encryption for logging-in, hashing the passwords, making sure your server can only be reached via SSH, adding firewalls, filters, etc. etc. Then some hacker in Eastern Europe comes along (or some beginner at the NSA/GCHQ) and finds out that your .git is exposed and somehow gains…
You only need to make a single mistake and you are hosed. Your attacker can fail an arbitrary number of times and only needs to succeed once.
If you are 99.9% likely to make the right call on anything that could have a security impact then you only need to make 1000 decisions before you probably screwed one up and have a hole.
Some would say this means true security is impossible.
Earlier quoted context omitted.
Hiding the repo is hardly a bandaid. It should never be exposed even if the repo is perfectly secret-free. Except in the rare cases where it is intentional e.g. an open source repo and you happen to want people to download it from the same domain not github or git.domain.com.
Can you elaborate on why it shouldn't be exposed? Presumably, for most commercial entities, the parts of the site that are valuable are the assets, which are served from the site as part of it doing the thing it's meant for. For a large percentage, they're running a CMS like Wordpress or Drupal or whatever, where the codebase is public anyways. And for even more, we're talking about a directory of hand-crafted HTML f…
Because for a non-trivial number of websites their codebase is their IP and product and not something they want to be public.
I'm all for open sourcing as much as possible, but Google doesn't publish their search algorithms for a reason.
If you're using a modern framework with url routing, you don't need to worry about hiding .git or .hg in your webserver config file.
Earlier quoted context omitted.
Where is the right place to store db passwords, api keys, etc? What is best practice in this area?
Environment variables are the best and easiest way that I know of. You can supply those anyway you want to, and any programming language can easily get their values.