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

181–190 of 266 posts

Re: GitHub commit search: “remove password”

#181

Post by dsp1234 »

libeclipse wrote: post #145
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.

Whoa, that's actually amazing. Wonder how they got alerted and reacted so fast.

Github provides a public firehose for events[0]. So it's possible to hook a process to read from the firehose, and look for commit events and then match file contents against the list of API keys.

[0] - https://developer.github.com/v3/activity/events/

Re: GitHub commit search: “remove password”

#183

Post by lloydde »

chmike wrote: post #156
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…

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.

Or environmental variables loaded at provisioning though this just moves the target. But these options do not themselves have the "in motion" characteristics that provide the best reliability, scalability and security.

If your needs are more sophisticated this means keyservers where hardware security module (HSM) might by part of the equation.

Re: GitHub commit search: “remove password”

#184

Post by the_af »

chmike wrote: post #156
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…

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?

Re: GitHub commit search: “remove password”

#187

Post by okreallywtf »

chmike wrote: post #156
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…

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.

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.

Re: GitHub commit search: “remove password”

#188

Post by teaearlgraycold »

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.

Someone should create an app where you select an API service and it gives you a key that's been pushed to a public GitHub repo.

Re: GitHub commit search: “remove password”

#190

Post by joseph »

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?

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 you can use something like Hashicorp Vault, though it requires setting up servers for that purpose.

Once you've decided on one of these tools, it's no problem to script the retrieval of a secret into your deployment mechanism. It will work fine for autoscaling or any other unattended deployment.

Post reply on HN