Security 增强基于遗留数据库的新系统的安全性

我们有一个旧的传统ASP应用程序，它将客户密码存储为咸MD5散列。我们已经在ASP.NET MVC中编写了一个新的应用程序来取代此功能

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

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

有人能发现这种方法的任何缺陷吗？在我看来，似乎

加宽列以支持散列

引入第二列以确定哈希策略（或参见下文）；默认为MD5（因为这是当前哈希）

更改登录（及类似）和密码更改/重置例程，以基于该值检测正在使用的哈希策略，然后应用该策略；如果该值是用“不推荐使用的”散列进行散列的，则以静默方式升级它（因为一旦您验证了密码，您将从用户那里获得纯文本密码）

在合理的时间段后，考虑锁定未升级旧密码哈希的用户。 您可以根据编码输出的长度自动检测一些散列策略，例如直接MD5与SHA1，十六进制编码MD5占用32字节，而SHA1需要40字节。然而，“散列策略”也可以包含关于在散列上执行的任何其他操作的信息（对应用程序来说很有意义——请确保对其进行完整的文档记录！），例如盐析机制或散列迭代次数，并且通常更为健壮。将来，您可能希望引入第三个哈希（比如Tiger-192）并重复升级过程

---

如果您不能腾出另一列，则扩展现有列以支持使用哈希的某些指示符作为前缀，例如，

{SHA1}xxxxxxxx

-旧哈希将不作为前缀，可以假定为MD5。

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

但除此之外，你的计划似乎是合理的。幸运的是，现有的散列具有易于识别的格式，因此如果不想向数据库中添加新列，可以添加标识符前缀

---

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

我正在尝试用最少的额外代码（而不是用SHA1重新散列）来完成这项工作。该列已经相当大（

varchar（1024）

），因此没有问题。我还想立即为每个人实施此升级，我不希望等待客户再次登录以进行静默升级（这也是我考虑过的策略）。不过你的建议很有用。谢谢道格拉斯。BCrypt肯定会刺激我的食欲。