Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub commit search: “remove password”

github.com

Post reply on HN
Print view View original

251–260 of 266 posts

Re: GitHub commit search: “remove password”

#251

Post by hartleybrody »

dorianm wrote: post #7

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.

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.

Re: GitHub commit search: “remove password”

#252

Post by ComputerGuru »

Nahjil567 wrote: post #237
ComputerGuru wrote: post #209

Earlier quoted context omitted.

Shamless plug: SecureStore, our .NET secrets manager: https://neosmart.net/blog/2017/securestore-a-net-secrets-man... I'm drafting a writeup and will post it to HN when that's ready. Other secrets managers I've seen posted to HN seem far too overcomplicated, at least for our company's needs. This is a step up from reading secrets from a plain text file, but not so complicated that you need a separate docker image run…

What hashing algorithms are you using? Are you updating that hashing algorithms as cipher-suites are being broken? Are we as a user required to set a random seed? Just because it is encrypted doesn't mean it is impossible to decrypt. Especially if default settings in the hash are being used and someone uses a poor password found in another breach. Its a great idea, but I would still worry about security issues around…

High level APIs are used for all crypto. The user does not have to generate their own seed. You can use your own key file or stretch a secret phrase once to create one with the library. Passwords are otherwise not hashed, only encrypted.

Re: GitHub commit search: “remove password”

#253

Post by 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

Re: GitHub commit search: “remove password”

#254

Post by raesene6 »

Xylakant wrote: post #207
raesene6 wrote: post #50

Earlier quoted context omitted.

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.

> 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 th…

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.

Re: GitHub commit search: “remove password”

#255

Post by muyuu »

jvehent wrote: post #136

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

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.

Re: GitHub commit search: “remove password”

#256

Post by matt_kantor »

shimo5037 wrote: post #176
chmike wrote: post #156

Earlier quoted context omitted.

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.

It can be slightly more complex than that if you use a package manager to publish your work. I once accidentally leaked a password due to having both a .gitignore and an .npmignore, and forgetting to include my .env file in the latter. Fortunately, I realized what had happened almost immediately and was able to change the password. Now I tend to `tar tf` everything before publishing.

Because of issues like this I tend to set up my deploy scripts to first `git clone` into a temporary directory, then do the rest of the work from there.

Re: GitHub commit search: “remove password”

#257

Post by teaearlgraycold »

red0point wrote: post #246
teaearlgraycold wrote: post #245

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

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?

It's running kippo

https://github.com/desaster/kippo

Re: GitHub commit search: “remove password”

#258

Post by chiefalchemist »

wongarsu wrote: post #70
chiefalchemist wrote: post #53

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.

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) us…

Exactly! So we agree that Git - as it is today - is not up to the task(s)? :)

That's all I'm trying to say

We keep expecting a cat to bark, and then we're shocked and disappointed that it doesn't. So let's stop asking and find / build a better tool.

Re: GitHub commit search: “remove password”

#259

Post by chiefalchemist »

Latty wrote: post #61
chiefalchemist wrote: post #53

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.

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.

Regardless. The broader point is, Git is a screwdriver and what is needed at this point is a hammer. Sure, we can keep trying to pound nails with a screwdriver but that's harder work and is far less productive.

We. Need. A. New. Tool.

p.s. But there are how many CSS pre-processors? And how many JS frameworks? Etc. Things we don't need. Go figure.

Re: GitHub commit search: “remove password”

#260

Post by chiefalchemist »

s_kilk wrote: post #57
chiefalchemist wrote: post #53

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.

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

What would I do? I'd take ALL those incidents on GitHub and I'd run them thru some sort of AI pattern recognition algorithm. That would become my identification "engine" (?).

It might not catch everything all the time - since humans are pretty creative when it comes to fucking things up - but I bet it would be pretty effective. Certainly more effective than what we have now. Then if it can keep learning going forward, all the better, eh.

Post reply on HN