Skip to main content

关于强制双因素身份验证

启用强制双因素身份验证来保护帐户并维护对 GitHub.com 的访问权限。

从 2023 年 3 月开始到 2023 年底,GitHub 将逐渐开始要求在 GitHub.com 上贡献代码的所有用户启用一种或多种形式的双因素身份验证 (2FA)。 如果你在符合条件的组中,当选择该组进行注册时,将收到一封通知电子邮件,该电子邮件标志着 45 天的 2FA 注册期的开始,并且你会看到要求你在 GitHub.com 上注册 2FA 的横幅。 如果未收到通知,则表示你不是需要启用 2FA 的组的成员,但我们强烈建议启用 2FA。

关于强制 2FA 的资格

如果你对 GitHub 进行的一些操作表明你是参与者,则会选择你的帐户进行强制 2FA。 符合条件的操作包括:

  • 为他人发布应用或操作。
  • 为存储库创建发布。
  • 参与特定的高重要性存储库,例如开源安全基金会跟踪的项目
  • 成为高重要性存储库的管理员。
  • 成为包含存储库或其他用户的组织的组织所有者。
  • 成为企业管理员

GitHub 会持续评估对帐户安全功能和 2FA 需求的改进,因此这些条件可能会随时间变化。

注意: 如果你的帐户有教育优惠券处于活动状态,则它可免除强制 2FA。

关于组织和企业的强制 2FA

GitHub 本身需要强制 2FA,以提高单个开发人员以及更广泛的软件开发生态系统的安全性。 管理员可能还需要启用 2FA 作为加入其组织或企业的要求,但这些要求与本计划无关。

帐户的强制 2FA 资格不会影响其他个人的资格。 例如,如果你是组织所有者,并且你的帐户符合强制 2FA 的条件,则不会影响贵组织内其他帐户的资格。

注意:GitHub Enterprise Managed Users 和本地 GitHub Enterprise Server 用户不需要启用 2FA。 强制 2FA 启用仅适用于在 GitHub.com 上有密码的用户。

关于未能启用强制 2FA 的情况

如果在 45 天的设置期内未启用 2FA,并且 7 天的宽限期已到期,则在启用 2FA 之前,将无法访问 GitHub.com。 如果尝试访问 GitHub.com,将会提示你启用 2FA。

如果无法启用强制 2FA,则属于帐户的令牌将继续有效,因为它们用于关键自动化。 这些令牌包括 personal access tokens 以及颁发给应用程序以代表你行事的 OAuth 令牌。 启用 2FA 不会撤销或更改为你的帐户颁发的令牌的行为。 但是,在启用 2FA 之前,锁定的帐户将无法授权新应用或创建新 PAT。

关于必需的 2FA 方法

建议将基于时间的一次性密码 (TOTP) 应用设置为主要 2FA 方法,并添加密钥或安全密钥作为备份。 如果没有密钥或安全密钥,GitHub Mobile 应用也可作为不错的备用选项。 短信在大多数国家/地区都很可靠,但存在有些风险模型可能无效的安全风险。

目前,我们不支持将密钥或安全密钥作为主要 2FA 方法,因为它们很容易丢失,也不支持在足够大范围的设备之间进行同步。 随着密钥得到更广泛的采用以及同步支持更为普遍,因此我们将支持它们作为主要方法。

注意: 建议在 GitHub.com 上保留 Cookie。 如果将浏览器设置为每天擦除 Cookie,则永远不会有已验证设备可用于帐户恢复,因为 _device_id Cookie 用于安全地证明你以前使用过该设备。 有关详细信息,请参阅“丢失 2FA 凭据时恢复帐户”。

关于 TOTP 应用和强制 2FA

对于 GitHub,TOTP 应用是推荐的 2FA 因素。 有关配置 TOTP 应用的详细信息,请参阅“配置双重身份验证”。

如果不想在移动设备上下载应用,还有多个跨平台运行的独立 TOTP 应用可供选择。 对于桌面应用程序,我们建议使用 KeePassXC,对于基于浏览器的插件,我们建议使用 1Password

还可以手动设置任何可生成与 RFC 6238 兼容的代码的应用。 有关手动设置 TOTP 应用的详细信息,请参阅“配置双重身份验证”。 有关 RFC 6238 的详细信息,请参阅 IETF 文档中的 TOTP:基于时间的一次性密码算法

注意: 如果使用 FreeOTP 进行 2FA,可能会看到有关弱加密参数的警告。 GitHub 使用 80 位密钥来确保与早期版本的 Google Authenticator 兼容。 80 位低于 HOTP RFC 建议的 128 位,但目前我们不打算进行更改,建议忽略此消息。 有关详细信息,请参阅 IETF 文档中的 HOTP:基于 HMAC 的一次性密码算法

关于 SAML SSO 和强制 2FA

如果你被选择进行强制 2FA,则即使公司已要求通过 2FA 进行单一登录 (SSO),你也必须在 GitHub.com 上注册 2FA。 虽然通过 2FA 进行 SSO 是保护组织或企业拥有的资源的强大方法,但它不会保护与组织或企业无关的 GitHub.com 上归用户拥有的内容,也不会保护用户的配置文件和设置。

GitHub 仅要求你对初始身份验证和敏感操作执行 2FA,因此即使每天必须执行公司 2FA 以访问 GitHub,也很少需要再次通过 GitHub 执行 2FA。 有关敏感操作的的详细信息,请参阅“Sudo 模式”。

关于电子邮件验证和强制 2FA

登录到 GitHub.com 时,电子邮件验证不算作 2FA。 帐户的电子邮件地址用于密码重置,这是帐户恢复的一种形式。 如果攻击者能够进入你的电子邮件收件箱,他们可以重置帐户的密码,并通过电子邮件设备验证检查,从而将帐户的保护降低到单一因素。 我们需要第二个因素来防止发生这种情况,因此第二个因素必须不是电子邮件收件箱。 如果启用 2FA,在登录时将不再执行电子邮件验证。

关于服务帐户和强制 2FA

组织中为强制双因素身份验证选择的无人参与或共享访问帐户(例如机器人和服务帐户)必须注册 2FA。 启用 2FA 不会撤销或更改为服务帐户颁发的令牌的行为。 GitHub 建议将服务帐户的 TOTP 机密安全存储在共享凭证存储中。 有关详细信息,请参阅“使用双因素身份验证管理机器人和服务帐户”。

关于强制性 2FA 的隐私性

如果已选择强制 2FA,这并不意味着必须向 GitHub 提供电话号码。 如果使用短信进行 2FA,则只需提供电话号码。 但是,我们建议将 TOTP 应用配置为主要 2FA 方法。 有关详细信息,请参阅“配置双重身份验证”。

注意: 你所在区域可能未在可用的短信选项中列出。 我们按区域监测短信传送成功率,并禁止对传送率较差的区域进行设置。 如果未在列表中看到你所在区域,则必须改为设置 TOTP 应用。 有关短信可支持区域的详细信息,请参阅“支持 SMS 身份验证的国家/地区”。