Github 如何知道我的密码在其他网站上常用?

Chi*_*oki 6 github

有趣的事实,但不知道这是怎么发生的。只是好奇。

在我的Github帐户的设置页面中,显示“您提供的密码位于其他网站常用的密码列表中。为了提高您的安全性,您必须更新您的密码......”

这似乎很正常,但当我深入思考时,我真的不明白Github是如何知道我的密码被其他网站常用的!

我的意思是,从“其他网站”的角度来看,Github 假设不知道其客户端使用的是哪组密码,那么 Github 如何知道自己的客户端密码是其他网站常用的呢?

在此输入图像描述

Von*_*onC 11

正如本帖子中提到的,自 2020 年第二季度以来:

\n
\n

虽然您当前拥有的密码可能满足列出的要求,但当您提供密码时(登录或 sudo 访问期间),系统也会运行检查。

\n

该检查将该密码的单向哈希值与我们已知因其他网站或服务的破坏而受到损害的内部凭据数据库进行比较

\n

您收到的弱密码消息表明您输入的密码已被某人(不一定是您自己)在遭到入侵的网站上使用,这意味着它\xe2\x80\x99 出现在恶意行为者在自动接管尝试中使用的列表中。

\n
\n

因此,比较的是密码哈希值,而不是实际密码。

\n

该线程添加:

\n
\n

GitHub 使用公开和私人付费的违规数据源来保护客户帐户。
\n我们通常不会指定我们的供应商的名称,在某些情况下,我们实际上无法根据合同这样做。当然,例外情况是我们与供应商 5 共享客户数据,而这里的情况不是\xe2\x80\x99t。

\n

对于任何匹配的凭据,我们有两种不同的响应:

\n
    \n
  1. 如果存在直接匹配(即,您的电子邮件地址和密码完全一致),那么我们将强制重置密码。
    \n在重置密码之前,\xe2\x80\x99您将无法再次使用您的帐户。
    \n直接匹配会给您的 GitHub 帐户以及您有权访问的任何 GitHub 存储库或组织的安全带来很高的风险。

    \n
  2. \n
  3. 如果存在间接匹配 - 即您的密码已被泄露,但不一定是您的确切电子邮件地址 - 我们会警告密码较弱,并给您一个更改密码的时间窗口。
    \n这是风险较低的情况,但仍然存在风险。

    \n
  4. \n
\n

我们\xe2\x80\x99意识到我们确实在这里采取了保守的方法,并且不断地接受审查。
\n我们知道有些人希望自己对安全性更加放松,但同样,帐户接管给我们带来了巨大的工作量,而且目前不提供选择退出功能。

\n
\n
\n
\n

他们如何比较加盐哈希呢?或者他们是否暗示他们直接对密码进行哈希处理?

\n
\n

在遵循最佳实践的加密系统中,密码通常使用每个用户唯一的盐值进行哈希处理。然后,盐与散列密码一起存储在数据库中。该技术使得预先计算的哈希表(如彩虹表)变得无效。唯一盐的存在确保具有相同密码的两个用户将在数据库中存储不同的哈希值。

\n

鉴于加盐哈希对于每个用户来说都是唯一的,直接将加盐哈希与受损哈希列表进行比较是无效的。

\n
    \n
  • GitHub 可以临时对不加盐(或使用普通盐)的密码进行哈希处理,以在帐户创建或密码更新过程中将其与已知受损哈希值列表进行比较。这并不意味着存储未加盐的哈希值;而是存储了未加盐的哈希值。检查后,系统将丢弃未加盐的哈希值并存储密码的加盐哈希值以供长期存储。

    \n
  • \n
  • 受损凭据的数据库可能包含以与检查兼容的方式创建的哈希值。这将允许 GitHub 对输入密码进行单向哈希,并将其与数据库进行有效比较。

    \n
  • \n
  • 列表中的泄露密码可能使用 GitHub 用于临时检查的相同算法进行哈希处理。然而,它们可能不包含盐。

    \n
  • \n
\n

根据我上面的最初回答,GitHub 可能会使用密码的单向哈希来检查受损凭据的数据库。这可能意味着用于此比较的哈希未加盐或使用标准盐,与用于在数据库中安全存储密码的唯一盐分开。在检查数据库中是否存在泄露的凭据后,您的密码将根据最佳实践进行加盐和哈希处理以安全地存储。

\n