基础方法更改时是否应自动重置密码

#1 楼

您的选择1.是一个坏主意：除了您陈述的用户体验/公共关系原因之外，您还为攻击者提供了一个拦截密码重置令牌并破坏服务器上每个帐户的窗口。如果您甚至有一个懒惰的用户也无法登录/更新密码，这也不能解决您的问题。

乍一看，我觉得2.和3.都不错。 ＃2的安全性不亚于现在的安全性，但是2.意味着您必须永远继续支持当前的弱登录（或执行类似“在X个月后，我们将擦除您的密码并强迫您执行操作）恢复”会破坏您想要的良好的用户透明性，因此，我们可以忽略它。）让我们考虑一下这种情况，您在数据库中拥有永远不会再次登录的用户。对于2和3.，您必须继续在代码库中永远支持当前的哈希算法，以防万一他们确实登录了，但是至少3.具有防止它们（或更确切地说，您）受到保护的优点如果您的数据库曾经被盗，则进行离线暴力攻击。

由于您必须永远保留“旧样式标志”列，因此请帮自己一个忙，使其成为int而不是bool，这样，如果您不得不再次更新密码哈希算法，就可以记录它们所使用的旧样式。


更新：这里提出了一个非常类似的问题，并基于此线程。

#2 楼

如果您可以执行选项3，我不知道您为什么还要考虑其他选项。到目前为止，这是最佳选择。使用此选项，我的直觉是考虑使用两种不同的盐，一种用于旧算法，另一种用于带有bcrypt的新算法。我正在设想这样的设置：


设置新密码系统，就像今天开始一样。
创建一个新的单独的表，其中包含用于用户名（或ID），哈希算法（名称或ID），盐。
登录时，检查用户是否在单独的表中有记录，如果是，则以旧方式哈希密码，然后哈希结果新方法并与bcrypt哈希值进行比较。如果匹配，请以新方式重新添加盐/散列密码，然后从单独的表中删除记录。

缺点是您必须将密码在内存中保留几毫秒（谁在乎），那么您每次登录都会获得额外的表查询，几乎永远都是这样，直到单独的表为空或旧帐户变得陈旧到足以让您愿意要求他们自己重置密码为止。

#3 楼

请注意，如果您的OLD方案是用salt进行哈希处理的，则除非您单独存储盐，否则将无法使用方案＃3。

通常盐会与哈希一起存储，并且您将盐用作哈希函数的输入-如果不使用完全相同的盐，则将获得完全不同的输出。

如果您使用newhash（oldsalt + oldhash，newsalt），那么具有正确的密码，您将无法重新创建oldhash（因为您没有oldsalt），并且您无法生成最终的哈希。同样的事情也适用于具有参数的任何事物（例如bcrypt具有“ cost”参数-加密时需要设置此参数，并将其嵌入到输出中，以便在验证密码时使用）。

ALSO ：就像其他人提到的那样，如果您存储的哈希是“旧”或“新”样式，请考虑存储“方案”，例如0是“旧”，而1是bcrypt（请注意，我不使用“ new”-现在是“ new”，永远不会是“ new”！）。一种常见的方法是在散列的开头添加一个标记（可能已经是这种情况了！）。 bcrypt使用以下标准前缀之一：“ $ 2a $”，“ $ 2b $”，“ $ 2x”或“ $ 2y $”。根据“旧”算法的可能输出，您可能需要组成自己的前缀来标记这些内容，或者您​​可以摆脱“不以'$'开头的任何内容”。

最后，由于您显然对旧密码的安全性感到担心（正确的是！），我建议通过向每个人发送带有令牌的说明（不要这样做！）来强迫所有人更改密码。发送链接！您不希望用户单击链接！只需告诉他们登录到通常的位置即可。然后，要求令牌和密码。否则，过去曾经窃取密码的人可以更改密码，并获得有效的“新”密码。

最后：有一个有效期-如果在该日期之前未更改密码，则它们应该无效。该日期应该在电子邮件中，并且不要太远（一个星期？取决于客户响应的时间）。之后，他们将必须执行“密码重置”过程。

#4 楼

我不知道您的密码编码方案是什么，但是如果它还算不错的话，那么新旧格式的密码结构可能会有所不同。

我已经看到过类似的内容在旧的BSD系统中，当系统从传统的密码编码更改为更安全的密码编码时。新密码以旧模式中不存在的字符序列开头，因此，每次使用旧密码登录的用户都使用旧方法验证其明文密码，然后使用以下方法静默重新哈希并存储回密码数据库中：新方法。一个月后，数据库中不再存在旧密码，而最终用户没有注意任何事情。

那将是第二种和第三种方法之间的某个地方。

我知道在实际的生产Web系统上，情况可能会变得更糟，因为用户可能需要等待数周甚至数月才能再次连接。但是（取决于实际活动）可以通过以下事实缓解：一个未连接几个月的用户可能忘记了密码-或者您可以告诉他他已经这样做了……这意味着我会稍等一下在这里待了3到6个月，然后我将所有旧密码重置为禁止值，从而迫使用户在下次连接时通过被忘记的密码屏幕重置密码。

不错的地方是：


对于普通用户是透明的
没有数据库架构更改-只要密码字段可以接受两种样式
偶然的用户将被简单地处理，就像他们几个月后忘记使用密码而没有使用它

缺点是它迫使您同时实施两种身份验证方法和所有样式密码的自动更新。

#5 楼

您没有提及您使用的语言。 Php的问题在于，各种函数在某些情况下应返回true时应返回false，或听起来像是在完成工作但缺少实际处理所有可能有效输入的逻辑的其他函数。

但是，即使您不使用php，这也是执行您在php中谈论的内容的正确方法。高级别的代码可以为您进行编码提供一个起点。

http://php.net/manual/en/function.password-needs-rehash.php

$password = 'rasmuslerdorf';
$hash = 'y$YCFsG6elYca568hBi2pZ0.3LDL5wjgxct1N8w/oLR/jfHsiQwCqTS';

// The cost parameter can change over time as hardware improves
$options = array('cost' => 11);

// Verify stored hash against plain-text password
if (password_verify($password, $hash)) {
    // Check if a newer hashing algorithm is available
    // or the cost has changed
    if (password_needs_rehash($hash, PASSWORD_DEFAULT, $options)) {
        // If so, create a new hash, and replace the old one
        $newHash = password_hash($password, PASSWORD_DEFAULT, $options);
    }

    // Log user in
}

我要做的是将您的＃2与使用int进行了提及。通过阅读PASSWORD_DEFAULT上的文档，当找到更好的算法时，它可能会更改，并且由于php升级，出于不安全目的，它们需要删除当前算法。

#6 楼

就旧认证系统中的安全漏洞向用户提供建议，并建议他们更改/重置密码以使用新的认证系统。如果在预定的时间段（可能会在某些地方的“小字样”中提示用户）之后，某些用户仍未更改/重置密码，请停用其帐户并发送电子邮件，指导他们如何再次激活它。这样，您的普通用户会感到自己在“要求”更改密码，而不是“告诉”他们更改密码，因此即使他们确实更改了密码，也不太可能对请求做出负面反应（希望他们会，如果您的咨询电子邮件具有足够的说服力），您将不必为永远无法更改密码的少数用户永远支持旧的身份验证系统。