Hacker News Reader

Comment by 3pt14159 | Hacker News Reader

This is a very grave error. If this caused damage to open source projects then I could see a class action suit against GitHub.

1. Duty of care - should never have accepted keys provably weak.

2. Poorly communicated that username.keys was available, thus many users may have thought their keys weren't at risk.

3. No countermeasures from crawlers mass collecting keys. (Not they they should even need to do this - they should just have done #1 in the first place!)

This isn't a game man, GitHub hosts a ton of the world's open source code and they're supposed to be experts in cryptography and security. Russian mobsters, NATO spooks, bitcoin drug cartels, and even high school script kiddies are all constantly trying shit and it impacts us all not just the people with weak keys. If python core gets backdoored I get backdoored, no matter how careful I am with the software I install.

View on HN

Instead of downvoting, let's educate people a bit more:

1. Picking a small key is all on the user. It's like choosing the single letter 'a' as a password. If you want to do so why not?

2. The key you give to github is a "public" key. It is made to be public so this should be irrelevant.

3. There is 'almost' no known countermeasures against mass crawls of public keys. Look at the recent attacks: https://blog.hboeck.de/archives/872-About-the-supposed-facto...

What they could do: check against databases of public keys to see if your key is weakened by such attacks.

Edit:

In response to your #1:

Picking a password is all on the user too. But magically GitHub is competent enough to stop users from picking the password "ilovecake". Most users of GitHub are not security professionals. Just like most people opening a bank account are not bank vault security professionals.

Original:

They are downvoting me because they love / work at GitHub or don't understand how critical software security is. If you think about the physical life equivalent here (say a bank leaving keys out in the open for safe deposit boxes) there is no way to rationalize it. But all of a sudden it's our favorite social coding startup we can't actually call them out on a huge security fuck up. If this were Microsoft we'd be laughing.

> But magically GitHub is competent enough to stop users from picking the password "ilovecake"

That is definitely a good thing, but github wouldn't be responsible if they didn't do that and people chose weak passwords.

> If you think about the physical life equivalent here (say a bank leaving keys out in the open for safe deposit boxes) there is no way to rationalize it

No, it would be like a bank not actively looking for deposit box keys that customers may have dropped.

btw, I 100% think github should protect users from weak keys, I'm just disagreeing that they could somehow be sued for it

I think it is more like a bank making a diagram of the lock used on each customer's safety deposit box and posting that up on the internet.

I don't see any good reason to put everyone's public key out in the open. Is there any possible way that hiding the keys would hurt github's profits?

That is a truly awful analogy.

The entire point of PKI is that the public key is meant to be public. The impact on your security if a properly-created public key gets out is absolutely nil. I don't see any reason to hide them, save for an irrational belief that only comes from not knowing how the math works.

Noted upthread: there are some noncryptographic threats about revealing the identity of anonymous users, and conceivably giving people information about which devices to steal in order to impersonate that developer. (The second is mitigated a bit by stripping the comments, but is still conceivably a source of information.)

How is a public key revealing your identity? You can generate as many pair as you want. If you want your identity on github to be masked just generate a key specifically for github

This is all fine and well if you know that github exposes your keys. Which, at least wheb I added my keys, was not mentioned in a big, red button in the key dialog. Maybe I trusted GH too much by not creating a separate key pair for them. But information about me is being leaked without my knowledge, and that's wrong.

Yes, I for one didn't know that GitHub did this. If I had had a pseudonymous account that I trusted GitHub to protect, it would have exposed my identity because I wouldn't have realized it was important to make separate SSH keys.

Edit: Elsewhere commenters say GitHub wouldn't have allowed this for a different policy reason, so this problem couldn't actually come to pass.

It's not called a "public" key for nothing.

Shrug, I didn't know github did this till I read this thread, but I feel neither insecure nor compelled to change anything in response to the news.

I would trust a bank who published their lock diagrams (or at least provided them to me on request) more than one that shrouded their security in secrecy. If I can look at the bank's diagrams I can verify that the lock has no obvious weaknesses, I can show the diagrams to my friends and through analysis we can determine if the lock seems secure enough for my needs. If the workings of the bank's vault are opaque to me the bank could easily be locking my safety deposit box with a twist-tie as a cost cutting measure.

GitHub allowed users to host critical code behind keys that were trivial for bad actors to compromise.

End of story. They should have blocked those keys. They didn't. The majority of the modern open source software movement is centred around a company that couldn't be bothered to lock down the cryptographic keys that protect millions of people from intrusion.

And when I point this out I get downvoted. Completely contrary to the HN guidelines of what deserves a downvote. If people disagree with me that it is gross negligence (which I still 100% view that it is) then they are more than able to voice that, but I'm not some new user shooting their mouth off or saying a dumb inane thing. I'm legitimately concerned about how seriously Github takes software security.

I strongly disagree with #2. Your public key should NOT be public, especially without your explicit consent. Specifically because, at least theoretically, it could be used to derive your private key. From a parandoid point of view that's just Bad.

This is one of the reasons why should use different key pairs for different purposes.

can you suggest a better name for it then?

I strongly disagree with you. So do many, many people who upload their public PGP keys to keyservers. The whole point is that anybody, anywhere can have my public key without knowing my private key. If you can derive the private key from your public key, then you have a really bad keypair (by algorithm or by keysize).

Yes, but communication is the whole point of PGP. I didn't upload my PGP key to a keyserver, I uploaded SSH keys to GitHub so that I could check out my own code--code which is in a private repo.

I can't think of any reason that my SSH keys should be publicly avaiable. GitHub offers private repos so I can't understand why keys are all public by default.

It is because there is absolutely no reason they shouldn't be public. You can generate as many ssh key as you want and if they are long enough they are secure.

I think you are talking about private keys.

> Specifically because, at least theoretically, it could be used to derive your private key.

What theory? I'm unaware of a current working theory that could be used to derive a private key from a public key of sufficient complexity.

Well, maybe when some of these keys were made, they were sufficiently complex, but now they're not. Revealing those public keys has potentially given attackers months/years to try to factor them offline. If the public keys were not known, Github would have a chance (and hopefully does) of rate-limiting brute-force attacks. Heck, even if Github is doing nothing to help against brute-forcing, just hiding public keys might make the bandwidth costs more infeasible than the cost of factoring a known public key.

They're insecure whether or not GitHub makes them viewable. All you get by not publishing your public key is a false sense of security.

This is textbook security through obscurity, and is considered ill-advised by the security community.

But in real-world terms, some users are less likely to be compromised if GitHub hadn't published them. In that light, I don't think it's advisable for GitHub to go out of their way to publish them without the user's knowledge.

I think the "security through obscurity" principle ought to, if it doesn't already include this, say that added measures or core design principles should not be based on obscurity. This should not mean that all obscurity must be removed. In this case, GitHub have added anti-obscurity, and the defense is mainly dogmatic mis-application of the principle IMO.

if they are "compromised" then the whole security of internet is.

Oh, the whole internet is using 512-bit RSA keys, like some GitHub users were? (And I did say "some" before, not "all" or "whole internet".) My point is that the 512-bit users would not have been targetable if nobody knew their keys were 512 bits long. And with bandwidth constraints, their keys would probably not have been bruteforceable either. Due to GitHub publishing their keys, they were targetable, potentially for months, plenty of time to factor.

I guess the response to that will be something about how they don't "deserve" protection because they used weak keys, and while I would resent that sentiment, I can't really argue against the idea.

To sum up, GitHub is doing something cryptographically unnecessary for this use case, that potentially harms confidentiality and anonymity for some users, and the arguments in favor seem to be: 1) A few users find it marginally useful, 2) It doesn't break the actual crypto if the users do it right, 3) Obscurity is taboo, 4) The name is "public key". I'll grant my position is weak, but so are those arguments. Their primary strength is dogma. Which, I don't know, maybe drilling crypto basics does have a net benefit even if they're not applicable to every situation.

> My point is that the 512-bit users would not have been targetable if nobody knew their keys were 512 bits long

This is wishful thinking. A Man In The Middle Attack would have worked on him.

MITM SSH to get the public key and factor it? My understanding from other discussions in this thread is that the publickey authentication protocol is encrypted with the server's host key. Are you relying on the user ignoring key mismatch errors, or targeting them on the first connection and relying on them not checking the key fingerprint? Or something else entirely? I'd like to learn if there's something I haven't thought about here.

> But in real-world terms, some users are less likely to be compromised if GitHub hadn't published them.

This is not true.

Can you read my reply to your "sibling" comment, especially regarding 512-bit keys? I want to know if I have a factual misunderstanding. Or maybe we disagree on probability or something.

The solution to "my key is easily factorable" is not "hide the key", it's "get a new key".

Factually you haven't said anything I know to be wrong.

I agree, with the (silly?) distinction that it's not "hiding" like a secret key, it's just "not showing to the whole world" because they never had a good reason in the first place IMO. Had they not published them, it would address the privacy concerns some of us have, and happen to band-aid over the easily factorable keys too. I guess I'll agree that's not really a legitimate reason to make them "hide" them now... it's mainly my preference for avoiding metadata leakage. I shouldn't have focused so much on factoring.

Just in case anyone is still reading, some rough analogies: Would you publish intermediate state data from a hashing or signing process? Would you publish your users' password hashes (even w/ scrypt and robust character set+length requirements)? Would you re-use Bitcoin addresses that have spent before?[1] Would you add a feature to an SSH server to return users' public keys to anyone on the internet? Would you have GPG auto-publish new keys to keyservers? I see these as not usually fatal, but not smart or necessary things, somewhat similar to this.

[1] One of the justifications for address rotation in Bitcoin is that once the address has spent, its 512-bit ECDSA public key is known, rather than just a RIPEMD160(SHA256()) hash of the public key. Absurd paranoia, lack of understanding crypto, or defense in depth?

It's not because you had more time that you will be able to crack a 1024bits RSA public key.

Are you talking about how factoring will take more time than anyone has available, or something?

Nice try Sourceforge. ;) You should complain with those core commiters.

Reply on news.ycombinator.com