feature request

Hi everyone,

Just would like to request a security feature to help secure peoples github accounts more by supporting 2 factor authentication like the yubikey more information can be found from this link www.yubico.com/develop/ and googles 2 factor authentication. Hope it gets implemented as I think it would make a great feature

On Mon, Feb 18, 2013 at 1:52 PM, Jay Townsend <townsend891@hotmail.com> wrote:

This would most likely be something that users would set up with their SSH client, and GitHub would have to provide support for it on their servers as well. It shouldn't require any changes to git. Here is an example of how this could be done:

http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/

I like the idea, and I would probably use it if it were available. Jeff, what do you think?

On Mon, Feb 18, 2013 at 02:54:30PM -0500, James Nylen wrote:

When you are talking about something like GitHub, there are a lot of times and methods to authenticate: logging into the web service, using an ssh key for git-over-ssh, using a password for git-over-http, tokens for API access, and probably more that I can't think of right now.

Logging into the web page can add 2-factor auth pretty easily, since it's a web form.

Git over ssh can also do so without changes to git, because we rely on ssh to do all of the interactive authentication. However, I wonder how many people would be that interested in it, as key auth already provides some degree of two factor protection, assuming you protect your key with a passphrase (the threat model is different, of course, because the two factors are happening on the client, and do not involve the server at all).

Git over http _would_ need git client support, since it asks the user for the password directly. Or at the very least some clever encoding scheme where your password becomes "<real_password>:<2FA_pass>" or something. But I'm not sure that people want raw two-factor authentication for pushes. It's a giant pain, and people were recently happy to move to password-less pushes via credential helpers; this would move in the opposite direction.

The thing that makes 2FA usable in the web browser setting is that you authenticate only occasionally, and get a token (i.e., a cookie) from the server that lets you have a longer session without re-authenticating. I suspect a usable 2FA scheme for http pushes would involve a special credential helper that did the 2FA auth to receive a cookie on the first use, cached the cookie, and then provided it for subsequent auth requests. That would not necessarily involve changing git, but it would mean writing the appropriate helper (and the server side to match). I seem to recall Shawn mentioning that Google does something like this internally, but I don't know the details[1].

So yes. It's an interesting direction to go, but I think there's a fair bit of work, and it needs to be broken down into how specific services will interact with it. The first step would probably be securing the web login with it, since that is the easiest one to do, and also the most powerful interface (the other ones just let you push or fetch code; the web interface lets you delete repos, change passwords, access billing, etc).

But that first step is something that would happen entirely at GitHub, with no client support necessary. We don't have schedules or plans, and we don't promise features. So I can neither confirm nor deny that people are working on it right now.

-Peff

[1] I don't know if Google's system is based on the Google Authenticator
    system. But it would be great if there could be an open,
    standards-based system for doing 2FA+cookie authentication like
    this. I'd hate to have "the GitHub credential helper" and "the
    Google credential helper". I'm not well-versed enough in the area to
    know what's feasible and what the standards are.

On Mon, Feb 18, 2013 at 3:45 PM, Jeff King <peff@peff.net> wrote:

I don't know what the specific infrastructure they (Google's engineers) are using is (something written in python if I'm not mistaken), but @$dayjob we've managed to authenticate to Google Apps using SAML 1.1 & SAML2 wrappers "living" in both CAS and Shibboleth. SAML is a standard and is supported (in whole or in part) by a lot of systems and SSOs out there. Given the way that systems like that work I don't see Git authenticating that way any time soon (but I've been surprised before).

On Mon, Feb 18, 2013 at 12:45 PM, Jeff King <peff@peff.net> wrote:

Right, otherwise you spend all day typing in your credentials and syncing with the 2nd factor device.

...

Yes, it is based on the Google Authenticator system, but that's not relevant to how Git works with it. :-)

We have a special "git-remote-sso" helper we install onto corporate workstations. This allows Git to understand the "sso://" protocol. git-remote-sso is a small application that:

- reads the URL from the command line,
- makes sure a Netscape style cookies file has a current cookie for
the named host,
   - acquires or updates cookie if necessary
- rewrites the URL to be https://
- execs `git -c http.cookiefile=$cookiefile remote-https $URL`

The way 2FA works is the user authenticates to a special internal SSO management point in their web browser once per period (I decline to say how often but its tolerable). Users typically are presented this SSO page anyway by other applications they visit, or they bookmark the main entry point. A Chrome or Firefox extension has been installed and authorized to steal cookies from this host. The extension writes the user's cookie to a local file on disk. Our git-remote-sso tool uses this cookie file to setup per-host cookies on demand within the authentication period.

Horrifically hacky. It would be nice if this was more integrated into Git itself, where the cookies could be acquired/refreshed through the credential helper system rather than wrapping git-remote-https with a magical URL. I am a fan of the way our extension manages to get the token conveyed automatically for me. Much easier than the OAuth flows[2], but harder to replicate in the wild. Our IT group makes sure the extension is installed on workstations as part of the base OS image.

[2] https://developers.google.com/storage/docs/gsutil_install#authenticate