增强基于旧数据库构建的新系统的安全性答案

【问题标题】：Bolstering the security of a new system built on a legacy database增强基于旧数据库构建的新系统的安全性
【发布时间】：2011-06-05 21:59:40
【问题描述】：

我们有一个旧的 ASP 应用程序，它将客户密码存储为加盐的 MD5 哈希值。我们在 ASP.NET MVC 中编写了一个新应用程序来替换它。

我想将密码字段的保护提高一个档次并使用 SHA1 散列。显然，我需要在不强制客户更新密码以创建新的 SHA1 哈希的情况下执行此操作。

我的想法是使用 SHA1 对现有的 MD5 哈希值进行哈希处理。这意味着我仍然需要使用 MD5 进行哈希处理，然后在客户登录和重置密码时再次使用 SHA1 进行哈希处理，但我可以接受。

谁能发现这种方法的任何缺陷？在我看来，

【问题讨论】：

标签： security passwords hash

【解决方案1】：

您应该使用 Bcrypt 或类似的东西，而不是使用 SHA1。

但除此之外，您的方案似乎是合理的。幸运的是，现有的哈希格式易于识别，因此如果您不想向数据库添加新列，可以添加标识符前缀。

我建议修改代码以能够处理md5、md5+bcrypt或bcrypt，然后你可以运行后台进程将密码从md5升级到md5+bcrypt，而在线登录代码升级到bcrypt？

【讨论】：

谢谢道格拉斯。 BCrypt 确实让我胃口大开。

【解决方案2】：

加宽列以支持哈希
引入第二列来确定哈希策略（或见下文）；默认为 MD5（因为这是当前哈希）
更改登录（和类似的）和密码更改/重置例程，以根据此值检测正在使用的哈希策略，然后应用它；如果该值使用“已弃用”散列进行散列，则静默升级它（因为一旦验证，您将获得用户的纯文本密码）
经过一段合理的时间后，考虑锁定尚未升级旧密码哈希的用户

您可以自动检测一些散列策略，例如直接 MD5 与 SHA1，基于其编码输出的长度 - 十六进制编码的 MD5 占用 32 个字节，而 SHA1 需要 40 个字节。但是，“散列策略”也可以包含信息（对应用程序有意义 - 确保你彻底记录它！ ) 关于对散列执行的任何其他操作，例如加盐机制或散列迭代次数，并且通常更健壮一些。将来，您可能希望引入第三个哈希（例如 Tiger-192）并重复升级过程。

如果您不能保留另一列，则扩大现有列以支持带有一些哈希指示符的前缀，例如{SHA1}xxxxxxxxxxxxx - 旧的哈希值不会加前缀，可以假定为 MD5。

【讨论】：

我正在尝试用最少的额外代码（除了使用 SHA1 重新散列）来做到这一点。该列已经相当大（varchar(1024)），所以没有问题。我也想立即为大家实施这个升级，我宁愿不等待客户再次登录以静默升级（这也是我考虑过的策略）。不过你的建议很有用。