14 ms·

GitHub commit search: “remove password”

861 points by rsc-dev 10y ago

Jonnax 10y ago
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.
starefossen 10y ago
Or try "remove aws"
- Cthulhu_ 10y ago
  I tried "fuck", but it's nowhere near as prevalent as "remove password"
  - jcastelein 10y ago
    Give "oops" a try
    - karrotwaltz 10y ago
      "stuff" isn't far behind
      - timborden 10y ago
        Always been a fan of "fix" ...LOL
        prodigal_erik 10y ago
        Fixed? At least "wip" for "work in progress" doesn't raise your expectations too much.
ioquatix 10y ago
Git-crypt is your friend!
- nickik 10y ago
  Cool. I did no know this existed. I did not know that I wanted it. Now I want it.
- dorianm 10y ago
  Then .gitignore and .env are your best friends :)
  - ioquatix 10y ago
    git-crypt suits a significantly larger set of use cases such as storing private keys, etc.
deleted 10y ago
[deleted]
dorianm 10y ago
Right after my "remove secrets" post: https://news.ycombinator.com/item?id=13650614 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.
- shawabawa3 10y ago
  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
  - dorianm 10y ago
    1) Search for common pattern where the key can be stored 2) Search if found keys are actual valid keys 3) Expire key, send explanatory email, issue new key (I think that's what AWS does)
  - Flimm 10y ago
    Heroku's official Python template include `.env` in the repo: https://github.com/heroku/python-getting-started https://github.com/heroku/python-getting-started https://github.com/heroku/heroku-django-template https://github.com/heroku/heroku-django-template (Although, to be fair, they do include `.env` in the `.gitignore` file.)
  - _pctq 10y ago
    And this would be a cool feature from github too. A link mentioning "we found something in your code that looks like a secret, please know people will use it."
    - Klathmon 10y ago
      They do this for all of their own API keys already. They not only notify you but instantly invalidate a key pushed to a public repo. Annoyingly there is no way to turn it off even when you explicitly want to share an API key knowingly. But i'm more than fine with needing to "obfuscate" an API key or manage secrets correctly knowing it saves TONS of people.
karrotwaltz 10y ago
Related topic: "Production AWS keys on GitHub" ~ 3 years ago https://news.ycombinator.com/item?id=7411927 https://news.ycombinator.com/item?id=7411927 By just looking quickly, it seems that you can still find many recent live keys...
- dorianm 10y ago
  Amazon scans GitHub and revokes valid keys (can't find source, but proof is that it's been a while no AWS keys were stolen from GitHub)
  - tinco 10y ago
    I have it on good authority ( >_> ) that this is indeed true.
  - dotancohen 10y ago
    I'm embarrassed to say that it's happened to me. I deliberately created an IAM user that was 'public', for purposes of the application. Amazon shut down that user and everything (not much) that it had access to. This was in 2014 or 2015.
jamesphillips 10y ago
Once it's on the internet. Sites like github have become an amazing OSINT tool.
lucideer 10y ago
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=searchresults&type=Code&utf8=%E2%9C%93 https://github.com/search?p=2&q=smtp.gmail.com+pass&ref=sear...
- chillydawg 10y ago
  Wow, that is scary.
- AckSyn 10y ago
  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.
  - ProblemFactory 10y ago
    > the equivalent to the Post-IT on a monitor Writing passwords down on a piece of paper, and keeping that in your wallet or locked desk drawer is actually one of the more secure ways of storing passwords these days. No risk of electronic compromise, and its highly unlikely that people who would steal your wallet or break into your home are also interested in your online accounts.
    - deleted 10y ago
      [deleted]
    - patrick_haply 10y ago
      To be honest, and not that I ever would, but, if I stole your laptop, the moment I would become interested in your online accounts would be the moment I found your paper with all of your passwords on it.
    - puddintane 10y ago
      This still has many flaws. 1. New guy gets hired. 2.You work for a large corporation and we'll you can't say you can trust everyone there. 3. Small company of 10 (company I work at for example) could be compromised by the weekly janitor. 4. Someone could break in and make it look like a robbery all while stealing your critical infrastructure. I recently helped research a bit about internal security for our office and sticky notes are still a very common place for credentials to be compromised.
oelmekki 10y ago
The worst part in that is that it provides tons of passwords to analyze and detect recurring words or schemes. This probably also will hurt people that never commited their passwords in public repos. Github should probably filter out such searches.
- raesene6 10y ago
  I think the ship of "easily analzed password dumps" has already sailed e.g. https://xato.net/today-i-am-releasing-ten-million-passwords-b6278bbe7495#.1iy9voua1 https://xato.net/today-i-am-releasing-ten-million-passwords-... <-- 10 million passwords
  - oelmekki 10y ago
    Yeah, indeed. I guess we can expect password schemes to change over time, so it's still a good idea to prevent it. Not sure in which proportion it helps, though.
sagivo 10y ago
git is a great tool, unfortunately there's no standard of storing sensitive info (like passwords). some store it as ENV variables, some hard copy the files to servers using custom scripts etc.. would love to see an easy tool that developers can use to manage this info like people manage files on git.
raesene6 10y ago
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...
- c3833174 10y ago
  Don't hardcode things, .gitignore your production config files, check in conf.example if needed.
- Xylakant 10y ago
  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.
  - Klathmon 10y ago
    I've gone through the process of open-sourcing previously closed codebases, and in virtually all of them a decision is made to make a single "genesis" commit to start the public exposure because there's just not enough manpower (or I don't know git well enough) to go through and ensure there not only aren't any secrets now (meaning passwords, or info the company doesn't want to release), but also there weren't at any point in the past.
    - Vinkekatten 10y ago
      Genesis commit, that's a catchy name for it. We've done the same thing, after some discussion this always ends up making the most sense. Also, you can hide your crimes and not show off all your "TODO: put more stuff here" commits to the world.
      - deleted 10y ago
LeonidBugaev 10y ago
If you found a similar mistake in your repository, you can delete commit from history using: `git rebase --onto <commit-id>^ <commit-id>`. Or if you want actually rewrite it, see git rebase -i` documentation.
- danieldk 10y ago
  Doesn't that requires a force push? Force pushes are acceptable for private repositories with a single user, but typically not in larger projects. Just revoke the password/secret/whatever.
  - adrianN 10y ago
    Or do both? Better safe than sorry.
    - jomkr 10y ago
      It's better to just revoke and not re-write git history in a public repository. Re-writing history is pointless after the credentials are revoked, and causes a headache to others using your repository.
  - majewsky 10y ago
    I find force pushes acceptable for topic branches of public repos. In fact, I use them a lot to leave behind clean history. Same as with squash merges, which technically also lose history.
    - prodigal_erik 10y ago
      It's better to push a similar name and let people decide if and when to rebase --onto the new upstream. Squash merges are just bad. They destroy all the info that makes git handle branching and conflicts better than svn.
- avip 10y ago
  You'll have to revoke committed credentials regardless, as github is so frequently scrapped to find such content.
drinchev 10y ago
How do you guys, handle this problem? I use either `git-crypt` [1] or `ansible-vault` [2]. 1: https://github.com/AGWA/git-crypt https://github.com/AGWA/git-crypt 2: http://docs.ansible.com/ansible/playbooks_vault.html http://docs.ansible.com/ansible/playbooks_vault.html
- FanaHOVA 10y ago
  ENV variables. I use `dotenv` in Ruby projects.
- StavrosK 10y ago
  Yep, same here. I prefer git-crypt, but we use Ansible vault too.
- tildedash 10y ago
  I follow the 12 factor app methodology (https://12factor.net/ https://12factor.net/), everything in ENV.
- reitanqild 10y ago
  And it actually uses GPG : )
- dekz 10y ago
  .env or ENV with AWS KMS
- adamors 10y ago
  Dotenv and Ansible vault, depending on the project. I also want to look into Hashicorp's Vault https://www.vaultproject.io https://www.vaultproject.io
- aequitas 10y ago
  For puppet users: https://github.com/TomPoulton/hiera-eyaml https://github.com/TomPoulton/hiera-eyaml Advantage of this approach is it encrypts the values individually instead of per file. This way the secrets files are git/review friendly.
sirn 10y ago
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.
WildUtah 10y ago
When you put your dotfiles in a repository online, be sure to commit all the public keys and none of the private ones. Github, like SSH, uses an asymmetric authentication scheme. They even publish everyone's public keys. It's much more secure than passwords.
franzwong 10y ago
You'd better change the password instead of removing it.
djm_ 10y ago
A good a time as ever to mention AWS's provider-agnostic secrets-aware git hook that attempts to prevent this at the repository level [1] [1] https://github.com/awslabs/git-secrets https://github.com/awslabs/git-secrets
dpix 10y ago
This is the main reason I use gitlab, because they have free private repos. When your trying to smash out code as fast as possible in a startup you don't want to have to worry about acccidently checking a secret in
- hasperdi 10y ago
  Bitbucket is another alternative for free private repos.
chiefalchemist 10y ago
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.
- KyeRussell 10y ago
  I'd say that it's hard to implement this effectively. Maybe as a language / framework-specific hook.
- s_kilk 10y ago
  How would git know that it's a password/key/whatever?
  - diesal11 10y ago
    just make it search for files or variable assignments named "password" or "secret". That will catch the majority. In comparison Gmail doesn't catch all cases either, if you say something like "here are" instead of I've attached it misses it.
  - aaron695 10y ago
    Key is easy. The high entropy should tip you off. Passwords, look for variables with the name password, passwd assigned strings. Like Gmails attachment, it'll get stuff wrong, just make it easy to continue on.
    - tuxxy 10y ago
      This. However, it would only work with secure passwords. Setting the entropy count too low would result in a bunch of false positives.
  - epalm 10y ago
    I believe Django's logging framework will automatically replace strings in your settings.py file (basically a dict) with '*' if the key "looks like" a secret (contains the word 'secret' or 'key' or 'passw' etc).
sparkslabs 10y ago
I'll raise you a handful more: add password / add passwords * https://github.com/search?utf8=%E2%9C%93&q=add+passwords&type=Commits&ref=searchresults https://github.com/search?utf8=%E2%9C%93&q=add+passwords&typ... * https://github.com/search?utf8=%E2%9C%93&q=add+password&type=Commits&ref=searchresults https://github.com/search?utf8=%E2%9C%93&q=add+password&type... add secret / add secrets * https://github.com/search?utf8=%E2%9C%93&q=add+secret&type=Commits&ref=searchresults https://github.com/search?utf8=%E2%9C%93&q=add+secret&type=C... * https://github.com/search?utf8=%E2%9C%93&q=add+secrets&type=Commits&ref=searchresults https://github.com/search?utf8=%E2%9C%93&q=add+secrets&type=...
- beothorn 10y ago
  Also: search for code making connections to db ruby https://github.com/search?q=DBI.connect&ref=searchresults&type=Code&utf8=%E2%9C%93 https://github.com/search?q=DBI.connect&ref=searchresults&ty... java https://github.com/search?p=2&q=DriverManager.getConnection%28&ref=searchresults&type=Code&utf8=%E2%9C%93 https://github.com/search?p=2&q=DriverManager.getConnection%... and so on...
- hackerboos 10y ago
  Some of these commits are PGP signed...
  - pcr0 10y ago
    What do you mean by that? That people took the trouble to use PGP but then go and do something this silly?
    - TallGuyShort 10y ago
      It's a good reminder that the human is usually the weakest link.
    - hackerboos 10y ago
      Yes.
atti7 10y ago
reminds me of this: "I don`t know" https://github.com/search?p=1&q=+i+don`t+know&ref=searchresults&type=Commits&utf8= https://github.com/search?p=1&q=+i+don`t+know&ref=searchresu...
- yread 10y ago
  Heh the first result of this query has a password there as well https://github.com/budworth/cs313-php/commit/9113053776bb834261241474a8b97d5c7e1e49f6 https://github.com/budworth/cs313-php/commit/9113053776bb834...
sand500 10y ago
To people like me who have done this many times in the past and want to add the file to gitignore http://stackoverflow.com/questions/1139762/ignore-files-that-have-already-been-committed-to-a-git-repository http://stackoverflow.com/questions/1139762/ignore-files-that... The other alternative I can think of is to hide sensitive values in environment variables
- jholman 10y ago
  Careful. If you have already committed it, and you ever push the repo to a public GH repo, your key is compromised. Just because some benevolent slacker-attackers on HN aren't sniffing the PSHB event queue, doesn't mean no one is. If you ever send the secret to Github, criminals have it. If you ever committed it, and then you ever push, then you've sent it to GitHub. So yes, add the file to gitignore and git rm it, but also invalidate your keys and get new ones.
joshfarrant 10y ago
Throw the word 'oops' in for good measure. https://github.com/search?p=2&q=remove+password+oops&ref=searchresults&type=Commits&utf8=%E2%9C%93 https://github.com/search?p=2&q=remove+password+oops&ref=sea...
- ryanmaynard 10y ago
  I actually compiled a list of these from the last time this subject was mentioned on HN. http://gitoops.xyz/ http://gitoops.xyz/
random_upvoter 10y ago
Good thing all my commit messages are "xxx"
therealasdf 10y ago
For anyone wondering, if you want to remove a file or secret you've already committed, you can use BFG Repo-Cleaner to go through your commit history and completely remove any trace of it. https://rtyley.github.io/bfg-repo-cleaner/ https://rtyley.github.io/bfg-repo-cleaner/
- nailer 10y ago
  +1. Requires Java but BFG Repo Cleaner is the only app I've ever felt worth installing the JVM for.
  - dvdgsng 10y ago
    That's a pretty useless comment, don't you think?
- faitswulff 10y ago
  Just note that if it's a public repo, it may not help you, due to attackers scraping Github's API and mirrors like GHTorrent. From "Why Deleting Sensitive Information from Github Doesn't Save You": http://jordan-wright.com/blog/2014/12/30/why-deleting-sensitive-information-from-github-doesnt-save-you/ http://jordan-wright.com/blog/2014/12/30/why-deleting-sensit... The top HN comment on the article details their experiences with getting hacked this way: https://news.ycombinator.com/item?id=8818035 https://news.ycombinator.com/item?id=8818035
  - deleted 10y ago
    [deleted]
  - Flammy 10y ago
    Warning - in the HN comment that is linked, don't click the link, is a browser popup spam which is actually hard to close (url has been dropped and picked up by a spammer?)
- seanwilson 10y ago
  Sounds like a better idea to just change the secret.
cultavix 10y ago
imagine private repo's :)
martincmartin 10y ago
Years ago, there were proggit posts of google searches for open myphpadmin consoles. I think people then went and deleted/messed with the databases. My search fu is failing me though, I can't find any of those threads.
hharnisch 10y ago
Thank you for highlighting this is a such a common mistake. I hope developers of all skill levels look at this and realize it how easy it is to make this mistake and learn from it.
_joel 10y ago
Another for the list, JSON or YAML containing 'password' - https://github.com/search?utf8=%E2%9C%93&q=password+extension%3Ayaml+extension%3Ayml+extension%3Ajson&type=Code&ref=advsearch&l=&l= https://github.com/search?utf8=%E2%9C%93&q=password+extensio... Reminds me of the eye opening experience available at https://www.exploit-db.com/google-hacking-database/ https://www.exploit-db.com/google-hacking-database/
empath75 10y ago
Rotate your keys and passwords in production, everyone.
josscrowcroft 10y ago
I liked this one: https://github.com/squared-one/omniauth-unsplash/commit/072bc946b5d069d0f30b32f8f3cc53d22abff36e 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!"
- paulcole 10y ago
  just growth hacking
- olegkikin 10y ago
  - protected $password = '12root34'; + protected $password = ''; "I'm a bit disappointed now that putting 'protected' in front of the password doesn't protect it ;)"
- shitgoose 10y ago
  free advertising. genius!
- ag_47 10y ago
  Another less 'relevant' result: - acceptHandshake = params.pass == PASSWORD + acceptHandshake = true//params.pass == PASSWORD
  - purple-again 10y ago
    That just seems like a guy testing his authorization code. I would expect the next commit to put it back to its functional state.
    - ag_47 10y ago
      Like 'Revert "remove password"'? ;-)
EJTH 10y ago
Almost as many results on 'remove credentials' :-)
brightball 10y ago
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 10y ago
  Well, we suppose that's a solution of some kind. How about never committing passwords and having passwords hardcoded in your codebase?
  - brightball 10y ago
    Also that
westoque 10y ago
Good find. Reminds me of the a query done for Google Search that exposes sites vulnerable to SQL injection.
anacleto 10y ago
Holy shit!
androtheos 10y ago
Not nice
danarmak 10y ago
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.
kxait 10y ago
some of these seem legit
jakobov 10y ago
Someone here should make a bot and leave comments on all those commits warning people to change their passwords.
ssebastianj 10y ago
Maybe a confidential-linter or git pre-commit hook would be nice to prevent leaking confidential information.
burnbabyburn 10y ago
leaks of this types are known since AGES, and still people are unable to keep private things private.
bigtunacan 10y ago
This made me realize an unexpected (to me) search behavior on Github. Basic/Default search will search commit history, but if I try to add advanced options I don't appear to get search history. https://github.com/search?utf8=%E2%9C%93&q=remove+password+user%3Anicksagona&type=Repositories&ref=searchresults https://github.com/search?utf8=%E2%9C%93&q=remove+password+u... Here I was trying to search for "remove password" just on repos for nicksagona (just happened to be one of the first users to display when you go to this thread's search). That comes up with zero results. This leaves me wondering how I would run similar searches on repos that I'm involved with as a way of auditing to make sure none of them have compromised passwords that would need changed. I would love to hear suggestions on how to do this.
palerdot 10y ago
Just using a random commit name like 'minor bug fix', 'updated version' for these kind of commits will save a lot of headaches like this. One can do better by adding random lines/ logs in lot of files and sneakily remove password from one of them and then give a random commit name. But then it all boils down to your mindset at that particular moment when you are commuting.
- jvehent 10y ago
  > Just using a random commit name like 'minor bug fix', 'updated version' for these kind of commits will save a lot of headaches like this. Just change the leaked passwords, don't try to hide the commits.
  - vidyesh 10y ago
    Precisely, just change the password/key and don't do anything at all. People might think you are stupid or think used random text, either way you are safe.
- dbg31415 10y ago
  Don't commit passwords. Put them in a config file and .gitignore it. You could upload an example file... but please don't put real passwords in the example file.
- Xorlev 10y ago
  Security by obscurity is no security at all. Revoke the creds and then either just remove them or run BFG as a secondary measure.
jvehent 10y ago
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.
- Kunix 10y ago
  Blackbox is one good way to store secrets: https://github.com/StackExchange/blackbox https://github.com/StackExchange/blackbox
- libeclipse 10y ago
  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.
  - thecrazyone 10y ago
    Why would a webhook URL be a secret? Wouldn't it be more like internal API if anything? I would assume that the parameters sent to the webhook, an auth token or something of the sort would take care of the security bit. Obscuring the URL seems like security-by-obscurity no?
    - ksenzee 10y ago
      For purposes of security, there's no difference between example.com/api/my-webhook?auth-token=[some-uuid] and example.com/api/my-webhook/[some-uuid].
    - olalonde 10y ago
      Not if you treat the secret URL like a password. Plus, not all webhook callers allow you to authenticate them without supplying them a special URL.
joshuajeeson 10y ago
Another one: Search for Root password :D
wybiral 10y ago
A while ago I discovered similarly that there are several searches which lead you to active database logins. https://github.com/search?&q=mysqli_connect+http&type=Code https://github.com/search?&q=mysqli_connect+http&type=Code https://github.com/search?q="rds.amazonaws.com"&type=Code https://github.com/search?q="rds.amazonaws.com"&type=Code etc...
- Keverw 10y ago
  Wow. People would really store production passwords on GitHub for everyone to see? I wonder if GitHub blocked those searches "We could not perform this search Must include at least one user, organization, or repository" Edit: If I click on PHP for the language in the sidebar they show up. But hmm, I wonder if maybe GitHub tries to block leaks like that from being searched.
  - wybiral 10y ago
    Yeah, I just started getting those too. But adding "&p=2" to the URL shows results for the next page... shrug
    - problems 10y ago
      You could probably also just use Google to find them with site:github.com.
      - wybiral 10y ago
        When I was a teenager I liked to use search engines to find PHP upload tests. People almost always served uploaded files from a directory and made no distinction between .jpg or .php files. (No, I didn't exploit this, I just enjoyed finding them)
tmsldd 10y ago
The question is: how many are left in the wild?
athenot 10y ago
Even more frightening: https://github.com/search?utf8=&q=id_rsa&type=Commits&ref=searchresults https://github.com/search?utf8=&q=id_rsa&type=Commits&ref=se...
- mzzter 10y ago
  Wow private keys just sitting in plain sight o.O
  - ryanmaynard 10y ago
    From a former HN discussion http://gitoops.xyz/ http://gitoops.xyz/
- deleted 10y ago
  [deleted]
nico01f 10y ago
Wow!!! This could be a big thing. It's time to write: How to write code without expose you
mzzter 10y ago
I would recommend using torus.sh or other secret manager instead of an env or text file. I've forgotten to include them in .gitignore too many times.
thrillgore 10y ago
One of the things I've done after making this mistake was creating an example config file for this information, committing that, and then dropping a gitignore on the real config file.
adamvalve 10y ago
This one seems to be a winner: https://github.com/wrmsr/dotfiles/commit/a6597efe0421b6b0cc2a3f6c0fb14e4e99c54177 https://github.com/wrmsr/dotfiles/commit/a6597efe0421b6b0cc2...
jandrusk 10y ago
Encryption, do you speak it?
equalarrow 10y ago
Not only passwords, but api keys as well. I can't tell you how many times I've come across public repos that have full api credentials in them. Boggles the mind..
deleted 10y ago
[deleted]
hatsunearu 10y ago
some random guy spammed a ton of commits with a bitcoin address saying "please send me money" jesus christ, how low can you stoop
ceautery 10y ago
After this was posted, there has been some serious trolling in Github with "fake" commits matching this search.
level 10y ago
This is pretty much how I found a couple exposed Stripe API keys. You just need to look through code of people who use the example implementation, and then dig in the history/config a bit. If you send stripe a key or two, they'll give you a free shirt. https://adamlaycock.ca/blog/2016/05/23/Stop-Posting-Keys.html https://adamlaycock.ca/blog/2016/05/23/Stop-Posting-Keys.htm...
asc123 10y ago
use quotes. only about 19k
jgritty 10y ago
And now I got goatse'd, thanks Hacker News, lol.
nkkollaw 10y ago
Looks like a lot of people read Hacker News... https://github.com/doutchnugget/awesomevim/commit/a7292962ce6376968e5096c4abef8b74bfaabe06 https://github.com/doutchnugget/awesomevim/commit/a7292962ce...
kh_hk 10y ago
Seems this goes back to 1989 :) https://github.com/weiss/original-bsd/commit/0e1066151c90a8089c88365f3328934a588451a3 https://github.com/weiss/original-bsd/commit/0e1066151c90a80...
resalisbury 10y ago
look at these morons: https://github.com/checkr/supersecret/commit/6b9cdf3660843180ace92a62cd6d0b828fc73ede https://github.com/checkr/supersecret/commit/6b9cdf366084318...
teaearlgraycold 10y ago
I set up a honeypot and made this commit: https://github.com/teaearlgraycold/honey/commit/7c4289717979bf675862ad43a6f3da46969c7481 https://github.com/teaearlgraycold/honey/commit/7c4289717979... Already had a couple of sassy individuals telling me my honeypot is shit via the tty logging.
- red0point 10y ago
  Fell for it, this is the first time I connected to a honeypot (or so I think). I especially liked the part where you type 'exit' and it just keeps you connected but the command line changed to 'root@localhost' at the beginning. Had a good laugh there :) What software are you using?
  - teaearlgraycold 10y ago
    It's running kippo https://github.com/desaster/kippo https://github.com/desaster/kippo
cybergrime 10y ago
There are tools that automatically rewrite your git history and can fix this.
brockvond 10y ago
can someone please give me an ELI5 breakdown of what I'm missing... did these people attempt to change their password via git commits?
mickael-kerjean 10y ago
GitHub has become the best place to find all sort of sensitive information. From root password, access to companies network, Api keys, everything is available from a search box, you don't need to be a genius to do serious damage, spying or doing all sort of black hat stuff. Sure people should clean up their work, but as a fact not everybody does and it won't change tomorrow. You'll simply hear on the news: some Russian hacker are behind the attack or another bad excuse
lucianosousa 10y ago
git commit --amend just cleanup all the mess. also, better to change the pushed one

861 points by rsc-dev 10y ago

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.

starefossen 10y ago

Or try "remove aws"

Cthulhu_ 10y ago
I tried "fuck", but it's nowhere near as prevalent as "remove password"
- jcastelein 10y ago
  Give "oops" a try
  - karrotwaltz 10y ago
    "stuff" isn't far behind
    - timborden 10y ago
      Always been a fan of "fix" ...LOL
      - prodigal_erik 10y ago
        Fixed? At least "wip" for "work in progress" doesn't raise your expectations too much.

ioquatix 10y ago

Git-crypt is your friend!

nickik 10y ago
Cool. I did no know this existed. I did not know that I wanted it. Now I want it.
dorianm 10y ago
Then .gitignore and .env are your best friends :)
- ioquatix 10y ago
  git-crypt suits a significantly larger set of use cases such as storing private keys, etc.

deleted 10y ago

[deleted]

dorianm 10y ago

Right after my "remove secrets" post: https://news.ycombinator.com/item?id=13650614 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.

shawabawa3 10y ago
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
- dorianm 10y ago
  1) Search for common pattern where the key can be stored 2) Search if found keys are actual valid keys 3) Expire key, send explanatory email, issue new key (I think that's what AWS does)
- Flimm 10y ago
  Heroku's official Python template include `.env` in the repo: https://github.com/heroku/python-getting-started https://github.com/heroku/python-getting-started https://github.com/heroku/heroku-django-template https://github.com/heroku/heroku-django-template (Although, to be fair, they do include `.env` in the `.gitignore` file.)
- _pctq 10y ago
  And this would be a cool feature from github too. A link mentioning "we found something in your code that looks like a secret, please know people will use it."
  - Klathmon 10y ago
    They do this for all of their own API keys already. They not only notify you but instantly invalidate a key pushed to a public repo. Annoyingly there is no way to turn it off even when you explicitly want to share an API key knowingly. But i'm more than fine with needing to "obfuscate" an API key or manage secrets correctly knowing it saves TONS of people.

karrotwaltz 10y ago

Related topic: "Production AWS keys on GitHub" ~ 3 years ago https://news.ycombinator.com/item?id=7411927 https://news.ycombinator.com/item?id=7411927 By just looking quickly, it seems that you can still find many recent live keys...

dorianm 10y ago
Amazon scans GitHub and revokes valid keys (can't find source, but proof is that it's been a while no AWS keys were stolen from GitHub)
- tinco 10y ago
  I have it on good authority ( >_> ) that this is indeed true.
- dotancohen 10y ago
  I'm embarrassed to say that it's happened to me. I deliberately created an IAM user that was 'public', for purposes of the application. Amazon shut down that user and everything (not much) that it had access to. This was in 2014 or 2015.

jamesphillips 10y ago

Once it's on the internet. Sites like github have become an amazing OSINT tool.

lucideer 10y ago

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=searchresults&type=Code&utf8=%E2%9C%93 https://github.com/search?p=2&q=smtp.gmail.com+pass&ref=sear...

chillydawg 10y ago
Wow, that is scary.
AckSyn 10y ago
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.
- ProblemFactory 10y ago
  > the equivalent to the Post-IT on a monitor Writing passwords down on a piece of paper, and keeping that in your wallet or locked desk drawer is actually one of the more secure ways of storing passwords these days. No risk of electronic compromise, and its highly unlikely that people who would steal your wallet or break into your home are also interested in your online accounts.
  - deleted 10y ago
    [deleted]
  - patrick_haply 10y ago
    To be honest, and not that I ever would, but, if I stole your laptop, the moment I would become interested in your online accounts would be the moment I found your paper with all of your passwords on it.
  - puddintane 10y ago
    This still has many flaws. 1. New guy gets hired. 2.You work for a large corporation and we'll you can't say you can trust everyone there. 3. Small company of 10 (company I work at for example) could be compromised by the weekly janitor. 4. Someone could break in and make it look like a robbery all while stealing your critical infrastructure. I recently helped research a bit about internal security for our office and sticky notes are still a very common place for credentials to be compromised.

oelmekki 10y ago

The worst part in that is that it provides tons of passwords to analyze and detect recurring words or schemes. This probably also will hurt people that never commited their passwords in public repos. Github should probably filter out such searches.

raesene6 10y ago
I think the ship of "easily analzed password dumps" has already sailed e.g. https://xato.net/today-i-am-releasing-ten-million-passwords-b6278bbe7495#.1iy9voua1 https://xato.net/today-i-am-releasing-ten-million-passwords-... <-- 10 million passwords
- oelmekki 10y ago
  Yeah, indeed. I guess we can expect password schemes to change over time, so it's still a good idea to prevent it. Not sure in which proportion it helps, though.

sagivo 10y ago

git is a great tool, unfortunately there's no standard of storing sensitive info (like passwords). some store it as ENV variables, some hard copy the files to servers using custom scripts etc.. would love to see an easy tool that developers can use to manage this info like people manage files on git.

raesene6 10y ago

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...

c3833174 10y ago
Don't hardcode things, .gitignore your production config files, check in conf.example if needed.
Xylakant 10y ago
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.
- Klathmon 10y ago
  I've gone through the process of open-sourcing previously closed codebases, and in virtually all of them a decision is made to make a single "genesis" commit to start the public exposure because there's just not enough manpower (or I don't know git well enough) to go through and ensure there not only aren't any secrets now (meaning passwords, or info the company doesn't want to release), but also there weren't at any point in the past.
  - Vinkekatten 10y ago
    Genesis commit, that's a catchy name for it. We've done the same thing, after some discussion this always ends up making the most sense. Also, you can hide your crimes and not show off all your "TODO: put more stuff here" commits to the world.
    - deleted 10y ago

LeonidBugaev 10y ago

If you found a similar mistake in your repository, you can delete commit from history using: `git rebase --onto <commit-id>^ <commit-id>`. Or if you want actually rewrite it, see git rebase -i` documentation.

danieldk 10y ago
Doesn't that requires a force push? Force pushes are acceptable for private repositories with a single user, but typically not in larger projects. Just revoke the password/secret/whatever.
- adrianN 10y ago
  Or do both? Better safe than sorry.
  - jomkr 10y ago
    It's better to just revoke and not re-write git history in a public repository. Re-writing history is pointless after the credentials are revoked, and causes a headache to others using your repository.
- majewsky 10y ago
  I find force pushes acceptable for topic branches of public repos. In fact, I use them a lot to leave behind clean history. Same as with squash merges, which technically also lose history.
  - prodigal_erik 10y ago
    It's better to push a similar name and let people decide if and when to rebase --onto the new upstream. Squash merges are just bad. They destroy all the info that makes git handle branching and conflicts better than svn.
avip 10y ago
You'll have to revoke committed credentials regardless, as github is so frequently scrapped to find such content.

drinchev 10y ago

How do you guys, handle this problem? I use either `git-crypt` [1] or `ansible-vault` [2]. 1: https://github.com/AGWA/git-crypt https://github.com/AGWA/git-crypt 2: http://docs.ansible.com/ansible/playbooks_vault.html http://docs.ansible.com/ansible/playbooks_vault.html

FanaHOVA 10y ago
ENV variables. I use `dotenv` in Ruby projects.
StavrosK 10y ago
Yep, same here. I prefer git-crypt, but we use Ansible vault too.
tildedash 10y ago
I follow the 12 factor app methodology (https://12factor.net/ https://12factor.net/), everything in ENV.
reitanqild 10y ago
And it actually uses GPG : )
dekz 10y ago
.env or ENV with AWS KMS
adamors 10y ago
Dotenv and Ansible vault, depending on the project. I also want to look into Hashicorp's Vault https://www.vaultproject.io https://www.vaultproject.io
aequitas 10y ago
For puppet users: https://github.com/TomPoulton/hiera-eyaml https://github.com/TomPoulton/hiera-eyaml Advantage of this approach is it encrypts the values individually instead of per file. This way the secrets files are git/review friendly.

sirn 10y ago

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.

WildUtah 10y ago

When you put your dotfiles in a repository online, be sure to commit all the public keys and none of the private ones. Github, like SSH, uses an asymmetric authentication scheme. They even publish everyone's public keys. It's much more secure than passwords.

franzwong 10y ago

You'd better change the password instead of removing it.

djm_ 10y ago

A good a time as ever to mention AWS's provider-agnostic secrets-aware git hook that attempts to prevent this at the repository level [1] [1] https://github.com/awslabs/git-secrets https://github.com/awslabs/git-secrets

dpix 10y ago

This is the main reason I use gitlab, because they have free private repos. When your trying to smash out code as fast as possible in a startup you don't want to have to worry about acccidently checking a secret in

hasperdi 10y ago
Bitbucket is another alternative for free private repos.

chiefalchemist 10y ago

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.

KyeRussell 10y ago
I'd say that it's hard to implement this effectively. Maybe as a language / framework-specific hook.
s_kilk 10y ago
How would git know that it's a password/key/whatever?
- diesal11 10y ago
  just make it search for files or variable assignments named "password" or "secret". That will catch the majority. In comparison Gmail doesn't catch all cases either, if you say something like "here are" instead of I've attached it misses it.
- aaron695 10y ago
  Key is easy. The high entropy should tip you off. Passwords, look for variables with the name password, passwd assigned strings. Like Gmails attachment, it'll get stuff wrong, just make it easy to continue on.
  - tuxxy 10y ago
    This. However, it would only work with secure passwords. Setting the entropy count too low would result in a bunch of false positives.
- epalm 10y ago
  I believe Django's logging framework will automatically replace strings in your settings.py file (basically a dict) with '*' if the key "looks like" a secret (contains the word 'secret' or 'key' or 'passw' etc).

sparkslabs 10y ago

I'll raise you a handful more: add password / add passwords * https://github.com/search?utf8=%E2%9C%93&q=add+passwords&type=Commits&ref=searchresults https://github.com/search?utf8=%E2%9C%93&q=add+passwords&typ... * https://github.com/search?utf8=%E2%9C%93&q=add+password&type=Commits&ref=searchresults https://github.com/search?utf8=%E2%9C%93&q=add+password&type... add secret / add secrets * https://github.com/search?utf8=%E2%9C%93&q=add+secret&type=Commits&ref=searchresults https://github.com/search?utf8=%E2%9C%93&q=add+secret&type=C... * https://github.com/search?utf8=%E2%9C%93&q=add+secrets&type=Commits&ref=searchresults https://github.com/search?utf8=%E2%9C%93&q=add+secrets&type=...

beothorn 10y ago
Also: search for code making connections to db ruby https://github.com/search?q=DBI.connect&ref=searchresults&type=Code&utf8=%E2%9C%93 https://github.com/search?q=DBI.connect&ref=searchresults&ty... java https://github.com/search?p=2&q=DriverManager.getConnection%28&ref=searchresults&type=Code&utf8=%E2%9C%93 https://github.com/search?p=2&q=DriverManager.getConnection%... and so on...
hackerboos 10y ago
Some of these commits are PGP signed...
- pcr0 10y ago
  What do you mean by that? That people took the trouble to use PGP but then go and do something this silly?
  - TallGuyShort 10y ago
    It's a good reminder that the human is usually the weakest link.
  - hackerboos 10y ago
    Yes.

atti7 10y ago

reminds me of this: "I don`t know" https://github.com/search?p=1&q=+i+don`t+know&ref=searchresults&type=Commits&utf8= https://github.com/search?p=1&q=+i+don`t+know&ref=searchresu...

yread 10y ago
Heh the first result of this query has a password there as well https://github.com/budworth/cs313-php/commit/9113053776bb834261241474a8b97d5c7e1e49f6 https://github.com/budworth/cs313-php/commit/9113053776bb834...

sand500 10y ago

To people like me who have done this many times in the past and want to add the file to gitignore http://stackoverflow.com/questions/1139762/ignore-files-that-have-already-been-committed-to-a-git-repository http://stackoverflow.com/questions/1139762/ignore-files-that... The other alternative I can think of is to hide sensitive values in environment variables

jholman 10y ago
Careful. If you have already committed it, and you ever push the repo to a public GH repo, your key is compromised. Just because some benevolent slacker-attackers on HN aren't sniffing the PSHB event queue, doesn't mean no one is. If you ever send the secret to Github, criminals have it. If you ever committed it, and then you ever push, then you've sent it to GitHub. So yes, add the file to gitignore and git rm it, but also invalidate your keys and get new ones.

joshfarrant 10y ago

Throw the word 'oops' in for good measure. https://github.com/search?p=2&q=remove+password+oops&ref=searchresults&type=Commits&utf8=%E2%9C%93 https://github.com/search?p=2&q=remove+password+oops&ref=sea...

ryanmaynard 10y ago
I actually compiled a list of these from the last time this subject was mentioned on HN. http://gitoops.xyz/ http://gitoops.xyz/

random_upvoter 10y ago

Good thing all my commit messages are "xxx"

therealasdf 10y ago

For anyone wondering, if you want to remove a file or secret you've already committed, you can use BFG Repo-Cleaner to go through your commit history and completely remove any trace of it. https://rtyley.github.io/bfg-repo-cleaner/ https://rtyley.github.io/bfg-repo-cleaner/

nailer 10y ago
+1. Requires Java but BFG Repo Cleaner is the only app I've ever felt worth installing the JVM for.
- dvdgsng 10y ago
  That's a pretty useless comment, don't you think?
faitswulff 10y ago
Just note that if it's a public repo, it may not help you, due to attackers scraping Github's API and mirrors like GHTorrent. From "Why Deleting Sensitive Information from Github Doesn't Save You": http://jordan-wright.com/blog/2014/12/30/why-deleting-sensitive-information-from-github-doesnt-save-you/ http://jordan-wright.com/blog/2014/12/30/why-deleting-sensit... The top HN comment on the article details their experiences with getting hacked this way: https://news.ycombinator.com/item?id=8818035 https://news.ycombinator.com/item?id=8818035
- deleted 10y ago
  [deleted]
- Flammy 10y ago
  Warning - in the HN comment that is linked, don't click the link, is a browser popup spam which is actually hard to close (url has been dropped and picked up by a spammer?)
seanwilson 10y ago
Sounds like a better idea to just change the secret.

cultavix 10y ago

imagine private repo's :)

martincmartin 10y ago

Years ago, there were proggit posts of google searches for open myphpadmin consoles. I think people then went and deleted/messed with the databases. My search fu is failing me though, I can't find any of those threads.

hharnisch 10y ago

Thank you for highlighting this is a such a common mistake. I hope developers of all skill levels look at this and realize it how easy it is to make this mistake and learn from it.

_joel 10y ago

Another for the list, JSON or YAML containing 'password' - https://github.com/search?utf8=%E2%9C%93&q=password+extension%3Ayaml+extension%3Ayml+extension%3Ajson&type=Code&ref=advsearch&l=&l= https://github.com/search?utf8=%E2%9C%93&q=password+extensio... Reminds me of the eye opening experience available at https://www.exploit-db.com/google-hacking-database/ https://www.exploit-db.com/google-hacking-database/

empath75 10y ago

Rotate your keys and passwords in production, everyone.

josscrowcroft 10y ago

I liked this one: https://github.com/squared-one/omniauth-unsplash/commit/072bc946b5d069d0f30b32f8f3cc53d22abff36e 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!"

paulcole 10y ago
just growth hacking
olegkikin 10y ago
- protected $password = '12root34'; + protected $password = ''; "I'm a bit disappointed now that putting 'protected' in front of the password doesn't protect it ;)"
shitgoose 10y ago
free advertising. genius!
ag_47 10y ago
Another less 'relevant' result: - acceptHandshake = params.pass == PASSWORD + acceptHandshake = true//params.pass == PASSWORD
- purple-again 10y ago
  That just seems like a guy testing his authorization code. I would expect the next commit to put it back to its functional state.
  - ag_47 10y ago
    Like 'Revert "remove password"'? ;-)

EJTH 10y ago

Almost as many results on 'remove credentials' :-)

brightball 10y ago

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 10y ago
Well, we suppose that's a solution of some kind. How about never committing passwords and having passwords hardcoded in your codebase?
- brightball 10y ago
  Also that

westoque 10y ago

Good find. Reminds me of the a query done for Google Search that exposes sites vulnerable to SQL injection.

anacleto 10y ago

Holy shit!

androtheos 10y ago

Not nice

danarmak 10y ago

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.

kxait 10y ago

some of these seem legit

jakobov 10y ago

Someone here should make a bot and leave comments on all those commits warning people to change their passwords.

ssebastianj 10y ago

Maybe a confidential-linter or git pre-commit hook would be nice to prevent leaking confidential information.

burnbabyburn 10y ago

leaks of this types are known since AGES, and still people are unable to keep private things private.

bigtunacan 10y ago

This made me realize an unexpected (to me) search behavior on Github. Basic/Default search will search commit history, but if I try to add advanced options I don't appear to get search history. https://github.com/search?utf8=%E2%9C%93&q=remove+password+user%3Anicksagona&type=Repositories&ref=searchresults https://github.com/search?utf8=%E2%9C%93&q=remove+password+u... Here I was trying to search for "remove password" just on repos for nicksagona (just happened to be one of the first users to display when you go to this thread's search). That comes up with zero results. This leaves me wondering how I would run similar searches on repos that I'm involved with as a way of auditing to make sure none of them have compromised passwords that would need changed. I would love to hear suggestions on how to do this.

palerdot 10y ago

Just using a random commit name like 'minor bug fix', 'updated version' for these kind of commits will save a lot of headaches like this. One can do better by adding random lines/ logs in lot of files and sneakily remove password from one of them and then give a random commit name. But then it all boils down to your mindset at that particular moment when you are commuting.

jvehent 10y ago
> Just using a random commit name like 'minor bug fix', 'updated version' for these kind of commits will save a lot of headaches like this. Just change the leaked passwords, don't try to hide the commits.
- vidyesh 10y ago
  Precisely, just change the password/key and don't do anything at all. People might think you are stupid or think used random text, either way you are safe.
dbg31415 10y ago
Don't commit passwords. Put them in a config file and .gitignore it. You could upload an example file... but please don't put real passwords in the example file.
Xorlev 10y ago
Security by obscurity is no security at all. Revoke the creds and then either just remove them or run BFG as a secondary measure.

jvehent 10y ago

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.

Kunix 10y ago
Blackbox is one good way to store secrets: https://github.com/StackExchange/blackbox https://github.com/StackExchange/blackbox
libeclipse 10y ago
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.
- thecrazyone 10y ago
  Why would a webhook URL be a secret? Wouldn't it be more like internal API if anything? I would assume that the parameters sent to the webhook, an auth token or something of the sort would take care of the security bit. Obscuring the URL seems like security-by-obscurity no?
  - ksenzee 10y ago
    For purposes of security, there's no difference between example.com/api/my-webhook?auth-token=[some-uuid] and example.com/api/my-webhook/[some-uuid].
  - olalonde 10y ago
    Not if you treat the secret URL like a password. Plus, not all webhook callers allow you to authenticate them without supplying them a special URL.

joshuajeeson 10y ago

Another one: Search for Root password :D

wybiral 10y ago

A while ago I discovered similarly that there are several searches which lead you to active database logins. https://github.com/search?&q=mysqli_connect+http&type=Code https://github.com/search?&q=mysqli_connect+http&type=Code https://github.com/search?q="rds.amazonaws.com"&type=Code https://github.com/search?q="rds.amazonaws.com"&type=Code etc...

Keverw 10y ago
Wow. People would really store production passwords on GitHub for everyone to see? I wonder if GitHub blocked those searches "We could not perform this search Must include at least one user, organization, or repository" Edit: If I click on PHP for the language in the sidebar they show up. But hmm, I wonder if maybe GitHub tries to block leaks like that from being searched.
- wybiral 10y ago
  Yeah, I just started getting those too. But adding "&p=2" to the URL shows results for the next page... shrug
  - problems 10y ago
    You could probably also just use Google to find them with site:github.com.
    - wybiral 10y ago
      When I was a teenager I liked to use search engines to find PHP upload tests. People almost always served uploaded files from a directory and made no distinction between .jpg or .php files. (No, I didn't exploit this, I just enjoyed finding them)

tmsldd 10y ago

The question is: how many are left in the wild?

athenot 10y ago

Even more frightening: https://github.com/search?utf8=&q=id_rsa&type=Commits&ref=searchresults https://github.com/search?utf8=&q=id_rsa&type=Commits&ref=se...

mzzter 10y ago
Wow private keys just sitting in plain sight o.O
- ryanmaynard 10y ago
  From a former HN discussion http://gitoops.xyz/ http://gitoops.xyz/
deleted 10y ago
[deleted]

nico01f 10y ago

Wow!!! This could be a big thing. It's time to write: How to write code without expose you

mzzter 10y ago

I would recommend using torus.sh or other secret manager instead of an env or text file. I've forgotten to include them in .gitignore too many times.

thrillgore 10y ago

One of the things I've done after making this mistake was creating an example config file for this information, committing that, and then dropping a gitignore on the real config file.

adamvalve 10y ago

This one seems to be a winner: https://github.com/wrmsr/dotfiles/commit/a6597efe0421b6b0cc2a3f6c0fb14e4e99c54177 https://github.com/wrmsr/dotfiles/commit/a6597efe0421b6b0cc2...

jandrusk 10y ago

Encryption, do you speak it?

equalarrow 10y ago

Not only passwords, but api keys as well. I can't tell you how many times I've come across public repos that have full api credentials in them. Boggles the mind..

deleted 10y ago

[deleted]

hatsunearu 10y ago

some random guy spammed a ton of commits with a bitcoin address saying "please send me money" jesus christ, how low can you stoop

ceautery 10y ago

After this was posted, there has been some serious trolling in Github with "fake" commits matching this search.

level 10y ago

This is pretty much how I found a couple exposed Stripe API keys. You just need to look through code of people who use the example implementation, and then dig in the history/config a bit. If you send stripe a key or two, they'll give you a free shirt. https://adamlaycock.ca/blog/2016/05/23/Stop-Posting-Keys.html https://adamlaycock.ca/blog/2016/05/23/Stop-Posting-Keys.htm...

asc123 10y ago

use quotes. only about 19k

jgritty 10y ago

And now I got goatse'd, thanks Hacker News, lol.

nkkollaw 10y ago

Looks like a lot of people read Hacker News... https://github.com/doutchnugget/awesomevim/commit/a7292962ce6376968e5096c4abef8b74bfaabe06 https://github.com/doutchnugget/awesomevim/commit/a7292962ce...

kh_hk 10y ago

Seems this goes back to 1989 :) https://github.com/weiss/original-bsd/commit/0e1066151c90a8089c88365f3328934a588451a3 https://github.com/weiss/original-bsd/commit/0e1066151c90a80...

resalisbury 10y ago

look at these morons: https://github.com/checkr/supersecret/commit/6b9cdf3660843180ace92a62cd6d0b828fc73ede https://github.com/checkr/supersecret/commit/6b9cdf366084318...

teaearlgraycold 10y ago

I set up a honeypot and made this commit: https://github.com/teaearlgraycold/honey/commit/7c4289717979bf675862ad43a6f3da46969c7481 https://github.com/teaearlgraycold/honey/commit/7c4289717979... Already had a couple of sassy individuals telling me my honeypot is shit via the tty logging.

red0point 10y ago
Fell for it, this is the first time I connected to a honeypot (or so I think). I especially liked the part where you type 'exit' and it just keeps you connected but the command line changed to 'root@localhost' at the beginning. Had a good laugh there :) What software are you using?
- teaearlgraycold 10y ago
  It's running kippo https://github.com/desaster/kippo https://github.com/desaster/kippo

cybergrime 10y ago

There are tools that automatically rewrite your git history and can fix this.

brockvond 10y ago

can someone please give me an ELI5 breakdown of what I'm missing... did these people attempt to change their password via git commits?

mickael-kerjean 10y ago

GitHub has become the best place to find all sort of sensitive information. From root password, access to companies network, Api keys, everything is available from a search box, you don't need to be a genius to do serious damage, spying or doing all sort of black hat stuff. Sure people should clean up their work, but as a fact not everybody does and it won't change tomorrow. You'll simply hear on the news: some Russian hacker are behind the attack or another bad excuse

lucianosousa 10y ago

git commit --amend just cleanup all the mess. also, better to change the pushed one