Re: feature request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 18, 2013 at 12:45 PM, Jeff King <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]