Live data from Hacker News

GitHub Security Bug Bounty

github.com

21–30 of 38 posts

Re: GitHub Security Bug Bounty

#21

Earlier quoted context omitted.

Why don't they just publish the key on the site?

Probably because security@ emails are routed through their normal helpdesk system which doesn't handle PGP properly.

I doubt that their security emails do that, but even if they do, changing how you get the key wouldn't fix a PGP compatibility issue, since once you have the key you'd still be emailing them using it.

Re: GitHub Security Bug Bounty

#23

Great news. I'm happy to see this program in "public mode" now. GitHub launched this program already as private beta in May 2013. https://twitter.com/totally_unknown/status/42899282447475916... Don't expect to earn easy cash here. :)

I wonder if the reward values have changed since the beta? I'm sure it is much harder to find anything now than it would have been back then, assuming they got a good turnout from really experienced people and 7-8 months of headstart.

Re: GitHub Security Bug Bounty

#25
post #9

The one obvious flaw is the "email us for our PGP key" - distributing the public key in private and over an insecure channel makes it vulnerable to replacement. Has anyone written a "best practices" guide for designing a security page ?

Why don't they just publish the key on the site?

They should post it, and preferably on an https site.

Re: GitHub Security Bug Bounty

#26

Isn't $5000 ridiculously low compared to the black market value of a GitHub exploit, or the time required to develop it? Assuming a company thinks it's pretty secure, putting real money on the line (the same money you'd normally pay an expert to pentest your system) would get some more prolific minds involved.

Making 5k legally might be more appealing than making 20k on the black market, for example. When you have to hide your tracks and risk getting caught a lower for sure sum might be more appealing. Also, Github is new at this, they might raise the bounty once they see how the program progresses.

Re: GitHub Security Bug Bounty

#27
post #12
post #9

The one obvious flaw is the "email us for our PGP key" - distributing the public key in private and over an insecure channel makes it vulnerable to replacement. Has anyone written a "best practices" guide for designing a security page ?

In theory, PGP public keys shouldn't depend on being sent over a more-secure medium like SSL, because they're signed. One of the main points of PGP's design is that you can't spoof a public key, because you can't spoof its signatures. That being said, in practice, I don't know that everyone is diligent about checking signatures of public keys they receive. An attacker could create a spoofed key, sign it with several…

The point is that you need an entry point of trust. So either you have been in many different signing parties and you happen to have a reasonable connection with the key, or they must give you a trust reference on the website, preferably through HTTPS. At which point, they can just publish the key on the website.

Re: GitHub Security Bug Bounty

#28
Hey githubbers, could you please stop repeating the tired "responsible disclosure" meme?

Full disclosure is not irresponsible and attempts to frame it as such are bordering on malicious toward the exact community in which you are attempting to engender goodwill.

Re: GitHub Security Bug Bounty

#30
post #12

Earlier quoted context omitted.

In theory, PGP public keys shouldn't depend on being sent over a more-secure medium like SSL, because they're signed. One of the main points of PGP's design is that you can't spoof a public key, because you can't spoof its signatures. That being said, in practice, I don't know that everyone is diligent about checking signatures of public keys they receive. An attacker could create a spoofed key, sign it with several…

The point is that you need an entry point of trust. So either you have been in many different signing parties and you happen to have a reasonable connection with the key, or they must give you a trust reference on the website, preferably through HTTPS. At which point, they can just publish the key on the website.

Yes, that would definitely be a viable strategy. It's probably the easiest one, and it's what I would do. In general, using HTTPS for anything related to your bug bounty program is probably good hygiene.

Though even without that, I don't think you need to have been to a lot of key signing parties. The entry point of trust could very well be another organization--not GitHub, not someone at a key signing party. As long as the signature chain points back to an identity you can trust, you're good to go.

Post reply on HN