Many websites support two-factor authentication(2FA) to log in, like Github, I wander if we can support it in application layer.
When client clone something, they need input username and password, it is like a website login process. For security, we can
enable 2FA during this process.
From: Konstantin Ryabitsev <hidden> Date: 2021-08-11 13:51:00
On Wed, Aug 11, 2021 at 07:00:50PM +0800, lilinchao@oschina.cn wrote:
Many websites support two-factor authentication(2FA) to log in, like Github, I wander if we can support it in application layer.
When client clone something, they need input username and password, it is like a website login process. For security, we can
enable 2FA during this process.
As you well know, "cloning" a repository can be done via any number of
mechanisms:
1. locally from another repository on disk
2. locally, from a git bundle file
3. remotely, using the anonymous git:// protocol
4. remotely, using ssh or http(s) protocols
2-factor authentication does not make sense in the first three cases (you
already have access to all the objects with 1 and 2, and the git:// protocol
is public and anonymous by design). For the ssh/https scheme, 2fa is already
supported by the underlying protocol, so it does not make sense for git to
implement it again on the application level.
Hope this helps.
-K
Many websites support two-factor authentication(2FA) to log in, like Github, I wander if we can support it in application layer.
When client clone something, they need input username and password, it is like a website login process. For security, we can
enable 2FA during this process.
Typically, this is handled at the credential helper layer, which
is a tool outside of the Git codebase that can more closely work
with such 2FA/MFA requirements. For example, GCM Core [1] supports
2FA with GitHub, Azure DevOps, and BitBucket.
[1] https://github.com/microsoft/Git-Credential-Manager-Core
The mechanism is that Git attempts an operation and gets an error
code, so it asks for a credential from the helper. The helper
then communicates with the server to do whatever authentication
is required, including possibly performing multi-factor auth.
All of these details are hidden from Git, which is good.
I've CC'd Matthew Cheetham who is the maintainer of GCM Core to
correct me if I misstated anything here.
Thanks,
-Stolee
On Wed, Aug 11, 2021 at 09:50:55AM -0400, Konstantin Ryabitsev wrote:
On Wed, Aug 11, 2021 at 07:00:50PM +0800, lilinchao@oschina.cn wrote:
quoted
Many websites support two-factor authentication(2FA) to log in,
like Github, I wander if we can support it in application layer.
When client clone something, they need input username and
password, it is like a website login process. For security, we can
enable 2FA during this process.
As you well know, "cloning" a repository can be done via any number of
mechanisms:
1. locally from another repository on disk
2. locally, from a git bundle file
3. remotely, using the anonymous git:// protocol
4. remotely, using ssh or http(s) protocols
2-factor authentication does not make sense in the first three cases (you
already have access to all the objects with 1 and 2, and the git:// protocol
is public and anonymous by design). For the ssh/https scheme, 2fa is already
supported by the underlying protocol, so it does not make sense for git to
implement it again on the application level.
It might be helpful to be explicit about what *kind* of two-factor
authentication you are interested in. There are multiple different
kinds of 2FA systems, including ssh keys stored on a hardware token
such as a smartcard or a Yuibikey, U2F Fido systems using a security
key, TOTP or HOTP otp systems, etc.
Each of these systems have different tradeoffs in terms of ease of use
from the user perspective (both from the point of view of initial
setup and day-to-day use after getting set up), security against MITM
attacks, and ease of integration/deployment from the system
administrator's perspective.
Cheers,
- Ted
From: brian m. carlson <hidden> Date: 2021-08-13 22:57:30
On 2021-08-11 at 13:50:55, Konstantin Ryabitsev wrote:
2-factor authentication does not make sense in the first three cases (you
already have access to all the objects with 1 and 2, and the git:// protocol
is public and anonymous by design). For the ssh/https scheme, 2fa is already
supported by the underlying protocol, so it does not make sense for git to
implement it again on the application level.
To expand on this a little bit, you can absolutely set up a Git server
with OpenSSH and require 2FA with OpenSSH. That should work just fine.
You could also leverage a custom credential helper for HTTPS to require
a 2FA code, send it to a server, which would issue a one-time token for
Basic auth. All of this is achievable with existing tooling that we
have today or tooling that can be easily built.
One note here is that as a practical matter, many people require
automated cloning of repositories, such as to use their CI systems.
Those systems generally cannot practically use 2FA and the security
would not be improved if they did, so some solution that allows for that
to work is going to be required.
Also, in workflows that require many repositories to be cloned, it can
be kind of a hassle to wait for one clone to complete, enter the 2FA
code (or touch the YubiKey) for the second clone, wait for it to
complete, do 2FA for the third clone, and so on. So while you can do
this, it's important to keep in mind that there are some user experience
tradeoffs here that need to be considered as well.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA