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

71–80 of 266 posts

Re: GitHub commit search: “remove password”

#71

Post by thenickdude »

Mithaldu wrote: post #66
Xylakant wrote: post #44

Earlier quoted context omitted.

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.

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.

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.

Re: GitHub commit search: “remove password”

#72

Post by thegeomaster »

Xylakant wrote: post #40
LeonidBugaev wrote: post #23

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

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.

I can think of a legitimate use case for that: cleaning up a that's about to be opened to the public (so no one who shouldn't have access to sensitive info has checked it out yet).

Re: GitHub commit search: “remove password”

#74

Post by Klathmon »

chimeracoder wrote: post #60
Klathmon wrote: post #46

Earlier quoted context omitted.

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.

Why would you ever want to share a valid Github API key publicly?

It's been a while, but IIRC it was a key with no permissions used on a CI server to get around github's API usage limits.

It probably wasn't the best idea, but it was the only "secret" needed in the whole project and I didn't want to maintain a way of managing secrets in a public project for a pointless key.

In the end I did just that, and looking back it was the better choice, but at the time it was annoying.

Re: GitHub commit search: “remove password”

#75

Post by Mithaldu »

thenickdude wrote: post #71
Mithaldu wrote: post #66

Earlier quoted context omitted.

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.

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.

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.

Re: GitHub commit search: “remove password”

#76

Post by falsedan »

Piskvorrr wrote: post #43
Xylakant wrote: post #40

Earlier quoted context omitted.

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.

Indeed; but these actions complement each other.

Too little, too late. Plenty of people watch the stream of recent commits to github, and can snatch an API key as soon as it's pushed. Removing the compromised, revoked key from your git history is like making sure your front door is closed properly after coming home to find you've been burgled.

Re: GitHub commit search: “remove password”

#77

Post by [deleted] »

Vinkekatten wrote: post #59
Klathmon wrote: post #47

Earlier quoted context omitted.

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…

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]

Re: GitHub commit search: “remove password”

#78

Post by epalm »

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?

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

Re: GitHub commit search: “remove password”

#80

Post by OJFord »

Mithaldu wrote: post #75
thenickdude wrote: post #71

Earlier quoted context omitted.

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.

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.

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.

Post reply on HN