
GitHub commit search: “remove password” - rsc-dev
https://github.com/search?utf8=%E2%9C%93&q=remove+password&type=Commits&ref=searchresults
======
jvehent
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
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.

~~~
okreallywtf
I think its as important to make it "hard to do the wrong thing" as "easy to
do the right thing". In this case having to explicitly exclude a file
containing passwords from being deployed would fail that rule of thumb.

The Azure Key Vault is a good solution that so far seems easy to work with
(I've only just started using it though) and it can make the storage of
secrets easier to secure but you still have the issue of storing the
credentials to the key vault, so its difficult to fully get rid of the problem
although you can definitely isolate access to your passwords that way and then
have a more limited number of credentials to secure.

~~~
corndoge
Somehow I doubt Azure Key Vault is easier than a gitignore line and a text
file

~~~
bluebeard
.gitignore is easy but the pw is still naked. Probably a good practice to hash
it.

~~~
slrz
Probably not as the result would be useless for authenticating against another
service.

------
josscrowcroft
I liked this one:

[https://github.com/squared-one/omniauth-
unsplash/commit/072b...](https://github.com/squared-one/omniauth-
unsplash/commit/072bc946b5d069d0f30b32f8f3cc53d22abff36e)

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

~~~
ag_47
Another less 'relevant' result:

    
    
      -    acceptHandshake = params.pass == PASSWORD
      +    acceptHandshake = true//params.pass == PASSWORD

~~~
purple-again
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
Like 'Revert "remove password"'? ;-)

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

~~~
lutefisk
At my work one of my coworkers accidentally put a secret token in a GitHub
issue. Couple hours later he got an email from the sysadmin at the parent
company saying his token finding script went off. He probably wouldn't have
noticed for a long while if that script wasn't running.

~~~
manarth
Wouldn't the token-finding script be even more of a risk?

If the token is XYZ and the script is searching
[https://github.com/search?utf8=%E2%9C%93&q=XYZ&type=Commits&...](https://github.com/search?utf8=%E2%9C%93&q=XYZ&type=Commits&ref=searchresults):

1\. It's sharing the token with GitHub.

2\. It's embedding the token as query-string parameter in a GET request, which
is much more likely to be logged (than sending it as data in a POST request),
and more likely to be available to less-privileged/less-trusted staff.

3\. If the request is sent to a non-HTTPS endpoint, the query can be MITMd,
revealing the token.

I'd be very wary of setting up a token-finding script, it feels like it adds
more risk than it saves.

~~~
obsurveyor
You can scrape the issues without exposing the token. You could probably do it
by just subscribing to all of them and parsing emails. No one(especially in
security) should be using a third party search to match sensitive data. It's
like searching Google for your social security number.

------
therealasdf
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/)

~~~
seanwilson
Sounds like a better idea to just change the secret.

~~~
tcfunk
Why not both? :)

~~~
tonybaroneee
That's time you could be spending on adding a new feature or fixing a bug :)
Just change the secret and be done with it!

~~~
scaryclam
And when someone new thinks "that password's wrong, it'll update it!"? Do
both, gets rid of the issue on both sides and really doesn't take long :)

~~~
gkya
Why would they if the tip does not have any passwords in it? It's not like a
potential contributor will search the commit log to see if there were once
passwords around. Besides, making such changes in public changesets is rude,
to say the least.

~~~
scaryclam
What I mean is, lots of folks seem to be saying to ignore the presence of the
file and just change the password where it's used.

Removing the file, or the password and adding a comment, _as well as_ changing
the password where it's used is much less likely to end up with a re-added
password later.

Of course, removing the file, adding it to .gitignore and changing the
password makes it even harder as a contributor would have to work to add the
password back, which is even less likely to happen.

~~~
gkya
Oh sorry I tought you were saying to remove it from VCS history (as said many
times in the thread). I totally agree you.

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

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

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

------
sparkslabs
I'll raise you a handful more:

add password / add passwords

* [https://github.com/search?utf8=%E2%9C%93&q=add+passwords&typ...](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+password&type...](https://github.com/search?utf8=%E2%9C%93&q=add+password&type=Commits&ref=searchresults)

add secret / add secrets

* [https://github.com/search?utf8=%E2%9C%93&q=add+secret&type=C...](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+secrets&type=...](https://github.com/search?utf8=%E2%9C%93&q=add+secrets&type=Commits&ref=searchresults)

~~~
hackerboos
Some of these commits are PGP signed...

~~~
pcr0
What do you mean by that?

That people took the trouble to use PGP but then go and do something this
silly?

~~~
TallGuyShort
It's a good reminder that the human is usually the weakest link.

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

~~~
s_kilk
How would git know that it's a password/key/whatever?

~~~
aaron695
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
This. However, it would only work with secure passwords. Setting the entropy
count too low would result in a bunch of false positives.

------
djm_
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)

------
joshfarrant
Throw the word 'oops' in for good measure.

[https://github.com/search?p=2&q=remove+password+oops&ref=sea...](https://github.com/search?p=2&q=remove+password+oops&ref=searchresults&type=Commits&utf8=%E2%9C%93)

~~~
ryanmaynard
I actually compiled a list of these from the last time this subject was
mentioned on HN. [http://gitoops.xyz/](http://gitoops.xyz/)

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

~~~
raesene6
Sure there's always a cost / benefit balance to take into account.

That said I'd say putting secrets in a git repo is a pretty risky thing to do.
By the nature of the tool that means that the secret ends up on the device(s)
of every developer who checks out the codebase, so the security of the secrets
is equal to the security of the worst secured device in question.

~~~
Xylakant
> That said I'd say putting secrets in a git repo is a pretty risky thing to
> do

Storing and keeping secrets is a pretty risky thing in general. Think: small
team, small app, everybody has the secrets anyways for deployment purposes.
Sure, setting up vault is superior - but how much effort does that cost that
could be invested in a better solution. Or a puppet repo that you use to
provision your machines, shared in the ops team: small team, everbody has root
- on each machine there might be an ssh key that gives away all your secrets.
So better invest in solid FDE and maybe tie that to a TF device, a yubikey
that is required to decrypt the disk etc. Not perfect by all means, but
there's limited time to go around and you really should think about what
threats you want/can defend against. (for example, for most projects, I'm not
wasting any thought about defenses against a nation state actor, that's a
threat that I won't be able to meaningfully counter anyways).

~~~
raesene6
FDE's and Yubikeys are nice and good controls for some classes of risk, but
distributing your passwords onto dev laptops via a git repo. opens you up to a
wide range of risks that those won't help you with.

Unless you got super-corporate lockdown with the end point devices you have
risks like "A user with access to the repo. installs software which turns out
to be malware", "A user with access to the repo. leaves their laptop in a
coffee shop unlocked", "A user with access to the repo. puts it on a USB key
and loses the key". None of these are nation state level concerns, they're
things that could impact the project purely by accident, or at the hands of
low-skill attackers

The point is once you've allowed secrets to be in a distributed system like
this you have very little control over what happens to them, which is why I'd
recommend using a secrets management system where there's more control (e.g.
vault from hashicorp) in almost all circumstances.

------
wybiral
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
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
Yeah, I just started getting those too. But adding "&p=2" to the URL shows
results for the next page...

 _shrug_

~~~
problems
You could probably also just use Google to find them with site:github.com.

~~~
wybiral
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)

------
sand500
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...](http://stackoverflow.com/questions/1139762/ignore-files-that-have-
already-been-committed-to-a-git-repository)

The other alternative I can think of is to hide sensitive values in
environment variables

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

------
athenot
Even more frightening:

[https://github.com/search?utf8=&q=id_rsa&type=Commits&ref=se...](https://github.com/search?utf8=&q=id_rsa&type=Commits&ref=searchresults)

~~~
mzzter
Wow private keys just sitting in plain sight o.O

~~~
ryanmaynard
From a former HN discussion [http://gitoops.xyz/](http://gitoops.xyz/)

------
kh_hk
Seems this goes back to 1989 :)

[https://github.com/weiss/original-
bsd/commit/0e1066151c90a80...](https://github.com/weiss/original-
bsd/commit/0e1066151c90a8089c88365f3328934a588451a3)

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

------
karrotwaltz
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
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
I have it on good authority ( >_> ) that this is indeed true.

------
adamvalve
This one seems to be a winner:

[https://github.com/wrmsr/dotfiles/commit/a6597efe0421b6b0cc2...](https://github.com/wrmsr/dotfiles/commit/a6597efe0421b6b0cc2a3f6c0fb14e4e99c54177)

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

~~~
brightball
Also that

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

------
_joel
Another for the list, JSON or YAML containing 'password' \-
[https://github.com/search?utf8=%E2%9C%93&q=password+extensio...](https://github.com/search?utf8=%E2%9C%93&q=password+extension%3Ayaml+extension%3Ayml+extension%3Ajson&type=Code&ref=advsearch&l=&l=)

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/)

------
teaearlgraycold
I set up a honeypot and made this commit:
[https://github.com/teaearlgraycold/honey/commit/7c4289717979...](https://github.com/teaearlgraycold/honey/commit/7c4289717979bf675862ad43a6f3da46969c7481)

Already had a couple of sassy individuals telling me my honeypot is shit via
the tty logging.

~~~
red0point
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
It's running kippo

[https://github.com/desaster/kippo](https://github.com/desaster/kippo)

------
drinchev
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)

~~~
tildedash
I follow the 12 factor app methodology
([https://12factor.net/](https://12factor.net/)), everything in ENV.

------
bigtunacan
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+u...](https://github.com/search?utf8=%E2%9C%93&q=remove+password+user%3Anicksagona&type=Repositories&ref=searchresults)

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.

------
random_upvoter
Good thing all my commit messages are "xxx"

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

~~~
Xylakant
A single person who checked out your repo before the force push will still
have the credentials. Once this has been pushed to a public repo, assume that
the credentials are burned and revoke them.

~~~
Piskvorrr
Indeed; but these actions _complement_ each other.

~~~
Xylakant
if you revoke the credentials, removing them from the git history serves no
purpose but disrupts everybody that has a clone of the repo. So you're doing
harm for little benefit other than covering up the incident. A net loss, if
you ask me.

~~~
Mithaldu
It serves the purpose of removing a hint on your password patterns from public
availability.

E: Oh, and just to preempt this, even saying "i use only random passwords with
no pattern" is useful information, as is having a ballpark password length.

~~~
thenickdude
Don't have password patterns, problem solved. Knowing that my password is 20
random characters of all possible symbols will not reduce your search space by
any significant amount.

~~~
Mithaldu
Still useful, means there's no point in checking any < 20, which halves the
search space. Or, on the outside, can be useful to abort any attempts at
bruteforce by way of cost evaluation and move on to another target.

~~~
OJFord
My goal when choosing a password (generator) typically isn't "what will tie up
an adversary for the longest, preventing them from moving on to attack someone
else".

Call me selfish, but if my password is known to be too tough to bother, so Eve
moves on to someone else's weak password, great.

~~~
Mithaldu
If you know your password is too tough to bother, then having people bash away
at it is no cost to to, and benefit to everyone else.

------
dpix
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
Bitbucket is another alternative for free private repos.

------
mickael-kerjean
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

------
level
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.htm...](https://adamlaycock.ca/blog/2016/05/23/Stop-Posting-Keys.html)

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

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

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

------
ioquatix
Git-crypt is your friend!

~~~
dorianm
Then .gitignore and .env are your best friends :)

~~~
ioquatix
git-crypt suits a significantly larger set of use cases such as storing
private keys, etc.

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

------
nkkollaw
Looks like a lot of people read Hacker News...
[https://github.com/doutchnugget/awesomevim/commit/a7292962ce...](https://github.com/doutchnugget/awesomevim/commit/a7292962ce6376968e5096c4abef8b74bfaabe06)

------
oelmekki
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
I think the ship of "easily analzed password dumps" has already sailed e.g.
[https://xato.net/today-i-am-releasing-ten-million-
passwords-...](https://xato.net/today-i-am-releasing-ten-million-
passwords-b6278bbe7495#.1iy9voua1) <\-- 10 million passwords

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

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

------
starefossen
Or try "remove aws"

~~~
Cthulhu_
I tried "fuck", but it's nowhere near as prevalent as "remove password"

~~~
jcastelein
Give "oops" a try

~~~
karrotwaltz
"stuff" isn't far behind

~~~
timborden
Always been a fan of "fix" ...LOL

~~~
prodigal_erik
Fixed? At least "wip" for "work in progress" doesn't raise your expectations
too much.

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

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

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

------
hatsunearu
some random guy spammed a ton of commits with a bitcoin address saying "please
send me money"

jesus christ, how low can you stoop

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

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

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

~~~
yread
Heh the first result of this query has a password there as well
[https://github.com/budworth/cs313-php/commit/9113053776bb834...](https://github.com/budworth/cs313-php/commit/9113053776bb834261241474a8b97d5c7e1e49f6)

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

------
resalisbury
look at these morons:

[https://github.com/checkr/supersecret/commit/6b9cdf366084318...](https://github.com/checkr/supersecret/commit/6b9cdf3660843180ace92a62cd6d0b828fc73ede)

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

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

------
empath75
Rotate your keys and passwords in production, everyone.

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

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

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

------
joshuajeeson
Another one: Search for Root password :D

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

------
nico01f
Wow!!!

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

------
anacleto
Holy shit!

------
asc123
use quotes. only about 19k

------
kxait
some of these seem legit

------
jandrusk
Encryption, do you speak it?

------
cultavix
imagine private repo's :)

------
androtheos
Not nice

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

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

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

