9 ms·

Why Deleting Sensitive Information from GitHub Doesn't Save You

313 points by jwcrux 12y ago

tomphoolery 12y ago
It should be noted that GitHub's article on removing sensitive data is still applicable if you haven't pushed anything back to GitHub yet. Remember that a commit is just an entry into your repo, it doesn't synchronize with `origin/master` until you tell it to. So if the user has not pushed to GitHub yet, but has committed in their local Git repo, they should follow GitHub's guide and not worry about changing any keys.
- newman314 12y ago
  link pls?
  - ehPReth 12y ago
    https://help.github.com/articles/remove-sensitive-data/ https://help.github.com/articles/remove-sensitive-data/
- ncallaway 12y ago
  While it's absolutely true that if the credentials haven't been pushed then you are not compromised, I would still encourage people to rotate their credentials regardless. All it takes is a mistake when deleting the sensitive information, or having pushed without realizing it to be compromised. Even if you're absolutely positive there wasn't a breach, it can be a good excuse to drill for a _real_ breach later. It never hurts to walk through the practice of what to do if credentials leak when there's no pressure.
  - Dylan16807 12y ago
    A credential rotation drill does sound useful, but I'm kind of uncomfortable with assuming like that; it seems like sloppy thinking that can cause trouble down the line.
godzillabrennus 12y ago
Millions of emails for developers and no one harvesting this info thought it wise to obfuscate it in some way?
- akerl_ 12y ago
  Obfuscate the emails that are clearly visible on github.com? I think by this point it should be pretty clear that email addresses, like domain names, are not secret information. Obfuscating the data would have mangled useable information for a goal of blocking people who would have had no trouble gathering that information anyways.
- bhuga 12y ago
  Emails are part of commits, which are hashed as part of normal git operations. There's no way to make repositories public and not make emails public.
  - xai3luGi 12y ago
    You could set your author email address to an empty string before committing.
akerl_ 12y ago
To be clear, the guide from GitHub that's linked at the top of this article clearly states that you should consider the sensitive data compromised. Cleaning it out of the repo is a good move, but it's a companion move to rotating out those creds or whatever for new ones.
- fragmede 12y ago
  That guide highlights this in its own box. In red. Not sure how GitHub could make it more obvious. Perhaps if they mentioned there are unscrupulous users out there who have a script that hammers GitHub's events API to search for exposed passwords/keys, then it would reduce the 'oops I only pushed it for a second' thinking that users likely go through.
deleted 12y ago
[deleted]
PhantomGremlin 12y ago
If you ever put anything out on the Internet, not just to GitHub, consider it to be public information. Forever. You might be able to convince archive.org to remove it, but there are hundreds of players out there who aren't as ethical. Ben Franklin figured this out many years ago: Three can keep a secret, if two of them are dead.
baxter001 12y ago
A script to post random key containing config-like files to public repos and waste these guy's bandwidth/light them up on amazon's blacklist radar would be a cool idea.
deleted 12y ago
[deleted]
guiambros 12y ago
> In this post, I’m going to show exactly how hackers instantly harvest information committed to public Github repositories... A few days ago I published my blog to GitHub, with my MailGun API key in the config file (stupid mistake, I know). In less than 12 hours, spammers had harvested the key AND sent a few thousand emails with my account, using my entire monthly limit. Thankfully I was using the free MailGun account, which is limited to only 10,000 emails/month, so there was no material damage. Their tech support was awesome in immediately blocking the account and notifying me, and then quickly helping to unblock the account after keys and passwords were changed, and repo made private. I was exactly wondering how they were able to harvest GitHub content so quickly; it couldn't be web scrapping or a random search. This article explains well how to drink from GitHub's events firehose and the GHTorrent project, so everything makes sense now. Thanks for posting it. EDIT: This other post[1] describes a similar situation. There are some folks monitoring ALL GitHub commits and getting psswords as they are commited, on the fly. [1] http://www.devfactor.net/2014/12/30/2375-amazon-mistake/ http://www.devfactor.net/2014/12/30/2375-amazon-mistake/
- infinitone 12y ago
  I had a similar but less pleasant experience. I had decided to opensource an old side project of mine, that gets a good amount of users daily. And by that, it was just initially to make the repo public. But I had totally forgot about the mail server keys- this was a paid mail server, so you can imagine my disbelief when I get an email of a $1000 bill and a complaint saying that I had sent upwards of 250k emails with what seemed to be a iOS mail app malware email. Luckily it was resolved within a week with support.
  - andyjdavis 12y ago
    I'm curious. Did they excuse the bill or was this a $1000 lesson?
    - infinitone 12y ago
      Yup, it was credited as they checked the IPs of the server that was sending those requests. It was clear that it was malicious, also I had been a long time customer.
xasos 12y ago
Always use environment variables. They are probably the best way to safeguard your API keys.
- TTPrograms 12y ago
  I've always wondered the proper way to deal with this, and this makes total sense. How would you typically set such an environment variable? In bash init?
  - xasos 12y ago
    It depends on language. In node, you can set environment variables in the code with process.env and Python with os.environ and then use those to specify the values on the command line. In fact, even services like Heroku will let you edit these from their web-based client.
    - kbenson 12y ago
      That's really more of an implementation detail though. You'll want a file to specify these environment variables, so you can actually have services start on boot, so that means you need a config file (whether it's used for setting the environ, or read directly by the application is the implementation detail). What's really needed is to correctly separate and secure important configuration options outside of source, and designing for that from the beginning. Using environment variables in a way forces this, which is good, but it doesn't help if there's just a startup script that specifies those variables and it gets accidentally committed to the repo.
  - sesteel 12y ago
    Environment variables can work well for development but I wouldn't put them in .bashrc or .bash_profile; if you are like me, you like to store your dot files somewhere public. I typically leave them in an encrypted file on dev systems, but this only solves the accidental over the shoulder problem. Production systems require another level of security altogether. Typically, I've seen services run in restricted user accounts with limited system access, reading passwords out of an encrypted file. This file is stored in some obscure location on the box to which that user account is the only one with read permissions to. Keep in mind, every system has weaknesses and I am still interested in listening to others' approaches.
xasos 12y ago
It always amazes me to see the sheer amount of API keys left around in GitHub repositories. You can search anything like Twilio API Key and come out with hundreds of thousands of results. I wonder to what extent these keys have been exploited.
deleted 12y ago
[deleted]
- dllthomas 12y ago
  "API keys [...] need to be in your committed code" Why?
- thefreeman 12y ago
  They really don't. You can read them from environment variables (which would be set by your platform eg. heroku) or you could set up a vagrant instance with the necessary services to develop locally.
- Killswitch 12y ago
  > "API keys [...] need to be in your committed code" No they don't.
  - kevinmobrien 12y ago
    >> "API keys [...] need to be in your committed code" > No they don't. A better approach is what the rest of the comments here are suggesting: (1) store your secrets (API keys, certs, credentials, whatever) in a highly-secure system, with both strong encryption and immutable audit logging around their access and modification; (2) expose those secrets at run/compile-time via variables, such that the secret is never stored on-disk anywhere other than in the highly-secure system from (1) and in transient storage while in use; (3) wrap an authz layer around variable access, so that only authorized services/users/hosts (those that have authenticated properly and who are allowed access via the authz policy established here) can read/write/mutate the secrets It's (basically) the "privileged identity management" space; the challenge is that the commercial software in that market hasn't kept up with the combination of automated ops infrastructure and cloud-hosted dev tools. There are some ideas around how to do 1-3 better, with a devops/cloud-native design built in. (Full disclosure: I'm part of the founding team at a company doing this.)
    - devonkim 12y ago
      The PIM software I've seen in enterprise (stuff even older than what Cyber-Ark has) has barely even kept up with software from the early 2000s let alone modern automated operations infrastructure. APIs that are written for XML-RPC and even XDR for crying out loud (that implies that even TCP was a tough sell for them). Automating them has been an exercise in incredible pain for few rewards. Even AWS CloudHSM is not revolutionary conceptually as much as from a compliance and paperwork standpoint. I think there really needs to be emphasis on a (4) - all secrets must be rotated and revokable on-demand and on semi-random schedule. The goal is to make any credential only valid for a period of time less than what an attacker that is already present on your systems would need to further increase presence or to compromise any of 1-4. Who cares if an instance is owned if it's up for maybe 10 minutes and can literally only communicate on a specific port to a specific server with a specific protocol? Unfortunately, this is all only reasonable in a highly automated architecture and is basically impossible with almost every single company I've ever seen that's ever uttered the mere word ITIL because those companies tend to be people-driven cultures for everything, not process-driven (most companies try to add policies that are so ineffectual and meaningless that everyone reverts back to tribalism similar to how everyone defaults to e-mail when collaboration tooling is ineffective) that you have to figure out to be effective in cloud environments. I do devops and security automation as well, and there's nothing self-serving about your points if you ask me.
olefoo 12y ago
There's a fairly straight forward pattern for keeping sensitive credentials out of github. It comes straight from http://12factor.net/config http://12factor.net/config store configuration data in the environment. What I do for most projects is keep the tree containing the working directory in a directory that has some other items that don't belong on github (like the project brief, my emacs bookmarks file, random notes related to the project etc. ) and in that directory there is a .credentials file containing a set of export statements somewhat like: export AWS_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXX export AWS_SECRET_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX export AWS_USER_ID=############ If I'm feeling extra paranoid, I'll encrypt that into a blob that I only decrypt when I'm working on said project. Then at startup the app goes looking for it's config in the environment. This does create issues for some environments ( solving this for docker is trivial ) but you can usually pass environment variables to whatever is executing your code reasonably securely. Now it's not perfect, and environments can sometimes be revealed externally if an attacker is determined and clever and focused on your app for some reason. But it does give you a hygienic procedure that keeps your credentials that are equivalent to an open draw on your bank account out of public repositories.
- califield 12y ago
  I use the `dotenv`[1] package with Node.js and it does exactly the same thing: environment variable definitions that you can store elsewhere in a dead-simple format. To be fair, I think they just copied the `foreman` tool from Heroku. However, it works great. Most projects don't need anything more than a flat hierarchy of secret keys and values. Writing your own parser for a `.env` file is a piece of cake, even in shell language. Adding `etcd` is better, but it's too much work for a small project. [1] https://github.com/motdotla/dotenv https://github.com/motdotla/dotenv
  - kgilpin 12y ago
    12 factor and .env make a lot of sense. However they still leave some questions unanswered, such as: How do the secrets get safely distributed to the machines where they are needed? How to revoke/rotate a secret, especially once a compromise is suspected? How to perform all this in DevOps-y, automated systems? This is the problem space I work in.
nutanc 12y ago
I think this problem is widespread enough and there are enough idiots out there(me included),that there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted.
- mkal_tsr 12y ago
  > there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted. Sure, just enumerate any and all possible types of sensitive data, the format they may be in, regex / matching functions to account for them (supported across 20+ programming languages) and I'm sure Github will have that done asap. Alternatively, don't commit passwords/API-keys/sensitive-info to your repo.
  - lambda 12y ago
    > Alternatively, don't commit passwords/API-keys/sensitive-info to your repo. This is, of course, the right answer. However, it's frustrating that several frameworks make this very easy to get wrong. Anything that has an application.yml, database.yml, or similar configuration file that normally lives within the same directory as the source code, and which is intended to contain credentials, means that lots of people will make that mistake. It's one of the fundamental errors that you see so often in web frameworks like Rails, this whole idea of mixing application code and configuration files into one big tree. I don't know how this practice caught on, but it has, and it so frequently causes mistakes, both big ones like accidentally publishing credentials, and simply frustrating ones like confusing the difference between application code and configuration in ways that make it more difficult to have multiple local configurations and updating the application code independently.
    - deleted 12y ago
      [deleted]
  - jemfinch 12y ago
    > Sure, just enumerate any and all possible types of sensitive data False dichotomy. It doesn't have to be "everything" or "nothing". An 80% solution here is better than nothing. I still find it useful that gmail warns me before I send an email without an attachment if I've written "I've attached" in an email. Can gmail detect with 100% accuracy if I intended to send an attachment? Of course not. But the 80% solution here still does me and lots of other people a lot of good.
femto113 12y ago
My advice: USE PRIVATE REPOS! At $7/month Github's micro plan with 5 repos is just $1.40/repo-month. This is the cheapest insurance you can get against the nearly inevitable mistake of committing something sensitive.
- stinos 12y ago
  Could also have a look at BitBucket instead: unlimited private personal (or teams of max 5) repos at $0/month. Or for $7/month you can host your own at DigitalOcean/Azure/...
- mmahemoff 12y ago
  Sure, use private repos for private projects but this is about open-source authors accidentally leaving their credentials in config files and the like.
  - femto113 12y ago
    Anecdotally this seems to happen mostly from personal experiments, not from development of open source software meant to be consumed by others. Secrets generally are included in projects that are meant to be deployed (like a rails app, or a blog, or ...), not in thelibraries/gems/modules that make up the bulk of open source found on Github.
icymatter 12y ago
Github has very good cache. In the past, when I deleted a repository I still was able to access some diff and commit information from my own activity pages. I had to request Github team to clear that page manually.
deleted 12y ago
[deleted]
DenisM 12y ago
On MacOS theres keychain - it's a designated place for storing secrets. On windows I create a batch file at a fixed location with all the credentials in it. A script simply runs this batch file and reads the env cars to get values. A compiled program parses the batch file with regex to find required values. This works remarkably well for keeping credentials out of the code base. Hope that hels someone.
revelation 12y ago
So many words for one simple principle: if sensitive data has been publicly accessible or transferred in plaintext over the internet, consider it compromised, logged stored and abused. The only recourse is to immediately change or revoke access.
jpdlla 12y ago
Thinking of actually working on a tool for this. Will have a blacklist of "searches" that might contain sensitive data and perhaps notifying via the email of the committer or creating an issue on the repo. Anyone else want to get involved?
jpetersonmn 12y ago
First time I tried to use github I uploaded my gmail password which I was using to send myself an email when something failed. I figured that there would be bots that would scoop up that information right away. Luckily I realized what I had done before people could get into my gmail.
rilita 12y ago
TLDR: It won't save you because people could have copied the information before you deleted it. Duh?
- sheetjs 12y ago
  TL;DR: github makes it easy to notice when events have occured, so easy that you can write tools to copy information as soon as it hits. This is a bit more nuanced than your summary because GH makes it easy. Without the events API, you would have to poll the various repos to find out if changes happened Furthermore, the existence of GHTorrent demonstrates the ease with which this information can be harvested
  - rilita 12y ago
    So what you are saying is that because Github provides a clean API we should be more careful about posting sensitive data to it versus other things where you can simply scrape index pages? I fail to see how the warning is meaningful. One should assume anything you post to the public internet may be public forever. The existence of an API changes nothing as far as the amount of care you should take.
deleted 12y ago
[deleted]
tlrobinson 12y ago
Are there any open source git hooks that will scan your code for known credential formats?
jquast 12y ago
I'm very certain this is a hacker's account configured to follow a great deal of projects and people (2k projects, 1.3k users) for this very purpose -- a suspicious [redacted] [unknown] profile, https://github.com/trnsz https://github.com/trnsz
morkfromork 12y ago
What would happen if you published a few billion fake credentials?

313 points by jwcrux 12y ago

It should be noted that GitHub's article on removing sensitive data is still applicable if you haven't pushed anything back to GitHub yet. Remember that a commit is just an entry into your repo, it doesn't synchronize with `origin/master` until you tell it to. So if the user has not pushed to GitHub yet, but has committed in their local Git repo, they should follow GitHub's guide and not worry about changing any keys.

newman314 12y ago
link pls?
- ehPReth 12y ago
  https://help.github.com/articles/remove-sensitive-data/ https://help.github.com/articles/remove-sensitive-data/
ncallaway 12y ago
While it's absolutely true that if the credentials haven't been pushed then you are not compromised, I would still encourage people to rotate their credentials regardless. All it takes is a mistake when deleting the sensitive information, or having pushed without realizing it to be compromised. Even if you're absolutely positive there wasn't a breach, it can be a good excuse to drill for a _real_ breach later. It never hurts to walk through the practice of what to do if credentials leak when there's no pressure.
- Dylan16807 12y ago
  A credential rotation drill does sound useful, but I'm kind of uncomfortable with assuming like that; it seems like sloppy thinking that can cause trouble down the line.

godzillabrennus 12y ago

Millions of emails for developers and no one harvesting this info thought it wise to obfuscate it in some way?

akerl_ 12y ago
Obfuscate the emails that are clearly visible on github.com? I think by this point it should be pretty clear that email addresses, like domain names, are not secret information. Obfuscating the data would have mangled useable information for a goal of blocking people who would have had no trouble gathering that information anyways.
bhuga 12y ago
Emails are part of commits, which are hashed as part of normal git operations. There's no way to make repositories public and not make emails public.
- xai3luGi 12y ago
  You could set your author email address to an empty string before committing.

akerl_ 12y ago

To be clear, the guide from GitHub that's linked at the top of this article clearly states that you should consider the sensitive data compromised. Cleaning it out of the repo is a good move, but it's a companion move to rotating out those creds or whatever for new ones.

fragmede 12y ago
That guide highlights this in its own box. In red. Not sure how GitHub could make it more obvious. Perhaps if they mentioned there are unscrupulous users out there who have a script that hammers GitHub's events API to search for exposed passwords/keys, then it would reduce the 'oops I only pushed it for a second' thinking that users likely go through.

deleted 12y ago

[deleted]

PhantomGremlin 12y ago

If you ever put anything out on the Internet, not just to GitHub, consider it to be public information. Forever. You might be able to convince archive.org to remove it, but there are hundreds of players out there who aren't as ethical. Ben Franklin figured this out many years ago: Three can keep a secret, if two of them are dead.

baxter001 12y ago

A script to post random key containing config-like files to public repos and waste these guy's bandwidth/light them up on amazon's blacklist radar would be a cool idea.

deleted 12y ago

[deleted]

guiambros 12y ago

> In this post, I’m going to show exactly how hackers instantly harvest information committed to public Github repositories... A few days ago I published my blog to GitHub, with my MailGun API key in the config file (stupid mistake, I know). In less than 12 hours, spammers had harvested the key AND sent a few thousand emails with my account, using my entire monthly limit. Thankfully I was using the free MailGun account, which is limited to only 10,000 emails/month, so there was no material damage. Their tech support was awesome in immediately blocking the account and notifying me, and then quickly helping to unblock the account after keys and passwords were changed, and repo made private. I was exactly wondering how they were able to harvest GitHub content so quickly; it couldn't be web scrapping or a random search. This article explains well how to drink from GitHub's events firehose and the GHTorrent project, so everything makes sense now. Thanks for posting it. EDIT: This other post[1] describes a similar situation. There are some folks monitoring ALL GitHub commits and getting psswords as they are commited, on the fly. [1] http://www.devfactor.net/2014/12/30/2375-amazon-mistake/ http://www.devfactor.net/2014/12/30/2375-amazon-mistake/

infinitone 12y ago
I had a similar but less pleasant experience. I had decided to opensource an old side project of mine, that gets a good amount of users daily. And by that, it was just initially to make the repo public. But I had totally forgot about the mail server keys- this was a paid mail server, so you can imagine my disbelief when I get an email of a $1000 bill and a complaint saying that I had sent upwards of 250k emails with what seemed to be a iOS mail app malware email. Luckily it was resolved within a week with support.
- andyjdavis 12y ago
  I'm curious. Did they excuse the bill or was this a $1000 lesson?
  - infinitone 12y ago
    Yup, it was credited as they checked the IPs of the server that was sending those requests. It was clear that it was malicious, also I had been a long time customer.

xasos 12y ago

Always use environment variables. They are probably the best way to safeguard your API keys.

TTPrograms 12y ago
I've always wondered the proper way to deal with this, and this makes total sense. How would you typically set such an environment variable? In bash init?
- xasos 12y ago
  It depends on language. In node, you can set environment variables in the code with process.env and Python with os.environ and then use those to specify the values on the command line. In fact, even services like Heroku will let you edit these from their web-based client.
  - kbenson 12y ago
    That's really more of an implementation detail though. You'll want a file to specify these environment variables, so you can actually have services start on boot, so that means you need a config file (whether it's used for setting the environ, or read directly by the application is the implementation detail). What's really needed is to correctly separate and secure important configuration options outside of source, and designing for that from the beginning. Using environment variables in a way forces this, which is good, but it doesn't help if there's just a startup script that specifies those variables and it gets accidentally committed to the repo.
- sesteel 12y ago
  Environment variables can work well for development but I wouldn't put them in .bashrc or .bash_profile; if you are like me, you like to store your dot files somewhere public. I typically leave them in an encrypted file on dev systems, but this only solves the accidental over the shoulder problem. Production systems require another level of security altogether. Typically, I've seen services run in restricted user accounts with limited system access, reading passwords out of an encrypted file. This file is stored in some obscure location on the box to which that user account is the only one with read permissions to. Keep in mind, every system has weaknesses and I am still interested in listening to others' approaches.

xasos 12y ago

It always amazes me to see the sheer amount of API keys left around in GitHub repositories. You can search anything like Twilio API Key and come out with hundreds of thousands of results. I wonder to what extent these keys have been exploited.

deleted 12y ago

[deleted]

dllthomas 12y ago
"API keys [...] need to be in your committed code" Why?
thefreeman 12y ago
They really don't. You can read them from environment variables (which would be set by your platform eg. heroku) or you could set up a vagrant instance with the necessary services to develop locally.
Killswitch 12y ago
> "API keys [...] need to be in your committed code" No they don't.
- kevinmobrien 12y ago
  >> "API keys [...] need to be in your committed code" > No they don't. A better approach is what the rest of the comments here are suggesting: (1) store your secrets (API keys, certs, credentials, whatever) in a highly-secure system, with both strong encryption and immutable audit logging around their access and modification; (2) expose those secrets at run/compile-time via variables, such that the secret is never stored on-disk anywhere other than in the highly-secure system from (1) and in transient storage while in use; (3) wrap an authz layer around variable access, so that only authorized services/users/hosts (those that have authenticated properly and who are allowed access via the authz policy established here) can read/write/mutate the secrets It's (basically) the "privileged identity management" space; the challenge is that the commercial software in that market hasn't kept up with the combination of automated ops infrastructure and cloud-hosted dev tools. There are some ideas around how to do 1-3 better, with a devops/cloud-native design built in. (Full disclosure: I'm part of the founding team at a company doing this.)
  - devonkim 12y ago
    The PIM software I've seen in enterprise (stuff even older than what Cyber-Ark has) has barely even kept up with software from the early 2000s let alone modern automated operations infrastructure. APIs that are written for XML-RPC and even XDR for crying out loud (that implies that even TCP was a tough sell for them). Automating them has been an exercise in incredible pain for few rewards. Even AWS CloudHSM is not revolutionary conceptually as much as from a compliance and paperwork standpoint. I think there really needs to be emphasis on a (4) - all secrets must be rotated and revokable on-demand and on semi-random schedule. The goal is to make any credential only valid for a period of time less than what an attacker that is already present on your systems would need to further increase presence or to compromise any of 1-4. Who cares if an instance is owned if it's up for maybe 10 minutes and can literally only communicate on a specific port to a specific server with a specific protocol? Unfortunately, this is all only reasonable in a highly automated architecture and is basically impossible with almost every single company I've ever seen that's ever uttered the mere word ITIL because those companies tend to be people-driven cultures for everything, not process-driven (most companies try to add policies that are so ineffectual and meaningless that everyone reverts back to tribalism similar to how everyone defaults to e-mail when collaboration tooling is ineffective) that you have to figure out to be effective in cloud environments. I do devops and security automation as well, and there's nothing self-serving about your points if you ask me.

olefoo 12y ago

There's a fairly straight forward pattern for keeping sensitive credentials out of github. It comes straight from http://12factor.net/config http://12factor.net/config store configuration data in the environment. What I do for most projects is keep the tree containing the working directory in a directory that has some other items that don't belong on github (like the project brief, my emacs bookmarks file, random notes related to the project etc. ) and in that directory there is a .credentials file containing a set of export statements somewhat like: export AWS_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXX export AWS_SECRET_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX export AWS_USER_ID=############ If I'm feeling extra paranoid, I'll encrypt that into a blob that I only decrypt when I'm working on said project. Then at startup the app goes looking for it's config in the environment. This does create issues for some environments ( solving this for docker is trivial ) but you can usually pass environment variables to whatever is executing your code reasonably securely. Now it's not perfect, and environments can sometimes be revealed externally if an attacker is determined and clever and focused on your app for some reason. But it does give you a hygienic procedure that keeps your credentials that are equivalent to an open draw on your bank account out of public repositories.

califield 12y ago
I use the `dotenv`[1] package with Node.js and it does exactly the same thing: environment variable definitions that you can store elsewhere in a dead-simple format. To be fair, I think they just copied the `foreman` tool from Heroku. However, it works great. Most projects don't need anything more than a flat hierarchy of secret keys and values. Writing your own parser for a `.env` file is a piece of cake, even in shell language. Adding `etcd` is better, but it's too much work for a small project. [1] https://github.com/motdotla/dotenv https://github.com/motdotla/dotenv
- kgilpin 12y ago
  12 factor and .env make a lot of sense. However they still leave some questions unanswered, such as: How do the secrets get safely distributed to the machines where they are needed? How to revoke/rotate a secret, especially once a compromise is suspected? How to perform all this in DevOps-y, automated systems? This is the problem space I work in.

nutanc 12y ago

I think this problem is widespread enough and there are enough idiots out there(me included),that there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted.

mkal_tsr 12y ago
> there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted. Sure, just enumerate any and all possible types of sensitive data, the format they may be in, regex / matching functions to account for them (supported across 20+ programming languages) and I'm sure Github will have that done asap. Alternatively, don't commit passwords/API-keys/sensitive-info to your repo.
- lambda 12y ago
  > Alternatively, don't commit passwords/API-keys/sensitive-info to your repo. This is, of course, the right answer. However, it's frustrating that several frameworks make this very easy to get wrong. Anything that has an application.yml, database.yml, or similar configuration file that normally lives within the same directory as the source code, and which is intended to contain credentials, means that lots of people will make that mistake. It's one of the fundamental errors that you see so often in web frameworks like Rails, this whole idea of mixing application code and configuration files into one big tree. I don't know how this practice caught on, but it has, and it so frequently causes mistakes, both big ones like accidentally publishing credentials, and simply frustrating ones like confusing the difference between application code and configuration in ways that make it more difficult to have multiple local configurations and updating the application code independently.
  - deleted 12y ago
    [deleted]
- jemfinch 12y ago
  > Sure, just enumerate any and all possible types of sensitive data False dichotomy. It doesn't have to be "everything" or "nothing". An 80% solution here is better than nothing. I still find it useful that gmail warns me before I send an email without an attachment if I've written "I've attached" in an email. Can gmail detect with 100% accuracy if I intended to send an attachment? Of course not. But the 80% solution here still does me and lots of other people a lot of good.

femto113 12y ago

My advice: USE PRIVATE REPOS! At $7/month Github's micro plan with 5 repos is just $1.40/repo-month. This is the cheapest insurance you can get against the nearly inevitable mistake of committing something sensitive.

stinos 12y ago
Could also have a look at BitBucket instead: unlimited private personal (or teams of max 5) repos at $0/month. Or for $7/month you can host your own at DigitalOcean/Azure/...
mmahemoff 12y ago
Sure, use private repos for private projects but this is about open-source authors accidentally leaving their credentials in config files and the like.
- femto113 12y ago
  Anecdotally this seems to happen mostly from personal experiments, not from development of open source software meant to be consumed by others. Secrets generally are included in projects that are meant to be deployed (like a rails app, or a blog, or ...), not in thelibraries/gems/modules that make up the bulk of open source found on Github.

icymatter 12y ago

Github has very good cache. In the past, when I deleted a repository I still was able to access some diff and commit information from my own activity pages. I had to request Github team to clear that page manually.

deleted 12y ago

[deleted]

DenisM 12y ago

On MacOS theres keychain - it's a designated place for storing secrets. On windows I create a batch file at a fixed location with all the credentials in it. A script simply runs this batch file and reads the env cars to get values. A compiled program parses the batch file with regex to find required values. This works remarkably well for keeping credentials out of the code base. Hope that hels someone.

revelation 12y ago

So many words for one simple principle: if sensitive data has been publicly accessible or transferred in plaintext over the internet, consider it compromised, logged stored and abused. The only recourse is to immediately change or revoke access.

jpdlla 12y ago

Thinking of actually working on a tool for this. Will have a blacklist of "searches" that might contain sensitive data and perhaps notifying via the email of the committer or creating an issue on the repo. Anyone else want to get involved?

jpetersonmn 12y ago

First time I tried to use github I uploaded my gmail password which I was using to send myself an email when something failed. I figured that there would be bots that would scoop up that information right away. Luckily I realized what I had done before people could get into my gmail.

rilita 12y ago

TLDR: It won't save you because people could have copied the information before you deleted it. Duh?

sheetjs 12y ago
TL;DR: github makes it easy to notice when events have occured, so easy that you can write tools to copy information as soon as it hits. This is a bit more nuanced than your summary because GH makes it easy. Without the events API, you would have to poll the various repos to find out if changes happened Furthermore, the existence of GHTorrent demonstrates the ease with which this information can be harvested
- rilita 12y ago
  So what you are saying is that because Github provides a clean API we should be more careful about posting sensitive data to it versus other things where you can simply scrape index pages? I fail to see how the warning is meaningful. One should assume anything you post to the public internet may be public forever. The existence of an API changes nothing as far as the amount of care you should take.

deleted 12y ago

[deleted]

tlrobinson 12y ago

Are there any open source git hooks that will scan your code for known credential formats?

jquast 12y ago

I'm very certain this is a hacker's account configured to follow a great deal of projects and people (2k projects, 1.3k users) for this very purpose -- a suspicious [redacted] [unknown] profile, https://github.com/trnsz https://github.com/trnsz

morkfromork 12y ago

What would happen if you published a few billion fake credentials?