Re: Users Scramble as GitHub Search Exposes Passwords, Security Details

[Stephanie Daugherty <sdaugherty () gmail com>]

It's not terribly hard to remove something from git, but, in a public
repository, by the time you've caught and removed it, it is indeed too late
- there's no telling who might have retrieved it,

More lessons to learn:
-  Protect your SSH keys with pass-phrases and use a ssh-agent if you can't
be bothered typing them in. This will at least buy a little time if they
get exposed.
- Private keys should only reside on workstations that you physically
control. Agent forwarding should be used for intermediary systems.
- Private keys should be present only on one workstation, so that you can
easily cancel access from a stolen device. Much better to have multiple
PUBLIC keys in the authorized_keys files on your server, that the same
PRIVATE key in multiple locations.
- Keys that must be shared for whatever reason, should not be your main
key.
- Consider a physical token for SSH keys if you are a high profile target -
such as a developer on a security-oriented and/or high visibility open
source project - at under $50 (US), the cost is much lower than the
man-hours that would be spent doing damage control if your key got into the
wild, and MUCH lower than the damage to you, and your project's reputation.

And specific to users of git and other version control
systems...particularly if you have public repositories
- Consider placing a .gitignore for sensitive data in your $HOME in case
you get any crazy ideas about uploading your settings to github...
- Rebuild things that might contain sensitive data by hand to make sure the
sensitive data's excluded - if you are making a template for your home
directories, make it in a clean directory or even a clean account, so that
you know exactly what's in there.
- Use git add properly, it's DESIGNED to keep this sort of thing from
happening - properly means naming every file you want in the change-set,
one at a time.
. Avoid using the shortcut git commit -a - it's easy to overlook something
you didn't mean to add. Take it out of your regular git vocabulary - the
only time it's appropriate is for mass renames, and then you should make
sure you have a "clean" working directory before you start.
- Don't git add entire add entire trees at once unless you are absolutely
sure what's in them. Initial imports of "uncontrolled" source files ALWAYS
require special caution to make sure that the import is clean - not just of
sensitive data, but also of compiler output, build system artifacts, and
other garbage that you don't want in your git repositories.






On Sun, Jan 27, 2013 at 9:47 PM, Jeffrey Walton <noloader () gmail com> wrote:

> From DG on the cryptography mailing list....
>
>
> http://www.webmonkey.com/2013/01/users-scramble-as-github-search-exposes-passwords-security-details/
>
> GitHub has temporarily shut down some parts of the site-wide search
> update it launched yesterday. As we mentioned in our earlier post, the
> new search tools made it much easier to find passwords, private ssh
> keys and security tokens stored in GitHub repos.
>
> GitHub hasn’t officially addressed the issue, but it appears to be
> blocking some of the security-related searches that were posted
> earlier in this Hacker News thread.
>
> GitHub’s status site also says that “search remains unavailable,”
> though in my testing searching worked just fine so long as you weren’t
> entering words like “RSA,” “password,” “secret_token” or the like.
>
> Most of the passwords and other security data exposed were personal —
> typically private ssh keys to someone’s server or a Gmail password —
> which is bad enough, but at least one appeared to reveal a password
> for an account on Chromium.org, the repository that holds the source
> code for Google’s open-source web browser. Another reportedly exposed
> an ssh password to a production server of a “major, MAJOR website in
> China.”
>
> Unfortunately for people that have been storing their private security
> credentials in public GitHub repos what GitHub’s search engine
> revealed is nothing new. Google long ago indexed that data and a
> targeted site:github.com search will turn up the same exposed security
> info, which makes GitHub’s temporarily crippled search a token gesture
> at best.
>
> If you accidentally stored sensitive data on GitHub the most important
> thing to do is change your passwords, keys and tokens. After you’ve
> created new security credentials for any exposed servers and accounts
> then you can go back and delete your old data from GitHub.
>
> Given that Git, the version control system behind GitHub, is
> specifically designed to prevent data from disappearing, deleting your
> sensitive data takes more than just the Git command rm. GitHub has
> full details on how to get your sensitive data off the site. As
> GitHub’s instructions say, “if you committed a password, change it! If
> you committed a key, generate a new one. Once the commit has been
> pushed you should consider the data to be compromised.”
> _______________________________________________
> Fun and Misc security discussion for OT posts.
> https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
> Note: funsec is a public and open mailing list.
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.