On Mon, Feb 18, 2013 at 02:54:30PM -0500, James Nylen wrote: > > 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 > > 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? 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html