Github Kills Search After Hundreds of Private Keys Exposed

← Back to Stories (view on slashdot.org)

Github Kills Search After Hundreds of Private Keys Exposed

Posted by Soulskill on Friday January 25, 2013 @01:49AM from the take-care-what-you-make-public dept.

mask.of.sanity writes "Github has killed its search function to safeguard users who were caught out storing keys and passwords in public repositories. 'Users found that quite a large number of users who had added private keys to their repositories and then pushed the files up to GitHub. Searching on id_rsa, a file which contains the private key for SSH logins, returned over 600 results. Projects had live configuration files from cloud services such as Amazon Web Services and Azure with the encryption keys still included. Configuration and private key files are intended to be kept secret, since if it falls into wrong hands, that person can impersonate the user (or at least, the user's machine) and easily connect to that remote machine.' Search links popped up throughout Twitter pointing to stored keys, including what was reportedly account credentials for the Google Chrome source code repository. The keys can still be found using search engines, so check your repos."

176 comments

Min score:

Reason:

Sort:

At least... by Anonymous Coward · 2013-01-25 01:52 · Score: 5, Funny

they've been seen by 'many eye balls'.
That's good right?
1. Re:At least... by Anonymous Coward · 2013-01-25 02:14 · Score: 1
  
  I don't know about that. I, for one, don't want my eyeballs seeing any of you guys expose your private "keys"
2. Re:At least... by Anonymous Coward · 2013-01-25 02:19 · Score: 0
  
  they've been seen by 'many eye balls'.
  That's good right?
  Kerckhoff's Principle is that a cryptosystem should be secure even if every detail about its implementation is known, EXCEPT for the key.
3. Re:At least... by ArsenneLupin · 2013-01-25 02:21 · Score: 4, Funny
  
  But on the other hand, you certainly wouldn't object to any gals exposing their pubic "locks"...
4. Re:At least... by Anonymous Coward · 2013-01-25 02:24 · Score: 1
  
  that may have whooshed you. OP was making a joke about the whole "open source makes it more secure because more people have looked at it" idea.
5. Re:At least... by Anonymous Coward · 2013-01-25 02:49 · Score: 1
  
  The key here is that it was a horrible joke, as anyone can see.
6. Re:At least... by Anonymous Coward · 2013-01-25 02:54 · Score: 0
  
  Which, essentially, follows roughly the same principle. With the exact same exception.
7. Re:At least... by nitehawk214 · 2013-01-25 03:22 · Score: 1
  
  I don't know about that. I, for one, don't want my eyeballs seeing any of you guys expose your private "keys"
  Especially Goldmember's private key.
  
  --
  I'm a good cook. I'm a fantastic eater. - Steven Brust
8. Re:At least... by i_ate_god · 2013-01-25 03:53 · Score: 1
  
  neither do I, but seeing the locks would be something I'd be interested in
  
  --
  I'm god, but it's a bit of a drag really...
9. Re:At least... by Anonymous Coward · 2013-01-25 04:01 · Score: 1
  
  Privately, I agree. Publicly, I feel the same.
10. Re:At least... by Anonymous Coward · 2013-01-25 04:10 · Score: 0
  
  neither do I, but seeing the locks would be something I'd be interested in
  You are going to need a mirror and moderate flexibility.
11. Re:At least... by Anonymous Coward · 2013-01-25 04:12 · Score: 0
  
  The real humor lies in your misunderstanding of the 'many eye balls' statement.
  The keys being divulged is the result of the bug, not the bug itself.
12. Re:At least... by Richy_T · 2013-01-25 11:04 · Score: 1
  
  You guys are making a real hash of this thread.
13. Re:At least... by Anonymous Coward · 2013-01-25 15:01 · Score: 0
  
  That's probably why it's at +5 Funny, yeah.
This is why developers are not sysadmins by h4rr4r · 2013-01-25 01:55 · Score: 3, Insightful

This is why developers are not sysadmins.
These kinds of repositories need to learn that and not let these folks do this sort of thing. If would be simple to use a regex to filter out the posting of these sorts of files. Maybe Devs should even be charged a couple dollars to get a decent review of these things.
1. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 01:59 · Score: 5, Insightful
  
  No. This is actually completely absurd. A developer that cannot grasp the concept that private keys have to be kept private, cannot be trusted to do anything but screw up the most basic security provisions when writing code.
  They should get a kick in the ass, such as three months without any sort of commit privileges, and mandatory code review for an year. THAT should be enough to make it stick, and impress on them the real gravity of their failure. Otherwise, they will just chalk it up as "an annoyance done by those uninteresting people who should learn to code before they go pestering code-gods".
2. Re:This is why developers are not sysadmins by stewsters · 2013-01-25 02:04 · Score: 1
  
  I don't think that would be easy to implement. In git you add and commit your changed to a local repository, then push them back to github. Somehow cutting them out later would give you really cool errors. They would need to catch them on your commit locally. The real question should be why those keys were placed inside the project directory, and not somewhere like ~/.ssh/
3. Re:This is why developers are not sysadmins by Hatta · 2013-01-25 02:07 · Score: 1
  
  Or just leave the keys and let them learn their lessons the hard way.
  
  --
  Give me Classic Slashdot or give me death!
4. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 02:08 · Score: 1
  
  This is why developers shouting "give me full access now" should always be denied - there is a totally different mindset between developers and admins (or DevOps) when it comes to protecting things like SSH keys.
  Both groups have similar (or certainly overlapping) technical skill sets, but have very different motivations.
  ObXKCD: http://xkcd.com/705/
5. Re:This is why developers are not sysadmins by h4rr4r · 2013-01-25 02:10 · Score: 1
  
  Could they not supply a .gitignore ?
  Either way simple enough to have a find script run, before you make it public. Basically on every commit turn off public access, run your clean script, then turn it back on. If this causes errors, that seems better than this.
  I admit at work we mostly use a combination of CVS and a 2x4 to hit developers with to avoid these issues while still having a nice simple repository.
6. Re:This is why developers are not sysadmins by h4rr4r · 2013-01-25 02:12 · Score: 4, Interesting
  
  Sysadmins should also know how to code. Nothing better than showing them their screwup and the solution to it.
  Plus, since all sysadmins, real ones anyway, are already competent in several scripting languages it is not that hard a skill to add if all you need to do is be better than bottom of the barrel programmers.
7. Re:This is why developers are not sysadmins by h4rr4r · 2013-01-25 02:14 · Score: 2
  
  The best system I have seen is not allow devs any access to production environments. All pushes done by sysadmin and dev boxes identical to production.
8. Re:This is why developers are not sysadmins by ArsenneLupin · 2013-01-25 02:17 · Score: 5, Insightful
  
  In some of these instances, all of ~/.ssh/ did actually end up in the project directory. Or maybe they used their entire home directory as the project root? Stoopid, stoopid people.
  (Yes, there is also a nice ~/.ssh/config file, so that you also know which locks those key fits...)
9. Re:This is why developers are not sysadmins by robmv · 2013-01-25 02:20 · Score: 1
  
  Yo can launch a filter like program from an event before the commit is saved on the remote repository, and stop with an error, this force the careless developer to amend their commits
10. Re:This is why developers are not sysadmins by h4rr4r · 2013-01-25 02:24 · Score: 1
  
  If we could pair this with some sort of clue bat strike via IP that would be best.
11. Re:This is why developers are not sysadmins by Raumkraut · 2013-01-25 02:36 · Score: 3, Insightful
  
  I've seen several people comment that they have their home directory config files under version control. If you're using git for that, it's a fairly simple next step to then "backup" the repo to github.
  "It's only config files; nobody would be interested in those."
12. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 02:38 · Score: 1
  
  You are correct that the penalties for something like this should be severe, but in the meantime, the damage done by people who expose their private keys in this way is still done, and still needs to be mitigated. A basic heuristic should not be hard. When a commit comes in, look commit for .ssh directories, and if they are found, look in those directories for valid private key files. If private keys are found, reject the commit, send the developer an automated nastygram ("We stopped this, but do you realize what in the flying blue fark you could have done?!"), and trigger the penalties.
  This is an imperfect solution, of course. It doesn't look anywhere but the default location for private keys. But this is the common case by such a huge margin that it should be enough: anyone who knows how to (and cares enough to) get their keys into a non-default location either knows what they're doing or deserves what they get.
13. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 02:42 · Score: 0
  
  And sysadmins don't do these kind of stupid shit? BS.
  Along with this, people posted their .bash_history which is just as bad imo, and in one of those .bash_history's I noticed a "ssh sysadmin@some_ip_addr" so it's not like they are all geniuses.
  You can still check all these bash histories by doing a google search:
  site:github.com inurl:.bash_history
14. Re:This is why developers are not sysadmins by petermgreen · 2013-01-25 02:53 · Score: 1
  
  For new screwups the soloution would be to just reject the push and let the developer sort it out.
  For existing screwups it's not so easy. One of the characteristics of hash-based dvcs systems like git is that they make it REALLY painful to change history. You could generate new commits and blacklist the old ones but doing so would tip off all users of the repository that something was up and those users would still have their copies of the original commits.
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
15. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 02:54 · Score: 0
  
  Yes, github should be sued out of existence because of incompetent coders who only needed to make their repos private.
16. Re:This is why developers are not sysadmins by h4rr4r · 2013-01-25 03:00 · Score: 1
  
  Those people should just be fired. This is pretty much par for the course for the average new developer.
17. Re:This is why developers are not sysadmins by segedunum · 2013-01-25 03:13 · Score: 2
  
  The first thing you learn is that your private SSH keys are sacrosanct. Most developers seems to just go through a howto on how to generate a SSH key and don't think about anything after that. They're probably all using node.js or something.........
18. Re:This is why developers are not sysadmins by Zeromous · 2013-01-25 03:22 · Score: 1
  
  I can't remember the last time a developer had a workable, secure solution to my problems.
  There's a reason you hear, 'fix your own code' a lot more than 'fix your servers' in a development environment.
  
  --
  ---Up Up Down Down Left Right Left Right B A START
19. Re:This is why developers are not sysadmins by tzanger · 2013-01-25 03:28 · Score: 1
  
  There's absolutely nothing wrong with that. My question is why they're storing their home dir on a *public* git repo...
20. Re:This is why developers are not sysadmins by nschubach · 2013-01-25 03:37 · Score: 2
  
  Duh... it's so they don't have to remember their passwords to get their configuration and RSA keys back!
  
  --
  Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
21. Re:This is why developers are not sysadmins by RevDisk · 2013-01-25 03:44 · Score: 1
  
  I concur. SysAdmins should know how to write a script. I certainly ask any sysadmin I hire what programming or scripting languages they know. If they don't, I assign them tasks to learn VBS and Linux shell scripts, as a start. If a sysadmin is running web servers, they need to know decent amount of HTML and PHP. Enough to see how it is interacting with the infrastructure.
  
  They don't have to be "professional programmers". Minimum is enough to understand what's going on. Code and scripts run on logic. If a sysadmin can't work out logic problems, I don't want them touching my infrastructure.
22. Re:This is why developers are not sysadmins by 19thNervousBreakdown · 2013-01-25 03:46 · Score: 2
  
  This is why key management should be part of the operating system, and every piece of software that doesn't use those APIs should be suspect.
  It's simply too big a subject to expect everyone who is in danger of falling prey to something similar (everyone who uses a computer) to manage on their own. If you know where every individual piece of software you run stores every single key, you are a very, very rare person. You're also probably mistaken.
  Even if we started down the path, it would take a long time, that's no question. But I can think of no other alternative that has even an ounce of realistic chance of success.
  
  --
  <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
23. Re:This is why developers are not sysadmins by nitehawk214 · 2013-01-25 03:50 · Score: 1
  
  If we could pair this with some sort of clue bat strike via IP that would be best.
  I hear a guy is working on a IP-based face-stabbing machine.
  
  --
  I'm a good cook. I'm a fantastic eater. - Steven Brust
24. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 03:53 · Score: 0
  
  The best system I have seen is not allow devs any access to production environments. All pushes done by sysadmin and dev boxes identical to production.
  Now if only we could find super-competent admins that don't fuck things up left and right, and devs that could write documentation that the good admins can follow and design code that can actually be deployed instead of hacked-in-place, and management that doesn't insist on "hurry up and get it fixed right now, we will follow the normal process when we have time".
25. Re:This is why developers are not sysadmins by ethan0 · 2013-01-25 04:03 · Score: 1
  
  your link has only .pub files, though. I see no private keys here.
26. Re:This is why developers are not sysadmins by Fnord666 · 2013-01-25 04:07 · Score: 1
  
  There's absolutely nothing wrong with that. My question is why they're storing their home dir on a *public* git repo...
  Because it's only free if it's a public repository.
  
  --
  'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
27. Re:This is why developers are not sysadmins by Fnord666 · 2013-01-25 04:13 · Score: 1
  
  The first thing you learn is that your private SSH keys are sacrosanct. Most developers seems to just go through a howto on how to generate a SSH key and don't think about anything after that. They're probably all using node.js or something.........
  Followed by going through the git howto that tells them to
  git init
  git add .
  git commit -m "Initial Commit"
  
  --
  'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
28. Re:This is why developers are not sysadmins by KingMotley · 2013-01-25 04:16 · Score: 3, Interesting
  
  I dunno about that here. Ever since they rolled out Sophos Full Disk Encryption on every desktop and server here, it's contributed more to downtime than any virus/malware ever has. I think literally every person in this office has had to have their machine completely rebuilt after it got corrupted somehow, and that includes our testing servers as well.
  All I can say is, thank god our production servers are out of our company's control. They haven't had any issues, but then again, they also don't have Sophos malware on them either.
29. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 04:16 · Score: 0
  
  They should get a kick in the ass,
  Be careful -- you don't want hacker news calling you a bully.
30. Re:This is why developers are not sysadmins by Zeromous · 2013-01-25 04:18 · Score: 1
  
  This is likely out of the hands of your sysadmins. Servers should not be running this POS, EOS. But you know, then some CIO reads about it in a magazine somewhere....
  Anyway, my condolences to your build farm.
  
  --
  ---Up Up Down Down Left Right Left Right B A START
31. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 04:34 · Score: 0
  
  I don't think it's that. I think we'll find that a popular git suite for windows has some checkbox that does this, and nobody pays attention to it.
  Remember that a ton of the stuff on github is done by regular joes, just amateurs that want to share what they did somewhere. They're not git pros or full time programmers... they're just following the github tutorial the best they can with whatever software google pointed them at.
32. Re:This is why developers are not sysadmins by ArsenneLupin · 2013-01-25 04:38 · Score: 2
  
  They had some when I posted this. Looks like the "candidate" (or github admins?) have cleaned them up...
33. Re:This is why developers are not sysadmins by ArsenneLupin · 2013-01-25 04:41 · Score: 1
  
  Another example is here: https://github.com/nouh/dotfile/tree/master/ssh
34. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 04:52 · Score: 0
  
  Yes. This. So often is heard the cry "but I only code!". I guess this must also mean "I do not think". Such 'developers' should really be eased out of the business, not just subject to a code review (which should happen as standard anyway).
35. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 04:54 · Score: 0
  
  If a sysadmin is running web servers, they need to know decent amount of HTML and PHP.
  I'd argue HTML, and PHP is only useful if the webservers are running PHP.
  But if they are - I am in total agreement.
  Mostly because PHP developers never seem to quite understand that there are these things they have logs - logs they have access to on development servers, but refuse to look at. Not to mention, when you can drop, "You're throwing a fatal in foo.php on line 62. Fix your code." on them, it's... Well, it isn't nice, but it means you can mute the 1AM conference call and get in some quality Netflix time while they fix their bloody code..
36. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 05:04 · Score: 0
  
  They had some when I posted this. Looks like the "candidate" (or github admins?) have cleaned them up...
  There's zero reference in the commit history to the private id_rsa key file outside .ssh/config. If it ever existed, it would have had to have been rebased out of the history which would screw with every remote repository cloned off this one.
37. Re:This is why developers are not sysadmins by sexconker · 2013-01-25 05:28 · Score: 1
  
  This is likely out of the hands of your sysadmins. Servers should not be running this POS, EOS. But you know, then some CIO reads about it in a magazine somewhere....
  Anyway, my condolences to your build farm.
  I'm just glad they don't advertise "business solution" software in Skymall.
38. Re:This is why developers are not sysadmins by Zeromous · 2013-01-25 05:49 · Score: 1
  
  I'm just glad they don't advertise "business solution" software in Skymall.
  Sadly, they do. Not many, but just enough to drive your IT dept batty.
  Here is an example:
  http://www.skymall.com/shopping/detail.htm?pid=204348403&c=102961963
  
  --
  ---Up Up Down Down Left Right Left Right B A START
39. Re:This is why developers are not sysadmins by 1s44c · 2013-01-25 06:49 · Score: 1
  
  No. This is actually completely absurd. A developer that cannot grasp the concept that private keys have to be kept private, cannot be trusted to do anything but screw up the most basic security provisions when writing code.
  They grasp the concept just fine. It isn't that they don't understand, it's that they don't see it as their problem.
40. Re:This is why developers are not sysadmins by 1s44c · 2013-01-25 06:57 · Score: 3, Insightful
  
  Developers are the best sysadmins you can have, since they're actually somewhat competent.
  It's just that they've got better things to do and are paid more.
  Developers are normally careless sysadmins. Sysadmins are usually inept programmers. Someone that really can do both well is a great asset.
  Good sysadmins get paid about the same as good developers. At least that's my experience.
41. Re:This is why developers are not sysadmins by osu-neko · 2013-01-25 08:05 · Score: 1
  
  Normally I'm a big fan of giving developers enough rope to shoot themselves in the foot, but not when this has the potential to hurt a lot of other people besides themselves...
  
  --
  "Convictions are more dangerous enemies of truth than lies."
42. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 08:07 · Score: 0
  
  THANK YOU!
  This is what happens in our environment nowadays.
  devs (of which I'm one) where allowed to tag for release. Until a major fuckup occured.
  Developers should NOT be allowed to release until their product goes through admins.
43. Re:This is why developers are not sysadmins by Hatta · 2013-01-25 08:53 · Score: 1
  
  How are other people endangered if I leave my private key in a public place?
  
  --
  Give me Classic Slashdot or give me death!
44. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 09:10 · Score: 0
  
  A developer that cannot grasp the concept that private keys have to be kept private, cannot be trusted to do anything but screw up the most basic security provisions when writing code.
  Welcome to OpenSource, where security isn't understood and creating lots of threads is "multi-threading". At least Linus is very strict and will break any bad-programmer's ego.
45. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-25 18:09 · Score: 0
  
  what about bitbucket? that's free even for private repos.
46. Re:This is why developers are not sysadmins by DarwinSurvivor · 2013-01-25 21:30 · Score: 1
  
  That depends how many other peoples systems (like your work perhaps) trust your private key.
47. Re:This is why developers are not sysadmins by beefsack · 2013-01-26 03:16 · Score: 1
  
  Real developers and real sysadmins are one and the same. For any non-trivial project, hardware and software are highly dependant on each other.
48. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-26 12:29 · Score: 0
  
  Bitbucket.
49. Re:This is why developers are not sysadmins by Anonymous Coward · 2013-01-27 00:01 · Score: 0
  
  All developers should have mandatory code review anyway, it incredibly improves the code's quality. If you see code review as a measure of punishment, something is cleary wrong with your development attitude.
Lol by Anonymous Coward · 2013-01-25 01:55 · Score: 1

'nuff said.
Deserving by Anonymous Coward · 2013-01-25 02:01 · Score: 1

Developers (using the term loosely) deserve whatever ill comes from checking in private keys. Public repo or otherwise
1. Re:Deserving by GameboyRMH · 2013-01-25 02:04 · Score: 5, Insightful
  
  Exactly, GitHub shouldn't disable a site feature to protect the stupid.
  
  --
  "When information is power, privacy is freedom" - Jah-Wren Ryel
2. Re:Deserving by Anonymous Coward · 2013-01-25 04:11 · Score: 1
  
  +5 Insightful? More like +5 Opinionated. Seriously modders, I fail to see anything insightful in that one-liner.
3. Re:Deserving by Anonymous Coward · 2013-01-25 04:34 · Score: 0
  
  +5 Insightful? More like +5 Opinionated. Seriously modders, I fail to see anything insightful in that one-liner.
  +5 Opinionated? I agree thatt it's not be Insightful, but it's more Obvious than Opinionated.
4. Re:Deserving by ilsaloving · 2013-01-25 06:52 · Score: 2
  
  I have to say I agree. We need to stop coddling people who do mindblowingly stupid things.
  Let them post their private keys. Let them learn the hard way what happens.
  Same with people who steady a scalding cup of coffee by putting it between their legs, while driving no less.
  I don't even WANT to know what prompted the warning label on a toilet brush that stated, "Not to be used for personal hygiene".
  Bring back lawn darts, kinder eggs and buckyballs, remove the warning labels from everything, and add a law that prevents people from being allowed to sue after doing something dumb (where 'dumb' is decided on by a jury of peers) and let the problem sort itself out.
5. Re:Deserving by Bengie · 2013-01-25 09:25 · Score: 1
  
  Protecting the stupid from themselves is just enabling them to continue to be stupid. Let them learn from their mistakes or let Darwin take over.
6. Re:Deserving by HiThere · 2013-01-25 13:29 · Score: 1
  
  I'd say oblivious, and deserves a -5, not a +5.
  The developers aren't the only people at risk here. Anyone who checks out the development tree is at risk. And just having the source code doesn't automatically protect you. You aren't very likely to go over the code with a fine toothed comb. And even if you did, it would be quite easy to miss an inserted "mal-feature". (I can't really call it a bug, since I'm thinking of code that was doing what it was intended to do, just not what *you* intended it to do.)
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
Search engines by ArsenneLupin · 2013-01-25 02:02 · Score: 5, Informative

On google, the following search string still turns up a goldmine...:
site:github.com inurl:id_dsa
Idiots...
1. Re:Search engines by robmv · 2013-01-25 02:16 · Score: 4, Funny
  
  Stop, Google will shutdown search because of that
2. Re:Search engines by ArsenneLupin · 2013-01-25 02:25 · Score: 2
  
  Actually, in the glory old days of SQL injection, google did shut down search for certain patterns (such as inurl:cfm inurl:page_id or inurl:asp inurl:password). If you did too many searches for these, you got a captcha to prove that you were not a "bot"...
3. Re:Search engines by Ysangkok · 2013-01-25 02:54 · Score: 1
  
  intitle:index.of used to work better too, though it kinda works today; I'm surprised.
4. Re:Search engines by ArsenneLupin · 2013-01-25 03:12 · Score: 1
  
  intitle:index.of
  Interesting, it still finds lots of music. Weird that the MAFIAA hasn't discovered this yet, and sent them lawyer's love letters...
  On a hunch, I tried my own search terms too, an I was quite surprised to notice that inurl:cfm inurl:page_id has several vulnerable sites on its second page...
5. Re:Search engines by ArsenneLupin · 2013-01-25 03:16 · Score: 1
  
  ... and intitle:index.of confidential finds loads of pages too (most are false positives, but the very first one is definately "the real thing"..)
6. Re:Search engines by Anonymous Coward · 2013-01-25 04:06 · Score: 1
  
  In the really old days of the internet, you could do a search for root: and turn up a bunch of /etc/passwd files of boxes that set httpd to reply to anything. And if it was the REALLY old days, you could even use that information!
7. Re:Search engines by tlhIngan · 2013-01-25 05:04 · Score: 4, Interesting
  
  Heck, Google disabled searching number ranges after some enterprising folks used them to harvest credit card numbers - doing searches for numbers between 4000000000000000 and 5999999999999999 which will get back lists of credit cards (Visa/MC) that Google indexed because someone put the list up.
8. Re:Search engines by Anonymous Coward · 2013-01-25 07:54 · Score: 0
  
  Looks like someone is flirting with 100 years in prison...
9. Re:Search engines by 1729 · 2013-01-25 08:43 · Score: 1
  
  Mikko Hypponen recently posted an example of such a search query:
  https://twitter.com/mikko/status/287615660115243009
  (Don't worry; the "instaban" only affects that query; subsequent searches will still work.)
Proof... by Ignacio · 2013-01-25 02:02 · Score: 1

...that even (supposedly) smart people can be stupid.
1. Re:Proof... by Anonymous Coward · 2013-01-25 02:08 · Score: 0
  
  ...that even (supposedly) smart people can be stupid.
  Or caught with Smartie Pants down.
2. Re:Proof... by VortexCortex · 2013-01-25 02:09 · Score: 2
  
  I'm sorry, were you under the assumption that idiots can't write code?
3. Re:Proof... by sdnoob · 2013-01-25 02:18 · Score: 1
  
  I thought most of those lived in or near Redmond, WA and Redwood City, CA.
4. Re:Proof... by Lisias · 2013-01-25 02:27 · Score: 1
  
  In a environment where idiots write code, you will never see a coder calling "idiot" to another.
  Been there, saw that.
  (I got fired, by the wat - I wasn't idiot enough!)
  
  --
  Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
5. Re:Proof... by ArsenneLupin · 2013-01-25 02:29 · Score: 1
  
  Visual Basic monkeys live all over the world unfortunately. Only the jumping monkey lives in or near Redmond...
6. Re:Proof... by Anonymous Coward · 2013-01-25 02:38 · Score: 0
  
  That's so '90s. The current putdown phrase is "Javascript monkeys".
7. Re:Proof... by Anonymous Coward · 2013-01-25 03:42 · Score: 1
  
  you will never see a coder calling "idiot" to another ... Been there, saw that... by the wat
  
  I wasn't idiot enough!
  Maybe you were...
8. Re:Proof... by osu-neko · 2013-01-25 08:11 · Score: 1
  
  Everybody is stupid. But not equally so -- the extremely stupid believe the previous statement is false, and that they are among the exceptions.
  
  --
  "Convictions are more dangerous enemies of truth than lies."
9. Re:Proof... by ArsenneLupin · 2013-01-25 12:54 · Score: 1
  
  I wasn't idiot enough!
  Maybe you were...
  It depends. In some jurisdictions, being fired gives you rights to extra compensation, so it may be better to be fired rather than resigning...
  Moreover, being fired gets you unemployment benefit, whereas resigning doesn't.
  So the smart move may indeed be to show how smart you are, and cause yourself being fired. Of course, it all depends on the circumstances, as being fired rather than resigning dimishes your chances of finding a job elsewhere.
10. Re:Proof... by Lisias · 2013-01-28 02:12 · Score: 1
  
  It was a smart move.
  I ended up in a job with a lesser payment (probably because of the laid off), but 6 months later when a LOT of guys were fired (the company decided to shrink the department - somewhat I had envisioned by my previous experiences in this field), I already was employed, with my bills being paid, while a couple dozen of professionals (a very few of them so good or better than me) were struggling for a new position in the market.
  I'm not a profet, I didn't knew for sure if the department will be, in fact, shrinked in the near future (and even by being shrinked, there was a chance of me being picked up to stay). But I didn't knew for sure if this mess can be prevented, and decided to play safe.
  I was right this time (and a couple of other times).
  Of course there was a time when I was wrong, but historically it appears I'm right a lot more than I'm wrong, so the net value is positive by now.
  
  --
  Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
WTF? by n1ywb · 2013-01-25 02:04 · Score: 1

Thanks for taking away valuable functionality to protect idiots from themselves. O_o

--
-73, de n1ywb
www.n1ywb.com
1. Re:WTF? by Threni · 2013-01-25 02:11 · Score: 1
  
  Well, they're also protecting you (potentially) from the actions of idiots.
I just saw this, sort of by slashmydots · 2013-01-25 02:04 · Score: 5, Interesting

I was cruising ebay yesterday and saw that one of the laptops had their windows license keys exposed in pictures in a readable format. I poked around some more and found that isn't terribly uncommon. Some people just don't think no matter what website it is.
1. Re:I just saw this, sort of by Anonymous Coward · 2013-01-25 02:22 · Score: 0
  
  It gets even dumber than that. Years ago people used to sell new copies of windows XP on ebay and have a picture of the license key. I have installed many copies of XP from a single XP cd by just searching eBay on Windows XP new.
2. Re:I just saw this, sort of by Anonymous Coward · 2013-01-25 02:52 · Score: 0
  
  I was crusing adult friend finder yesterday and saw that one of the girls had her breasts exposed in pictures. I poked around some more and found that isn't terribly uncommon. Some people just don't think no matter what website it is.
3. Re:I just saw this, sort of by antdude · 2013-01-25 03:37 · Score: 1
  
  Same thing on computers' case labels like at work.
  
  --
  Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
4. Re:I just saw this, sort of by tlhIngan · 2013-01-25 05:13 · Score: 1
  
  I was cruising ebay yesterday and saw that one of the laptops had their windows license keys exposed in pictures in a readable format. I poked around some more and found that isn't terribly uncommon. Some people just don't think no matter what website it is.
  Those aren't actual working keys, though most of the time. Usually on machines from the big guys, they're nonworking keys - because the real activation key is built into the BIOS. For earlier (pre-Vista) versions of Windows, they would require manual activation if you used them. Vista and afterwards, every version includes the BIOS check code that gets the license information.
  For OEM keys though, they may work, depending on how Microsoft is verifying, but after a couple of times it's locked out... but those are often only on whitebox OEM PCs.
5. Re:I just saw this, sort of by Anonymous Coward · 2013-01-25 05:45 · Score: 0
  
  I just used to install the corporate XP and generate my own VLKs. No activation to bother with, always checks out 100% genuine and it's a fuckload more honest than stealing some poor sods keys off of ebay.
6. Re:I just saw this, sort of by Anonymous Coward · 2013-01-25 05:48 · Score: 0
  
  It's not like you can use en OEM sticker key for anything much anyway.
  Besides, these days, just use the "secret" OEM keys, which are the same on any computer a certain OEM ships and easy to read out, together with the cert-file (also easy to read out of an OEM preinstall) and the SLIC 2.1 BIOS portion (or loader) and your all set.
  No hacking, no patching (except if you have to put the SLIC in the BIOS), no stealing codes of ebay.
7. Re:I just saw this, sort of by Anonymous Coward · 2013-01-25 05:53 · Score: 0
  
  I was googling geocities and angelfire the other decade, and found pretty much the same thing, but much less commercialized. Awesome times bro.
8. Re:I just saw this, sort of by PRMan · 2013-01-25 07:55 · Score: 1
  
  Those keys only work with the DELL or HP key, don't they? They're not actual Windows keys that could be typed into a new installation.
  
  --
  Peter predicted that you would "deliberately forget" creation 2000 years ago...
9. Re:I just saw this, sort of by zppln · 2013-01-25 09:04 · Score: 1
  
  More like, some people don't have a fucking idea what a product key is because they just see the computer as a means to an end (no matter of trivial that end might be) instead of as something to build their entire life and career around. Shocking, I know.
10. Re:I just saw this, sort of by Anonymous Coward · 2013-01-25 10:08 · Score: 0
  
  Any generic OEM install will accept the key.
Problem? by Anonymous Coward · 2013-01-25 02:05 · Score: 0

I don;t understand the issue.
It's all very cloudy to me.
Look at the pic by Anonymous Coward · 2013-01-25 02:06 · Score: 0

None of these "private key" files in the posted pic on Twitter actually contain any key data
How many of those are Rails projects? by Anonymous Coward · 2013-01-25 02:06 · Score: 0

Hey, let's be so lazy that user_id=1 is always the Admin user! Ohmygosh it makes testing so much easier and that all that matters!
Works on sourceforge too... by ArsenneLupin · 2013-01-25 02:07 · Score: 2

inurl:sourceforge inurl:id_dsa -inurl:id_dsa.pub
overreaction? by __aaltlg1547 · 2013-01-25 02:10 · Score: 3, Insightful

Seems like the wrong response. Instead of killing search, why not just erase the keys files and lock out the accounts of the offending devs?
1. Re:overreaction? by h4rr4r · 2013-01-25 02:19 · Score: 3, Insightful
  
  Because some of these might be test keys or place holders. If the key is not valid on any system and is just test data, it should not be a big deal to post publicly.
2. Re:overreaction? by Anonymous Coward · 2013-01-25 02:22 · Score: 0
  
  That's just silly. Github shouldn't go about banning people because of how they run their own projects. And they can't just go erasing important files out of someones repos either.
3. Re:overreaction? by KPU · 2013-01-25 02:22 · Score: 1
  
  Some projects deal with SSH keys and include them for testing purposes: https://github.com/trolldbois/sslsnoop/blob/master/test/id_dsa-1.key
4. Re:overreaction? by Anonymous Coward · 2013-01-25 02:29 · Score: 0
  
  Yes, it's the wrong response in that it's not a response. Search being down is unrelated, RTFA.
5. Re:overreaction? by Bogtha · 2013-01-25 02:44 · Score: 1
  
  Example: the keys for Vagrant. Vagrant is a system for managing virtual machines for development purposes. The ssh keys are used to facilitate passwordless login. They aren't typically exposed to the outside world, and they are clearly labelled as insecure.
  
  --
  Bogtha Bogtha Bogtha
6. Re:overreaction? by h4rr4r · 2013-01-25 03:02 · Score: 1
  
  That thing should really generate new ones on install.
  That way there are no keys to expose to the world that anyone would know.
7. Re:overreaction? by Bogtha · 2013-01-25 03:47 · Score: 1
  
  One of the things people do with it is build base boxes, which are preconfigured virtual machines, and share those base boxes for other people to build upon. In order to do so, the people who receive these base boxes need the private keys they are configured with.
  You could distribute the private keys with the base boxes, I suppose, but then you are stuck sharing multiple files instead of just one, and you can't install a base box by running one single command with a URL argument any more. It increases the complexity.
  
  --
  Bogtha Bogtha Bogtha
8. Re:overreaction? by Anonymous Coward · 2013-01-25 04:03 · Score: 0
  
  Why not let people check what they want into source control? It isn't their fuckin' problem.
9. Re:overreaction? by Anonymous Coward · 2013-01-25 05:11 · Score: 0
  
  It increases the complexity.
  Yes, proper security increases the complexity, which is why (1) it's so often lacking and (2) so many boxes in the field have default passwords and keys and are owned by hackers.
  
  ... the people who receive these base boxes need the private keys they are configured with.
  Ship with the keys loaded on a USB key taped to the box?
  Physical lock manufacturers don't ship with a default key and expect you to set the code yourself and make your own keys, they ship along with the keys. I'd bet they'd look at you funny if you asked them if that was too complex.
10. Re:overreaction? by Bogtha · 2013-01-25 05:52 · Score: 1
  
  I think you've misunderstood. A base box is a virtual machine. A digital file. They are run during development. They aren't production servers that other people access, and they aren't physical hardware.
  
  --
  Bogtha Bogtha Bogtha
11. Re:overreaction? by h4rr4r · 2013-01-25 07:58 · Score: 1
  
  People will use them in production, it will happen.
  Best to have the machine regenerate keys on first boot and make the user go get them.
12. Re:overreaction? by petsounds · 2013-01-25 13:02 · Score: 1
  
  I think the summary is wrong. status.github.com seems to indicate that github's search cluster died, not that they took it down. More likely is that there was a flood of search requests for private keys at the same time and the search cluster buckled.
Stupid people... by Lisias · 2013-01-25 02:18 · Score: 3, Insightful

These stupid people should be had their accounts suspended.
People should be accountable for their actions, and these idiots are potentially compromising third party data security!
ICO didn't fined Sony for the information leak on that Anonymous attack? Why in hell GITHUB user's should be less accountable for things THEY ARE FSCKING COMMITING in their accounts?

--
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
1. Re:Stupid people... by gajop · 2013-01-25 02:47 · Score: 1
  
  Why would they have their accounts suspended? It's their right to share that.. even if it's pretty stupid.
  I assume search will be back eventually, it's probably just a temporary measure until they implement ways to inform the users of a potential common* misstep.
  *It really is common when you see hundreds~thousands of .ssh and .bash_history files.
2. Re:Stupid people... by Anonymous Coward · 2013-01-25 03:57 · Score: 0
  
  Not far enough, they should be doused in gasoline and BURNED!
3. Re:Stupid people... by trev.norris · 2013-01-25 06:44 · Score: 1
  
  Yeah, because everyone that posted a private key "compromis[ed] third party data". And it's totally not possible that some were posted for other reasons
  Please, next time think before you speak.
4. Re:Stupid people... by Lisias · 2013-01-25 14:28 · Score: 1
  
  You put a automated test in the same basket as an idiot that commit private keys to God knows what, and tells ME to think?=P
  
  --
  Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
5. Re:Stupid people... by Lisias · 2013-01-25 14:34 · Score: 1
  
  Why would they have their accounts suspended?
  Why should, then, GITHUB shutdown a useful feature (the search!) in order to prevent data mining over that keys?
  Pretty stupid or not, GITHUB is hurting everybody because of them.
  So, or GITHUB are pretty stupid bastard themselves, or some of these keys can cause some serious havoc. I stand what I said : identify and suspend the idiots instead of fscking everybody!
  
  --
  Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
6. Re:Stupid people... by Anonymous Coward · 2013-01-26 19:07 · Score: 0
  
  Oh grow up already
7. Re:Stupid people... by Anonymous Coward · 2013-01-27 07:21 · Score: 0
  
  Virtual sex doesn't appeals me.
  Feel free to offer your ass to someone near you while thinking on me. :-)
github did not take search down because of this by Anonymous Coward · 2013-01-25 02:19 · Score: 2, Informative

According to their twitter and status pages, the search is currently unoperational due to problems with their search cluster. They recently released changes to their search including, I believe, a move to ElasticSearch. The linked article says as much, too, so yet another fail in a slashdot summary.
Nothing has changed... by 140Mandak262Jamuna · 2013-01-25 02:25 · Score: 5, Funny

Back in the days when I was the root (of all evil according my fellow grad students) of our lab, one of the constant problems was people blindly doing chmod 777 .* on the $home. They have .emacs or .profile or .cshrc that was customized ages ago by some grad student, and they want to share it with a new student. Somehow they stumbled on to "chmod 777 .*" as a solution to all their file sharing problems. Now this "magic command" was also being blindly passed around without worrying about security implications. Oh, yeah, they think they are clever and tape the login credentials to the underside of the keyboard and laugh at secretaries who tape it to their monitors.
Looks like these grad students have all growned up and uploading it all to the cloud.

--
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
1. Re:Nothing has changed... by h4rr4r · 2013-01-25 02:38 · Score: 2
  
  When people did stuff like that in my sysadmin classes we were encouraged to teach them a lesson. Far better to edit their login script to log them right back out than delete their homedir contents, or change their path so they got other versions of common programs. Probably the meanest was to make it so instead of calling the work submission script it called rm on whatever they were trying to submit as their classwork.
2. Re:Nothing has changed... by Frohboy · 2013-01-25 03:09 · Score: 2
  
  A subtler prank that I pulled on a friend who left himself logged in to one of the public undergrad labs (where there was the risk that an actual asshole would delete your stuff, send email as you, or something similarly cruel) was to add "echo 'sleep 1' >> .cshrc" to the end of his .cshrc before logging him out. I chuckled to myself, and then forgot about it.
  A week later, when it was 5 minutes before a submission deadline and he was yelling at the terminal to finish logging in (since it was taking 2-3 minutes for the prompt to appear by that point), I realized that I had probably gone too far.
3. Re:Nothing has changed... by WankersRevenge · 2013-01-25 03:10 · Score: 4, Funny
  
  Yeah ... I was "that guy". The first time I installed Linux in 2000, I was annoyed that I needed "permission" to write to a directory outside of my home directory. I was coming from a Windows world, after all.
  I solved this "problem" by chmod 777 the entire filesystem. Hah. Problem solved. Needless to say, I couldn't start the machine back up again. I'm guessing it killed itself from the shear embarrassment. After that, I decided it may be in my best interest to read the manual.
  I'll do that one of these days :)
4. Re:Nothing has changed... by Anonymous Coward · 2013-01-25 03:41 · Score: 0
  
  This is the reason that modern versions of ssh will refuse to use a private key if it is world-readable. (Of course, people who are just smart enough will chmod it back instead of generating a new key.)
  Perhaps it is time to take the bold step of ensuring that user-private keys aren't owned by the user since obviously users can't be trusted to protect their own assets.
5. Re:Nothing has changed... by 140Mandak262Jamuna · 2013-01-25 04:43 · Score: 1
  
  Users want to protect their assets. Often, they don't know what their assets are. For the biomedical researcher, the assets are her experimental results and literature survey etc. Does not even know that these credentials are valuable to some other people in a different universe.
  This is common even in other walks of life. I see a few of my colleagues routinely bringing their passports in their brief ases they lug to work. They constantly open it to retrieve reading materials, music players, etc in the bus. Many fellow commuters would have noticed the prominently placed passport in one of the pouches. They don't seem to realize a valid US passport fetches thousands of dollars in the black market. It is not that they would be asked to undertake a foreign trip without a chance to go home to pack the toothbrush and grab the passport. Then why do they casually carry around the passport? They don't see it the way a criminal would. The biology major does not look at her $home files the way a hacker would.
  
  --
  sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
6. Re:Nothing has changed... by Anonymous Coward · 2013-01-25 05:10 · Score: 0
  
  Wait, how could he not notice it getting slower before? I know that the amount of sleep time would increase exponentially, but still it would only take 2^(x-1) logins to get to that time. Either it would not have taken so long to login, or he would have noticed it earlier.
  Then again, I've seen a person who thinks that if you want a dvd to work, you have to blow on the label side, because she saw her son do it once (probably on accident).
7. Re:Nothing has changed... by xaxa · 2013-01-25 05:20 · Score: 3, Interesting
  
  Someone in my class installed a game in the officially-public network share. He was writing an AI for it, for a project. Other students found it, and played it.
  It had taken a lot of hacking to get the game to run on Linux, and he was annoyed other students had played it without putting in that effort. So, he altered the 'start.sh' script to generate an ssh key, add the public part to the user's authorized_hosts file, and move the private key somewhere obscure.
  He then got bored with the AI project.
  Some time later, while helping in a tutorial, I was showing a student how to set up an SSH key. The authorized_keys file already contained about 20 entries. The AI guy was sitting at the next computer, and told me what he'd done (I knew him quite well, but he hadn't told me what he'd done until now). He found over 200 private keys in the obscure place. He deleted them, chown -R go-rwx'd the game, and we thought that was the end of it...
  About a year later, Debian had that OpenSSL bug. The sysadmins ran a script across everyone's authorized_keys file, and removed any entries from keys generated by Debian OpenSSL. The email ended (I still have it):
  
  By the way: some of you have FAR TOO MANY authorized_keys ENTRIES
  and we seriously recommend that you radically shrink these down.
  As I said, we recommend kerberos tickets or ssh-agent instead!
  ...so I don't think they knew how they got there.
8. Re:Nothing has changed... by swillden · 2013-01-25 05:46 · Score: 1
  
  It's probably obvious and I'm just being stupid, but I can't think what you could possibly break by setting all perms to 777. Yeah, you'll mark a bunch of non-executable files as executable, but nothing should be trying to execute them anyway. There may be a few files (like /etc/passwd|shadow) which some components might refuse to use if they're world-readable, I suppose...
  Any idea what broke?
  BTW, my similar story: I purchased a NeXT machine in 1991. It came with a 110 MB hard drive, which wasn't a lot of space even then. I quickly ran out and so I started looking for stuff that I could delete to save space. I found that a big chunk of my disk space was consumed by ".so" files in various "lib" directories. Clearly they were files that I never used, so I deleted them. The system kept running, for a little while...
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
9. Re:Nothing has changed... by ctr2sprt · 2013-01-25 05:56 · Score: 1
  
  It's probably obvious and I'm just being stupid, but I can't think what you could possibly break by setting all perms to 777.
  Anything with the sticky, setuid, or setgid bits set.
10. Re:Nothing has changed... by Mathematiker · 2013-01-25 05:59 · Score: 2
  
  chmod'ing 777 kills the setuserid-bit.
  This means that programs like "su" or "ping" or "passwd" break.
  Also, some important daemons probably check whether their required files are world-writable and refuse continuing...
11. Re:Nothing has changed... by swillden · 2013-01-25 06:50 · Score: 1
  
  chmod'ing 777 kills the setuserid-bit.
  Duh. I knew it was something obvious. Thanks.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
12. Re:Nothing has changed... by Darinbob · 2013-01-25 08:45 · Score: 2
  
  I hate that attitude though. I told a friend once that I didn't use authentication with X windows because no one is ever going to bother to interfere and I didn't care if anyone was snooping. So he went out and decided to pop up random pictures on my screen and post messages until I relented. So I wasted a lot of time learning all about authentication and configuring it correctly, not to keep out adversaries but to keep out friends...
13. Re:Nothing has changed... by Anonymous Coward · 2013-01-26 10:36 · Score: 0
  
  Aahahaha oh my god that's amazing.
14. Re:Nothing has changed... by robsku · 2013-01-26 19:41 · Score: 1
  
  BTW, my similar story: I purchased a NeXT machine in 1991. It came with a 110 MB hard drive, which wasn't a lot of space even then. I quickly ran out and so I started looking for stuff that I could delete to save space. I found that a big chunk of my disk space was consumed by ".so" files in various "lib" directories. Clearly they were files that I never used, so I deleted them. The system kept running, for a little while...
  LOL, I did the equivalent with MS-DOS 5 on family IBM PS/1 with 30MB HD - luckily the system had IBM DOS 4 on ROM drive which you could boot if there was no bootable system installed on HD. Don't remember how we got it to not try and boot from HD but still make it available (so we could fix it).
  
  --
  In capitalist USA corporations control the government.
Lol by DontBlameCanada · 2013-01-25 02:26 · Score: 1

Security IQ test question 1: "Ensure all private keys are are stored in a secured location."
"Oh sh**..."
Open Secret Server to the rescue! by herberts · 2013-01-25 02:47 · Score: 1

This is exactly the problem OSS (http://github.com/hbs/oss) is trying to solve!
Deleting files is shockingly hard in git by bsberman · 2013-01-25 02:51 · Score: 1

Maybe if it weren't so goddamned complicated to remove a file from the history of git, this wouldn't happen. Explain to me, in a series of commands, how I would remove a hypothetical "secret_keys.txt"?
1. Re:Deleting files is shockingly hard in git by Anonymous Coward · 2013-01-25 03:00 · Score: 0
  
  dd if=/dev/zero of=/dev/brain
2. Re:Deleting files is shockingly hard in git by Anonymous Coward · 2013-01-25 03:05 · Score: 0
  
  https://help.github.com/articles/remove-sensitive-data
  It's difficult to impossible to do it when someone has already cloned your repository.
3. Re:Deleting files is shockingly hard in git by Anonymous Coward · 2013-01-25 03:08 · Score: 0
  
  Much easier than in SVN (which it is, AFAIK, impossible)..
  git filter-branch --index-filter 'git update-index --remove secret_keys.txt' ..HEAD
  git push --force --verbose --dry-run
  git push --force
4. Re:Deleting files is shockingly hard in git by Anonymous Coward · 2013-01-25 03:17 · Score: 1
  
  Here's a guide! https://help.github.com/articles/remove-sensitive-data
5. Re:Deleting files is shockingly hard in git by Anonymous Coward · 2013-01-25 08:34 · Score: 0
  
  That doesn't seem to be doiformsopi3807xzcg;jlP*U#NXLJFCPOIJE#)*U)8708$
  Connection reset by peer (PBKAC)
This demonstrates a critical flaw... by Junta · 2013-01-25 02:53 · Score: 1

This happens both in private and publicly developed projects. All too often the developers do not grasp the fundamentals of security. If lucky, they grasp 'enable encryption' but it's exceptionally rare for them to understand things like mutual authentication and appropriate key management or even why a backdoor or fixed credential is very very bad news. The 'answer' in many companies is to tack on a 'security expert' to audit the code and do some penetration testing. While this is certainly not a bad idea, the security expert who is not a developer can only do so much. Additionally, that security specialist frequently ends up with an antagonistic relationship to the other developers because the developers will want to do things the ludicrously insecure easy way and the security specialist, conversely, will impose security but without much perspective for making the security as easy as it could be. As a common example, take SSL. Many developers will say 'enable SSL because it is secure, but disable all cert checking because it's beyond us'. SSL is nearly useless in that scenario. Security person comes in and rightly notices this is a dumb idea. Security person then forces develoers to turn their project into nagware so that user is well warned about the threat and maybe the user will do something like carefully curate their certificate management to avoid the nag, when in practice the user just trains to always click 'ok'. Meanwhile, a third option of secure, automated PKI chaining off some other solid trust relationship is missed because the required understanding and perspective are not shared among enough of the developer base.

The only way software can be entrusted to do things moderately secure is if solid principles of security are pervasive in the minds of all the developers. Then good security practices are done and frequently in a manner that is extremely unobtrusive to the user.

--
XML is like violence. If it doesn't solve the problem, use more.
Not so many by Shimbo · 2013-01-25 02:58 · Score: 3, Insightful

Hundreds of keys from a million accounts; less than one in a thousand developers screwed up. Call a doctor at once! Then ask him about outliers in large populations.
1. Re:Not so many by darkmeridian · 2013-01-25 04:49 · Score: 1
  
  Well, you have to consider quality over quantity. There may only be less than one in a thousand developers who screwed up but what if the keys that were exposed belong to super-important servers such as those that control Google Chrome source code or some other big project?
  
  --
  A NYC lawyer blogs. http://www.chuangblog.com/
2. Re:Not so many by phantomfive · 2013-01-25 04:50 · Score: 1
  
  But how many of those developers have projects that need private keys? None of mine currently do.
  
  --
  "First they came for the slanderers and i said nothing."
3. Re:Not so many by Anonymous Coward · 2013-01-25 10:15 · Score: 0
  
  What's really interesting is that the observer effect is bringing even the outliers in line.
A big mess to clean up by NightHwk1 · 2013-01-25 03:06 · Score: 4, Informative

git rm id_rsa*; git commit -a -m "problem solved\!"
Not quite. They're already out there. The keys are still in the revision history. People have forked and cloned it.
Hopefully the developers who created these keys know that besides removing them from the repo, the keys can no longer be used. They must be removed from every .ssh/authorized_keys file, every service like Github that uses them for deploying code, etc.
1. Re:A big mess to clean up by rdnetto · 2013-01-27 20:06 · Score: 1
  
  Github is officially denying that the search feature being killed has anything to do with the exposure of keys. They also have a link on the same page to information on how to purge keys from your repository. (Make of that what you will.)
  
  --
  Most human behaviour can be explained in terms of identity.
Proof Github took search down? by gajop · 2013-01-25 03:09 · Score: 2

This doesn't suggest github took anything down on purpose: https://status.github.com/messages.
Seems to me they were just experiencing some technical difficulties from all the people sharing those search links and having a laugh at the stupids...
I skimmed over the github site and didn't find anything that would suggest otherwise at least.
Of course I didn't read the articles because they seem badly misinformed and confuse private keys with passwords.
Hard Coding does its lethal work by Stirling+Newberry · 2013-01-25 03:09 · Score: 1

Any wonder why I make factor passwords and keys a coding standard?

--
Fugue for Aaron Swartz
Github and Zshell history files... by afxgrin · 2013-01-25 03:10 · Score: 1

Interesting how just last night this post about Arch users being pedos showed up on 4chan. Someone had uploaded their zshell history file into the repository and OP happened to notice it. Today Github announces search is being killed...
1. Re:Github and Zshell history files... by computational+super · 2013-01-25 07:02 · Score: 1
  
  Man, how bored do you have to be to start stepping through somebody else's bash history file? Yikes.
  
  --
  Proud neuron in the Slashdot hivemind since 2002.
So... by Anonymous Coward · 2013-01-25 03:11 · Score: 0

Are people going to be demanding a class action lawsuit against the administrators of GitHub for "failing to protect their security," or is that only reserved for Sony and other hatreds-du-jour?
1. Re:So... by Anonymous Coward · 2013-01-25 04:14 · Score: 0
  
  Considering that those people didn't pay anything, and that it's their own damn fault in the first place for being idiots, probably not. It's the same as posting your id_rsa on pastebin (which people also do).
Reminds me of printers and searches by Anonymous Coward · 2013-01-25 04:27 · Score: 0

Here's an exercise: Remote into your favorite printer's web interface and find a unique short string of text on the front page. Search that in Google with quotes and be amazed at how many people have the web interface for their printers completely exposed to the internet with a public IP. I don't even know how this could happen without deliberately doing it.
Not exclusive to github. by Anonymous Coward · 2013-01-25 04:49 · Score: 0

https://encrypted.google.com/search?hl=en&q=site%3Abitbucket.org%20id_rsa ...
More stupid Americans by Anonymous Coward · 2013-01-25 05:19 · Score: 0

"Users found THAT quite a large number of users WHO HAD added private keys to their repositories AND THEN pushed the files up to GitHub."
And where's the rest of the sentence?
"I saw THAT my dog, WHO HAD chased a rabbit AND THEN gone to sleep..."
See?
Bloody Americans, can't even understand the words "that", "than" and "then". Idiots.
Idiots by pouar · 2013-01-25 05:26 · Score: 1

Those users are idiots. GitHub shouldn't shutdown the search funtion over this. It's their users' own fault for storing private keys in a public repo.

--
while :;do if windows sucks;then mv windows /dev/null;pacman -Sy linux;fi;done
so they remove there search? use google by Anonymous Coward · 2013-01-25 05:38 · Score: 0

Google search
site:github.com "id_rsa"
really them removing the search option does nothing now that is known.
That's not why the search was down. by Anonymous Coward · 2013-01-25 10:59 · Score: 0

https://github.com/blog/1390-secrets-in-the-code
"I also want to clarify that our code search results being unavailable is unrelated to this issue. Our operations team has been working on repairing and tuning the code search cluster. We will continue to update our status site with updates on our progress. We will also be publishing a detailed post-mortem on the code search availability issues next week."
Follow up - Github MITM attack this weekend? by cloudshark · 2013-01-28 07:53 · Score: 1

We've been looking for a Slashdot article about this, but over the weekend there was an apparent MITM attack on Github, from China. Someone posted it to our online packet capture viewer tool and it has been exploding every since: http://www.cloudshark.org/captures/cbdd11b20a5c Has anyone seen an article about this yet?