From the ‘If you leave the keys out in the open it’s your own fault’ files:
Github rolled out a new search tool today making it easier to not just discover new projects, but code within projects. Think Google Code search (when it was alive, but better).
So the TL;dr version is – awesome power. But as Spiderman taught me a long time ago, with great power comes great responsibility.
Remember Google Hacking? It’s still alive and well – but let’s call it Github Hacking now. This is a problem that a few people have now noticed and a simple search can easily pull up more results than I care to count.
One of the funniest things I’ve seen is Github user Postmodern open an issue on one user’s public tree for including a Pidgin IM password.
“Bro, you accidentally committed .purple/accounts.xml which contains all of your accounts and passwords,” the issue report states. “Might want to remove the file and change all passwords, otherwise your gonna have a bad time.”
It’s important to note that this is NOT a Github security issue. This is a BONEHEAD security issue. If you upload security information (keys/passwords etc) to a public repository, they will be discovered. All that Github search is doing is exposing what is already there – it isn’t creating the problem.
The hard part (I know..) for some comes in database connectivity type passwords where the usr/pswrd info is directly included as part of application code. While this *might* be ok in a demo, it’s just poor coding practice to include user/pswrd in non-encrypted/hashed and salted formats cause eventually it will lead to trouble.
Reality with Github though is lots of folks (just look at that pidgin example) are ppl that use it as cloud/online storage and don’t think before they upload. I suspect that for at least the next month (if not more), Github will be a hackers playground for more reasons then it should be.