支持构建在旧数据库上的新系统的安全性

我们有一个旧的传统ASP应用程序，它将客户密码存储为盐渍MD5散列。我们在ASP.NET MVC中编写了一个新的应用程序来取代它。支持构建在旧数据库上的新系统的安全性

我想将密码字段的保护提高一个档次，并使用SHA1哈希。显然，我需要这样做，而不会强迫客户更新其密码以创建新的SHA1哈希。

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

任何人都可以发现此方法中的任何缺陷？对我来说，这似乎是

来源

2011-01-08 Kev

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

但是，否则你的计划似乎是合理的。幸运的是，现有的哈希码具有易于识别的格式，因此如果您不想向数据库添加新列，则可以添加标识符前缀。

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

来源

2011-01-09 08:26:34

谢谢道格拉斯。 BCrypt肯定会激起我的胃口。 – Kev 2011-01-09 12:02:15

加宽列，以支持哈希
引入第二列，以确定散列策略（或见下文）;默认为MD5（因为这是当前散列）
改变登录（以及类似的）和密码更改/重置例程以基于此值检测正在使用哪个散列策略，然后应用它;如果该值使用“弃用”散列进行散列，然后静默升级（因为一旦您验证了密码，用户将以纯文本形式输入密码）
经过一段合理时间后，请考虑锁定用户谁没有升级旧密码哈希

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

如果你不能备用另一列，那么扩大现有的列以支持带有一些散列指示符的前缀，例如， {SHA1}xxxxxxxxxxxxx - 旧散列不会加前缀，并且可以假定为MD5。

来源

2011-01-08 23:15:10 Rob

我试图用最少的额外代码（除了用SHA1重新哈希之外）做到这一点。该列已经很大（`varchar（1024）`），所以没有问题。我也希望立即为所有人实施此升级，我宁愿不等待客户再次登录以进行无提示升级（这也是我曾考虑过的一种策略）。不过，你的建议非常有用。 – Kev 2011-01-08 23:24:45

支持构建在旧数据库上的新系统的安全性

回答

相关问题