On Mon, Feb 18, 2013 at 12:45 PM, Jeff King <p...@peff.net> wrote: > > 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.
Right, otherwise you spend all day typing in your credentials and syncing with the 2nd factor device. > 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]. ... > [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. 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
