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

211–220 of 266 posts

Re: GitHub commit search: “remove password”

#211

Post by javajosh »

ComputerGuru wrote: post #209
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.

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…

I think you need to add a sentence giving one good reason to use anything other than a plain text file.

Re: GitHub commit search: “remove password”

#212

Post by cs2818 »

unethical_ban wrote: post #194
lucideer wrote: post #13

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

META I notice in many instances Github showing an error. We could not perform this search: Must include at least one user, organization, or repository But if you change anything in the URL, it works again. Such as adding &p=2, which lucideer tried. But I got the error on his link. So I changed it to p=3, and it worked. So I'm guessing Github has an autodetection for a particular global code search getting high hits (…

Wow very interesting indeed, same behavior for me. Definitely makes me curious about the implementation details of Github's search feature.

Re: GitHub commit search: “remove password”

#213

Post by acejam »

joseph wrote: post #202
grogenaut wrote: post #198

Earlier quoted context omitted.

Kms doesn't have a size limit if used right. You should use kms to store a key and store the data on s3 encrypted.

Sure, which is why I said to use e.g. credstash in such cases. It stores the secrets in DynamoDB while using KMS to handle the keys. I guess you are talking about using S3 server side encryption, which is another approach.

+1 Upvote for credstash

Re: GitHub commit search: “remove password”

#214

Post by pyre »

stephenr wrote: post #193
plasticbugs wrote: post #142

Earlier quoted context omitted.

I once pushed my Amazon S3 key to GitHub accidentally. Realized instantly what I'd done, and while in the process of feverishly regenerating a new key, my cell phone rings. It's Amazon telling me I pushed my S3 key to GH.

You pushed your secret key, and they recognised it? Does that imply that they are not hashing secret keys, or did you also push the account key (allowing for a single auth test on their side)?

It's also possible that they just scrape the Github firehose for common patterns like

  AWS_SECRET_KEY="FOOBAR"
and send a message to the committer's email (since you presumably used a correct/valid email in the git commit).

Re: GitHub commit search: “remove password”

#215

Post by ComputerGuru »

javajosh wrote: post #211
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…

I think you need to add a sentence giving one good reason to use anything other than a plain text file.

Thanks, good idea.

I just did, though I may have gone overboard as it is more of a paragraph than a sentence. We developed SecureStore out of necessity, believe me, KISS all the way.

Re: GitHub commit search: “remove password”

#216

Post by jfroma »

plasticbugs wrote: post #142
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.

I once pushed my Amazon S3 key to GitHub accidentally. Realized instantly what I'd done, and while in the process of feverishly regenerating a new key, my cell phone rings. It's Amazon telling me I pushed my S3 key to GH.

It happens to us as well.

The interesting thing is that there is also an evil crawler that will automatically launch thousands of windows vms to mine bitcoins (that's all they do). Amazon told us that we have leaked our account id and secret but also they notice the other crawler has launched a lot of VMs and they did a refund to us. yes, we love amazon.

Lesson learned: you never put the account id and secret in your code, not only that you should not hardcode it, but there is no need to even read that from the environment etc.

Don't do something like this `new S3({accountKey: ..., accountSecret: ..}` instead you do `new S3()` and that's it. Every AWS SDKS is smart enough to find the keys in the environment following a series of steps:

- environment variables

- ~/.aws/credentials

- and when your code is run on ec2, lambda, etc. you should use IAM Roles.

So, in addition to not hardcoding an AWS secret, your code should not even pass the secret to the SDK.

Consider also enabling CloudTrail and have alerts on that.

There is also a way to not have ~/.aws/credentials in your machine and have another thing that requires MFA. I am not familiar how this work yet but we started to use it.

Re: GitHub commit search: “remove password”

#217

Post by ComputerGuru »

the_af wrote: post #184
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.

Agreed that you absolutely cannot store sensitive passwords in your source code repo. Your proposed solution, however, has its own share of problems for some deployment scenarios. Where do you get this file from? Assuming you are meant to place it by hand each time you deploy your application... what about autoscaling? What if you want unattended deployment of apps?

You totally can store sensitive passwords in your source code repo, just so long as they're encrypted. Here's how we do it: https://neosmart.net/blog/2017/securestore-a-net-secrets-man...

SecureStore is designed to be repo-friendly, it purposely avoids needless IV/payload regeneration, is based in plain text, and preserves element order to avoid driving source code managers crazy.

Re: GitHub commit search: “remove password”

#218

Post by thecrazyone »

libeclipse wrote: post #144
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…

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.

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?

Re: GitHub commit search: “remove password”

#219

Post by the_af »

joseph wrote: post #190
the_af wrote: post #184

Earlier quoted context omitted.

Agreed that you absolutely cannot store sensitive passwords in your source code repo. Your proposed solution, however, has its own share of problems for some deployment scenarios. Where do you get this file from? Assuming you are meant to place it by hand each time you deploy your application... what about autoscaling? What if you want unattended deployment of apps?

There are lots of ways to handle those scenarios. Deciding where to store your secrets is extra easy if you're in the cloud. In AWS you can use KMS to store it if it's 4kb or less. A cli command or API call can decrypt it for you. If it's larger, you can use a tool such as credstash which lets KMS manage the keys. If you're in an environment that's using Chef, it can handle them. Ansible has a solution as well. Or yo…

Oh, yes, I didn't mean there wasn't a solution. We use Hashicorp Vault, for example. I simply meant that "store passwords in a file" (as mentioned in the post I replied to) is too simplistic to cover all scenarios.

Re: GitHub commit search: “remove password”

#220

Post by Flammy »

faitswulff wrote: post #91
therealasdf wrote: post #87

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/

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-sensit... The top HN comment on the article details their experiences with getting hacked this way: https://news.ycombinator.com/item?id=8818035

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?)
Post reply on HN