前段时间我加入了新项目。它已经开发了很长时间。令我惊讶的是所有用户的密码都以非加密形式存储。
我向我们的管理层解释了这个巨大的安全漏洞——看起来他们同意这一点，并希望使项目更安全。团队成员也同意。
我们在系统中有大约 20,000 个用户。
其实做这项工作压力很大——将非加密密码迁移到加密形式。如果出现问题，可能会导致项目的灾难。
我怎样才能降低这种压力？备份？单元测试（集成测试）？
问问题
594 次
6 回答
5
好吧，请小心您的备份，因为它将包含未加密的用户密码:-)
假设密码存储在数据库中，一个简单的解决方案是这样的：
1）对整个表数据进行安全备份
2）创建新列（PasswordEncrypted 或类似名称）
3) 在使用 32 字节或更大的 salt 时，使用 UPDATE 查询使用未加密密码的 MD5 更新每一行的新列。今天几乎每个数据库系统都有一个 MD5 函数，所以你甚至不必离开你的 SQL 提示符
4）临时保留明文列并相应地更新您的应用程序/脚本以使用加盐密码。
5) 重命名明文旧密码列以暂时停止使用并测试您的应用程序 - 如果有任何问题，请返回第 4 步并修复您的错误。
6）当一切正常时删除明文密码列
7) 鼓励用户选择新密码，因为您已经具备一定程度的安全性，可以减轻之前可能成功的任何攻击的影响。
于 2009-05-02T15:27:35.647 回答
2
这是一个什么样的项目？Web 应用程序，桌面应用程序？
如果您要走重构之路，是否有理由将密码存储在加密等可逆的东西中？一般来说，最好用 SHA 之类的东西对密码进行哈希处理，然后用相同的算法对输入进行哈希处理并比较结果。您只存储散列值，而不是实际密码。这使您能够检查是否有人输入了正确的密码，而不会让您的用户暴露于您的加密被破坏和他们的密码暴露的可能性。
关于你的方法的具体信息不是我可以提供的（因为我不知道它是如何工作的），但你最好的办法是创建一个额外的列来存储散列密码，散列现有密码，然后保持它们任何密码更改的日期。将此新列用于所有新开发，然后在移动完成并经过测试后，删除带有明文密码的列。
于 2009-05-02T15:35:58.700 回答
1
编写大量测试，测试大量极端情况（大小写、数字、符号、Unicode 字符、长密码等）。当您在开发和测试时，创建一个系统以移回旧系统（当然，通过提供旧密码列表，因为一旦密码被散列，您将无法直接将它们转换回来）。保存当前密码列表的副本。在测试文件或测试数据库中转换密码，然后使用保存的密码副本来测试一切是否正常。现在将系统投入生产，并确保它适用于您的用户。如果没有，您已经测试了迁移回旧系统的计划。一旦它被证明可以工作几个星期，您就可以删除明文密码列表，一切就绪。
于 2009-05-02T15:30:05.687 回答
1
我只是散列当前密码，将它们存储在一个新的数据库字段中，然后在删除密码字段时开始使用该字段。然后我会通知我的用户，现在是更改密码的好时机，因为您已经实施了更多的安全机制来保证他们的数据安全。
要备份，只需执行SELECT * INTO Backup FROM UserData
于 2009-05-02T15:31:32.830 回答
1
通过为每次登录尝试运行两种身份验证方法（加密和未加密），您可以获得额外的信心，如果它们产生不同的结果，则会收到一封发送给您的警报电子邮件。此更改对您的用户不可见，因此它可以运行数周甚至数月。一旦您看到新旧身份验证对足够高比例的用户有效，请停用旧身份验证。
于 2009-05-02T15:34:45.223 回答
0
如果可能的话，你可以试试这个：向你的所有用户发送一封电子邮件，让他们在超时期限内更新他们的密码，如果他们不更改密码，他们将无法工作。散列这些新密码并存储散列。这将需要在前端进行一些更改（即它发回的数据）。
于 2009-05-02T15:24:53.827 回答