WingNews logo WingNews GitHub [2]
top | item 13650818

GitHub commit search: “remove password”

861 points| rsc-dev | 9 years ago |github.com | reply

257 comments

order
[+] jvehent|9 years ago|reply
Too many comments here recommend to clean up the commit and just hide the mistake under the rug. This is wrong.

If you leak a password to any public location, there is only one reasonable course of action: CHANGE IT!

Don't even bother rewriting the commit. Focus on changing that password right away, and while you're at it, figure out a better way to manage your secrets outside of your source code in the future. Mistakes happen, but they shouldn't be repeated.

[+] chmike|9 years ago|reply
the solution is to store the password and any other sensitive information in a text file that you read when your program starts up. And don't forget to add that file's name to .gitignore so git will ignore it. As simple as that. :)

If you leaked the password in the git repository, change it as @jvehent just commented.

[+] brettdong|9 years ago|reply
Completely agree. There are forks, mirrors and crawlers on GitHub, even you rewrite the commit and force push to GitHub server, the original commit data still exists in the forks and mirrors, and in fact anyone can even view the original commit in your own repo if they know its commit hash.
[+] lholden|9 years ago|reply
Very much this.

The first thing you should be doing is making the password useless by changing it. Doing anything else is entirely irresponsible. Sure, remove the file in question after that... but you can't treat the old password as anything other than public knowledge at that point.

[+] libeclipse|9 years ago|reply
I've only ever leaked a webhook, realised minutes later, and then changed the webhook URL on the backend. It's not hard to do, and doing anything else is simply really crappy security through obscurity while hoping for the best.
[+] olegkikin|9 years ago|reply
But what if your codebase is used in thousands of places that you don't control? You can't always change it.

The real lesson is - don't put passwords in your code.

[+] muyuu|9 years ago|reply
Reminds me of the Bitcoinica fiasco.

Stuff happens, especially under pressure. But yeah, if that happens to you, there is no more reasonable course of action than changing it right away.

[+] typetypetype|9 years ago|reply
100% agree with this. Not worth the hassle to do anything else.
[+] josscrowcroft|9 years ago|reply
I liked this one:

https://github.com/squared-one/omniauth-unsplash/commit/072b...

"... It's not really removing any password, is it? But hey, why not use the momentum ... wheeeeeeeeeeeeeeeeee!"

[+] olegkikin|9 years ago|reply 

    -    protected $password = '12root34';
    +    protected $password = '';
"I'm a bit disappointed now that putting 'protected' in front of the password doesn't protect it ;)"
[+] ag_47|9 years ago|reply
Another less 'relevant' result:

  -    acceptHandshake = params.pass == PASSWORD
  +    acceptHandshake = true//params.pass == PASSWORD
[+] dorianm|9 years ago|reply
Right after my "remove secrets" post: https://news.ycombinator.com/item?id=13650614

There are just so many of those it's crazy:

    remove .env
    YOURFAVORITEAPI_SECRETKEY
    YOURFAVORITEAPI_PASSWORD
Also replace "remove" with delete/rm/replace/etc.

And replace "YOURFAVORITEAPI" with CircleCI, Travis, Mailchimp, Trello, Stripe, etc, etc.

Also, companies I contacted consider it the customer fault and basically don't care.

[+] plasticbugs|9 years ago|reply
I once pushed my Amazon S3 key to GitHub accidentally. Realized instantly what I'd done, and while in the process of feverishly regenerating a new key, my cell phone rings. It's Amazon telling me I pushed my S3 key to GH.
[+] shawabawa3|9 years ago|reply
It is customer fault.

However it should be pretty easy for them to set up a script to search github for this kind of stuff and automatically invalidate keys

[+] hartleybrody|9 years ago|reply
MailChimp has something like this. A few years ago I accidentally committed and pushed an API key, and I got an email from them a few minutes later saying that they had found the key and already invalidated it, so it couldn't cause any damage. Very proactive and smart, especially for an email service which is likely a huge target for abuse around this sort of thing.
[+] teaearlgraycold|9 years ago|reply
Someone should create an app where you select an API service and it gives you a key that's been pushed to a public GitHub repo.
[+] lucideer|9 years ago|reply
There are so many of these.

It gets a little scary when it veers from professional security to individual personal privacy https://github.com/search?p=2&q=smtp.gmail.com+pass&ref=sear...

[+] unethical_ban|9 years ago|reply
META

I notice in many instances Github showing an error.

We could not perform this search: Must include at least one user, organization, or repository

But if you change anything in the URL, it works again. Such as adding &p=2, which lucideer tried. But I got the error on his link. So I changed it to p=3, and it worked.

So I'm guessing Github has an autodetection for a particular global code search getting high hits (for something like this, I assume) that locks people out.

Seems more like a band-aid on a broken leg, though.

[+] AckSyn|9 years ago|reply
I should be amazed at how prevalent this is but after almost two decades in IT/IS, it's no more than the equivalent to the Post-IT on a monitor, but more accessible. Dumb, but business as usual.
[+] chiefalchemist|9 years ago|reply
Computers are supposed to be good at what imperfect humans are not. This only proves how primitive the tool is.

That is, for example, if Gmail can ask "it looks like you forgot the attachment" why can't Git say "this is a public repo and you're about to commit and push passwords. Are you sure?"

It's going to be easier to fix the tool than it is to make humans be perfect.

[+] wongarsu|9 years ago|reply
Gmail can make a simple keyword search for a handfull of phrases in something that's known to be text

Git would have to first decide whether a file is a textfile or binary file, a decision that can be done reasonably well heuristically but that is undecidable in the general case. Then it has to parse text files for a long, curated list of known keywords that are only used for storing API keys and are not (usually) used in normal code. I'm not sure if that's even feasable.

And then of course git has no concept of "public" and "private" repos, so the entire task can't be handled well by git.

[+] ysavir|9 years ago|reply
I don't see a need for Git or Github to do this. Would be simple enough to set up your own Git precommit hook, that can be shared if you like.
[+] Latty|9 years ago|reply
While there may well be common trends, Git is a tool for arbitrary content - it's going to be pretty hard to accurately find passwords/secrets being committed. There are tools out there for more specific sets of stuff, but expecting git to catch anything is a little much.
[+] s_kilk|9 years ago|reply
How would git know that it's a password/key/whatever?
[+] KyeRussell|9 years ago|reply
I'd say that it's hard to implement this effectively. Maybe as a language / framework-specific hook.
[+] BenderV|9 years ago|reply
Good idea! Shouldn't be so hard to implement a simple prototype.

if "PASSWORD=xxx" in text => prompt alert or ask confirm

Next step would be to take this list (search result), make a curated list of 100-1000 unencrypted password (text/line + files + infos of repo), and then hard code some rules to detect +80% of cases.

[+] raesene6|9 years ago|reply
This is a good example of the increased risks from doing your development out in the open, any mistakes are exposed to a much wider group of potential adversaries.

On an internal VCS, this would still be a problem, but a bit less visible/exploitable...

[+] Xylakant|9 years ago|reply
On an internal VCS this may be a deliberate decision: Secrets need to be stored somewhere and a cost-risk analysis can result in "this is the best place that we currently have at our disposal". That obviously won't fly if your threat model includes "adversary may attack our github account from within GH" or if you ever plan on opening up that repo, but if neither applies this may be the best place to store some sorts of secrets.
[+] c3833174|9 years ago|reply
Don't hardcode things, .gitignore your production config files, check in conf.example if needed.
[+] Vinkekatten|9 years ago|reply
We've published internally developed projects on github after removing anything sensitive and initializing a new repo from the latest version of the code base.

You lose your development history, but you ensure you won't get bitten by stuff like this.

[+] danarmak|9 years ago|reply
Search for "update password" and you'll see almost as many results (268,000), many presumably with active passwords.

"Add password" finds 792,000 results, of which at least some (on the first page) are actual passwords.

[+] Jonnax|9 years ago|reply
I'd hope that all those people promptly changed their passwords after realising. But 200k commits, I'm sure a good percentage of them didn't.
[+] sirn|9 years ago|reply
Searching filename:id_rsa also yield a rather interesting result. Alongside with "BEGIN OPENSSH PRIVATE KEY". I wonder how much of these also contains ssh_config.
[+] brightball|9 years ago|reply
People...seriously...

I get it...you like github but you don't want to pay for private repos. That's when you use Gitlab or BitBucket and then this problem goes away.

[+] segmondy|9 years ago|reply
Well, we suppose that's a solution of some kind. How about never committing passwords and having passwords hardcoded in your codebase?