Compromised SSH keys used to access Spotify, UK Govt GitHub repos CloudFlare engineer Ben Cox says the official Github repositories of the UK Government, Spotify, and Python were accessed using likely compromised SSH keys. Cox says the keys revoked this month are subject to a compromised Debian OpenSSL random number generator seed discovered and fixed in early 2008. The security bod …
Dear Sirs,
why should github do more to stop users hurting themselves?
Github is code repository service, not a security service. How the repos are accessed is entirely up to the users.
It's like saying that Chris Boardman should make saver bikes so that users are saver on them.
Nannystatism, that. If you yourself are not clever enough to use github in a secure manner, maybe you shouldn't be accessing it to begin with... Why always state that problems are somebody else's fault? Is this what society is coming too? Is this what happened with society and why we ended up in these nannystates? Because nobody is man enough to put there balls on the table any more? What about standing tall and admitting that you made a mistake, that the fault is all yours... Your balls will be busted, but you can leave the room with integrity and be proud and respected for your actions!
Just my 0.02,
Guus
This post has been deleted by its author
"If you yourself are not clever enough to use github in a secure manner"
So Sir, were you clever enough to notice the bad random number generator in Debian's OpenSSL? Did you in fact report it and help fix things?
If not then STFU and get on with something more useful. The call is not for GitHub to hand-hold users at any point, but to notice said compromised keys and warn users about them. Those keys, most likely, were generated years ago and then kept even when the user's OS was updated to something that has that bug fixed and they probably forgot which version of number generator was used to generate them originally.
I took all of my existing keys out of use, and reissued the lot, because I couldn't remmeber exactly when each had been generated (or necessarily on which machine).
But to expect that level of action from everyone with a github account?
In the same way I expect browsers to flag up bad certs I'd expect SSH banners to warn about these compromised keys - or simply ignore them (with error in the server log at least, preferably in the banner)
You're right but you are still wrong.
If you have important data you want to protect, you will also have specific policies for periodically renewing the encryption keys (like erm... rotating passwords ?). Remember, lad, security is an on-going process not a one-shot deal.
Python hosts its own Mercurial repository so there could only be a mirror on Github.
Good point (assuming you're correct - I haven't checked). But if there's a mirror on Github, then probably there are some folks building Python and the Python crypto libraries from that mirror; and if that mirror's been compromised, then those binaries are compromised. So it's worth mentioning.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
