13 ms·
Auditing GitHub users’ SSH key quality
- scrollaway 11y agoHow does one even go about getting a 256-bit key? You have to do it on purpose somehow, or it has to be seriously old, in which case you're likely aware somehow that that's a terrible idea. Is there outdated ssh keygen software out there that still generates sub-768 keys?
- benjojo12 11y agoTo be honest, I have no idea. I had hack about to get Go's crypto/rsa package to give me a key that size, I really would love to know what can make these keys
- makomk 11y ago256 bits is a perfectly respectable length for an ECDSA key, so I'm guessing people tried to generate those and accidentally created RSA keys instead.
- xorcist 11y agoNo, ssh-keygen won't create that small RSA keys. It is a limitation that's been around since long before OpenSSH (although I believe it used to be 512, the limit now seems to be 768).
- TazeTSchnitzel 11y agoPerhaps someone is on an obscure platform whose only SSH key generator is subpar. Or perhaps someone has a system that generates keys automatically, and it was poorly configured.
- dfox 11y agoI vaguely remember that 10 or 15 years ago I've seen obscure ssh client for relatively obscure platform that could not handle RSA keys that were longer than some X, with X being something like 640. Even then, generating such key with OpenSSH was not something one could do by accident.
- pdw 11y agoAnd where do the odd numbers come from? 1023 bits? 799 bits??
- benjojo12 11y agoSo this one is kinda fun. IIRC PuTTYGen had a bug in it for a very long time that you would ask for a 1024 key, and it would subtract a bit off it. You can see the same with 2047 keys in the data that I will be publishing on the next post.
- mortenlarsen 11y agoSome people use slightly odd key-sizes on purpose, in the hope of buying a little extra time in case something like the Debian OpenSSL bug happens again.
- deleted 11y ago[deleted]
- baby 11y agoSame kind of people who write 1338 instead of 1337, for the lulz
- 88e282102ae2e5b 11y agoThey may have been assuming that appropriate key lengths for AES would work for SSH keys as well.
- Marcus316 11y agoI'm pretty sure the first 256 bit key listed in his output is/was mine. It was a key generated and used as a test (years ago). It has never been used to access my Github account. Also, my account is pretty bare as it is. To be safe, though, I have now removed the key.
- baby 11y agoNow you can also test several attacks on them, compare them to a larger database to see if you have common divisors, check for low primes, check for bad primes (fermat factorization)...
- benjojo12 11y agoYup, this is what I will be trying next.
- baby 11y agoOh and check for low private keys as well, I did that before here's the code: http://cryptologie.net/article/265/small-rsa-private-key-problem/ http://cryptologie.net/article/265/small-rsa-private-key-pro...
- LunaSea 11y agoIt could be interesting to try to match those keys to the ones generated by Debian during the OpenSSH vulnerability [1] period. [1] http://jblevins.org/log/ssh-vulnkey http://jblevins.org/log/ssh-vulnkey
- ryan-c 11y ago
- quux 11y agoKudos to Github for not charging him with "Unauthorized Access of a Computer"
- jessaustin 11y agoGiven their customer base, that sort of response would have kicked off a shit-storm. ISTM that any "responsible disclosure" ought to at least rate a T-shirt. (If GH don't want to pony up the T-shirt, that's fine, but they can't send customer notifications before the researcher publishes.)
- robzyb 11y ago> (If GH don't want to pony up the T-shirt, that's fine, but they can't send customer notifications before the researcher publishes.) In my uneducated opinion, that seems like a really good way to judge whether something qualifies as worthy of a bug bounty etc.
- benjojo12 11y agoI'm not saying that I didnt get anything for it what so ever, The peer of mine did manage to send over some swag as a thanks, I now have http://i.imgur.com/d2f7mcD.png http://i.imgur.com/d2f7mcD.png on my work desk :)
- kardos 11y agoSure, but as I understand it, he doesn't/didn't need to actually try it on github's servers. If he put the public keys in question into the authorized_keys list of a second account on his personal system, he can locally verify that the brute forced private key is correct. I think the wording agrees with this: > <snip> and then a few more minutes to transform those back into a SSH key that I could log into systems with.
- dimino 11y agoTo be wildly pedantic, GitHub wouldn't charge him with anything, the DoJ would, regardless of what GitHub does/doesn't do.
- 11y ago
- est 11y agothat https://github.com/anybody.keys https://github.com/anybody.keys feature, how on earth did OP find this?
- lucaspiller 11y agoI've heard of it before, the same is available in their API too: https://developer.github.com/v3/users/keys/#list-public-keys-for-a-user https://developer.github.com/v3/users/keys/#list-public-keys...
- helper 11y agoIts a documented feature [1]. [1]: https://developer.github.com/v3/users/keys/ https://developer.github.com/v3/users/keys/
- tyrel 11y agoSeeing a key with substring of "Tyr" as the username and that substring of my key matching scared me a bit. If you want to check how many bits your key is, use ssh-keygen -l -f ~/.ssh/your_key.pub (It wasn't mine, while it is an older key, mine is larger than 768 thankfully) Edit: look at timdorr's example for a better visual.
- timdorr 11y agoMost people will want to run this verbatim: ssh-keygen -l -f ~/.ssh/id_rsa.pub You'll get an output like so: ⚡~ $ ssh-keygen -l -f ~/.ssh/id_rsa.pub 2048 f6:2d:94:54:c0:96:18:64:24:fb:c2:ad:ed:6a:1d:68 timdorr@Pixelicious.local (RSA)
- tyrel 11y agoTrue, this will be default if you don't namespace your keys and use ssh config files like I do, I should have just said that.
- Killswitch 11y ago4096 63:f2:23:00:c9:0d:07:3b:6d:ad:4d:a9:98:32:f5:25 ***@*** (RSA) Am I good?
- wwwhizz 11y agoYour key is 4096 bits, you're good.
- _lce0 11y agohow much safe are we, with a 2048 bits key? is this something we should be upgrading (like to 4096) in the near future?
- mbesto 11y agoI don't have a qualified answer but given he says it would take 24 minutes to crack a 256bit key and 3 days to do a 512bit, I would extrapolate (given exponentially difficulty as you add more bits) to roughly: - 180x per doubling bit size would be - 512 doubled twice, would mean 3 days * 180 * 180 = 97,200 days I think you're safe.
- Someone1234 11y agoMaybe GitHub themselves should just stop accepting keys of a certain length. For example <2048 RSA keys (and <256 ECDSA keys). They could also check against the Debian set. As the article says, GitHub could be being proactive rather than reactive here. They don't "have" to, but they could.
- benjojo12 11y agoGitHub now, after reporting this to them do not allow keys below 1023 to be added, and all keys that had been smaller than that, have been removed and owners of those keys got a email like screenshot on the top of the post
- Noelkd 11y agoAccording to a 2009 blog post[1]: > Thanks to our new servers, known bad keys[2] from Debian and Ubuntu are now blacklisted. We estimate that about 1000 keys in our database were impacted by this. If you get authentication errors using keys that worked a day ago, please double-check that they are not on our blacklist. If they are, you should ensure your software is updated and generate new keys. We’ve got a guide to help you out with this. [1] https://github.com/blog/500-state-of-the-hub-rackspace-day-0 https://github.com/blog/500-state-of-the-hub-rackspace-day-0 [2] https://github.com/blog/63-ssh-keys-generated-on-debian-ubuntu-compromised https://github.com/blog/63-ssh-keys-generated-on-debian-ubun...
- scintill76 11y agoWoah, this new article says a lot of weak-Debian keys were found. Does this mean Github had a regression in their blacklisting since 2009? Or maybe they didn't blacklist enough originally?
- madsushi 11y agoRachel talked about Github and public keys a while ago (saw on HN): https://rachelbythebay.com/w/2013/04/07/ssh/ https://rachelbythebay.com/w/2013/04/07/ssh/
- 3pt14159 11y agoThis 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.
- baby 11y agoInstead 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-factoring-of-a-4096-bit-RSA-key.html 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.
- 3pt14159 11y agoEdit: 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.
- deleted 11y ago[deleted]
- Phemist 11y agoEspecially the guy with commit access to PyCrypto should reconsider his position in the project..
- Tharkun 11y agoAt least Github were "kind" enough to strip the comments from the public keys they publish without permission. I would've been even more upset if they were leaking things like username@workdomain....
- c22 11y agoBut the keys are public...
- Dylan16807 11y agoSo is the writing on a postcard; doesn't mean you want it published.
- Tharkun 11y agoThat's my point. They shouldn't be. I never gave Github permission to publish my keys. The "public" part in the key is merely there to distinguish it from the "private"-part ("never share this with anyone"). It should signify "share this with people whose machine you want to access", not "share this with the whole world". From a healthy paranoid point of view: you don't share your public key unless you have to. Sure, there are no known attacks on strong RSA keys today, but that doesn't mean there will never be. Why take that risk with, literally, thousands of keys and people's security? It's rude at the very least. Of course, you should never use your Github keys for anything else, but that's beside the point entirely. As for the comments: key comments are useful but often contain information that can identify a person (e-mail address, username@machine etc). Publishing that would have been even worse.
- dkrich 11y agoOr at least give each user the option and default it to unshared. I don't see why they'd default to sharing everyone's.
- the8472 11y ago> Why take that risk with, literally, thousands of keys and people's security? I would say it encourages scrutiny. The assumption of public keys is that they are public, if any part of your security architecture relies on a public key being private then it would seem flawed, flaws that should be exposed. And if them being public induces extra paranoia, such as using separate keys only for github then all the better. Sunlight is the best disinfectant.
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- nandhp 11y agoI still use a 1024-bit DSA key I generated ~10 years ago. How bad is that? Should I replace it with a 2048-bit RSA key?
- newman314 11y agoYes
- baby 11y ago> We go on to consider Diffie-Hellman with 768- and 1024-bit groups. A small number of fixed or standardized groups are in use by millions of TLS, SSH, and VPN servers. Perform- ing precomputations on a few of these groups would allow a passive eavesdropper to decrypt a large fraction of Internet traffic. In the 1024-bit case, we estimate that such com- putations are plausible given nation-state resources, and a close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break. We conclude that moving to stronger key exchange methods should be a priority for the Internet community. From: https://weakdh.org/imperfect-forward-secrecy.pdf https://weakdh.org/imperfect-forward-secrecy.pdf
- floatboth 11y ago> 210 | ssh-ed25519 AAAAC Does this mean GitHub finally supports Ed25519?
- mjevans 11y agoAs someone who's put an ed25519 key on github... I'm not actually sure (didn't verify). I also still have compatibility keys there, I merely installed it so that, opportunistically, it could be used when supported.
- glass- 11y agoI've been using an Ed25519 key on github for about 6 months now.
- lcd047 11y agoIn the mean time, Bitbucket still doesn't accept ECDSA keys: https://bitbucket.org/site/master/issue/4222/no-support-for-ecdsa-keys https://bitbucket.org/site/master/issue/4222/no-support-for-...
- 7ewis 11y agoWhat is the easiest way to manage SSH keys? I can't remember where half of mine have been saved. I should really revoke everything and start again, as I use it for accessing my VPS too. How do you revoke all keys on Ubuntu and OS X?
- semi-extrinsic 11y agoThere is no concept of revoking ssh keys, so you have to remove them from the ~/.ssh/authorized_keys file on every server you have access to, and delete the public keys at every service you've uploaded them to. For a revoking mechanism to be possible you would need a trusted third party (like a certificate authority) to verify the keys for each and every connection you make.
- shabble 11y agoFor managing large infrastructure, it's possible with semi-recent openSSH (5.4+ I think?) to validate and revoke keys[1] by signing them with a different key which the server (or client) trusts. [1] http://www.lorier.net/docs/ssh-ca http://www.lorier.net/docs/ssh-ca
- scintill76 11y agoSo, all the "it's called a public key for a reason!" people: when are you going to submit a patch for OpenSSH allowing unauthenticated users to query arbitrary users' public keys, and maybe a list of users while you're at it? You vehemently support one particular operator of an SSH server doing it, citing good security practice, so why not do it everywhere? Edit: to be fair, there is the difference that GitHub has already added it and probably didn't have to write C code to do it. So maybe this feature should be requested for things like, say, cPanel, and users' $HOME/.ssh/authorized_keys should be world-readable by default. Still, maybe it's worth doing in OpenSSH so everyone can get the huge benefits of this currently only enjoyed by GitHub's users.
- nodesocket 11y agoI'd be interested in the script used to scrape the GitHub public key endpoint? I assume it just throttled back to stay under the GitHub API rate limit?
- scintill76 11y agoPitting two well-known security principles (or at least watered-down versions) against each other: "security by obscurity is evil" and "defense in depth". Which trumps here? Should the public keys be printed in every phone book, just because it says "public" in the name? Or should they be kept semi-secret, since publishing them could lead to them being factored offline?
- akerl_ 11y agoDefense in depth doesn't conflict with "security by obscurity is evil": Defense in depth is that I keep my private key secured with a passphrase, on an encrypted volume, and that I take measures to protect against applications having access to it unless they require it. It's the layer of physical security where I don't leave my laptop where it's easily accessed, and everything else that goes into securing a workstation. Defense in depth recommends having multiple layers of security, such that a breach of a single layer doesn't constitute a full breach. There's no requirement (and in fact I'd argue there's no solid recommendation) for including obscurity as one or more of the layers.
- kelnos 11y agoThe parent may not have used the best terminology, but the point still stands: your "defense in depth" example utterly fails to protect your private key if your public key is widely-available and easily-factorable. If I didn't have my public key on GitHub, it's unlikely that even that could fall into an attacker's hands. Not that I would rely on that assumption, but it would reduce my attack surface.
- akerl_ 11y agoIf you think there's a chance that public RSA (lets not even get started on ed25519) keys of reasonable size are easily-factorable, there's a lot of groups out there who'd love to make you rich or lock you up.
- dragonwriter 11y ago
- hugomarisco 11y agoGood article. Very detailed and thoughtful!