未加密密码用户群的加密密码
前段时间我加入了一个新项目。 它已经开发了相当长的时间。 让我惊讶的是，所有用户的密码都以非加密形式存储。
我向我们的管理层解释了这个巨大的安全漏洞 - 看起来他们同意这一点并希望使项目更加安全。 团队成员也同意。
我们的系统中有大约 20K 用户。
实际上，完成这项工作是相当有压力的 - 将非加密密码迁移到加密形式。 如果出现问题，可能会导致项目灾难。
我怎样才能减轻这种压力？ 备份？ 单元测试（集成测试）？
Some time ago I joined new project. It was under development for quite a long time.
The thing that surprised me was that all users' passwords are stored in non-encrypted form.
I explained huge security vulnerabilities of this to our management - it looks like they agree with that and want to make project more secure. Team members agree too.
We have about 20K users in the system.
Actually it is quite stressful to make this work - migrate non-encrypted passwords to encrypted form. If something goes wrong it can lead to project's disaster.
How can I lower this stress?
Backup?
Unit-tests(integrational tests)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
好吧，请小心备份，因为它将包含未加密的用户密码:-)
假设密码存储在数据库中，一个简单的解决方案将如下所示：
1) 对整个表数据进行安全备份
2) 创建新列（PasswordEncrypted 或类似名称）
3) 使用 UPDATE 查询，在使用 32 字节或更大的 salt 时，使用未加密密码的 MD5 更新每行的新列。 如今几乎每个数据库系统都具有 MD5 功能，因此您甚至不必离开 SQL 提示符
4) 临时保留明文列并相应更新您的应用程序/脚本以使用加盐密码。
5) 重命名明文旧密码列以暂时将其退出并测试您的应用程序 - 如果有任何问题，请返回到步骤 4 并修复您的错误。
6) 当一切正常时，删除明文密码列
7) 既然您已经采取了一定程度的安全措施，可以减轻以前可能成功的攻击的影响，则鼓励用户选择新密码。
Well, be careful with your backup because it will contain unencrypted user passwords :-)
Assuming that the passwords are stored in a database, an easy solution would go something like this:
1) Make a secure backup of the entire table data
2) Create new column (PasswordEncrypted or similar name)
3) Use an UPDATE query to update each row's new column with an MD5 of the unencrypted password while using a 32 byte or larger salt. Pretty much every database system today has an MD5 function so you won't even have to leave your SQL prompt
4) Keep the plaintext column in the interim and update your application/scripts accordingly to work with the salted password.
5) Rename the plaintext old password column to temporarily take it out of play and test your application- if there are any problems then go back to step 4 and fix your mistakes.
6) When everything is working properly drop the plaintext password column
7) Encourage users to pick a new password now that you have some level of security in place to mitigate the effects of any previous attacks which may have been successful.
这是一个什么样的项目？ Web 应用程序、桌面应用程序？
如果您要走重构之路，是否有理由需要将密码存储在可逆的方式（例如加密）中？ 一般来说，最好使用 SHA 之类的方法对密码进行哈希处理，然后使用相同的算法对输入进行哈希处理并比较结果。 您仅存储哈希值，而不存储实际密码。 这使您能够检查某人是否输入了正确的密码，而不会让您的用户面临您的加密被破坏及其密码暴露的可能性。
我无法提供有关您的方法的具体信息（因为我不知道它是如何工作的），但您最好的选择是创建一个附加列来存储散列密码，散列现有密码，然后将它们保存到任何密码更改的日期。 使用此新列进行所有新开发，然后在移动完成并测试后，删除包含明文密码的列。
What sort of project is this? A web application, desktop application?
If you're going down the refactoring road, is there a reason that the passwords need to be stored in something reversible like encryption? In general, it's good practice to hash your passwords with something like SHA then hash the input with the same algorithm and compare the results. You only store the hashed values, not the actual passwords. This gives you the ability to check that someone has entered the correct password without exposing your users to the possibility of your encryption being broken and their passwords exposed.
Specific information about your approach isn't something I can provide (since I don't know how it works), but your best bet is to create an additional column to store the hashed passwords, hash the existing passwords, then keep them up to date with any password changes. Use this new column for all new development, then once the move is complete and tested, delete the column with the plaintext passwords.
编写大量测试，测试大量极端情况（大小写、数字、符号、Unicode 字符、长密码等）。 当您开发和测试时，创建一个系统以移回旧系统（当然，通过提供旧密码列表，因为一旦密码被散列，您将无法直接将它们转换回来）。 保存当前密码列表的副本。 在测试文件或测试数据库中转换密码，然后使用保存的密码副本来测试一切是否正常。 现在将系统投入生产，并确保它适合您的用户。 如果没有，则您已经测试了迁移回旧系统的计划。 一旦证明它可以工作几周，您就可以删除明文密码列表，一切就都准备好了。
Write lots of tests, that test lots of corner cases (upper and lower case, numbers, symbols, Unicode characters, long passwords, etc). When you're developing and testing, create a system to move back to the old system (by providing the old password list, of course, since once the passwords are hashed you won't be able to convert them back directly). Save a copy of the current password list. Convert the passwords over in a test file or test database, and then use the saved copied of the passwords to test that everything worked. Now move the system into production, and make sure it works for your users. If it does not, you have already tested the plan for migrating back to the old system. Once it has been demonstrated to work for a couple of weeks, you can delete the cleartext password list and you're all set.
我只需对当前密码进行哈希处理，将它们存储在新的数据库字段中，然后在删除密码字段时开始使用该字段。 然后，我会通知我的用户，现在是更改密码的好时机，因为您已经实施了更多安全机制来保证他们的数据安全。
要进行备份，只需执行
SELECT * INTO Backup FROM UserDataI would just hash the current passwords, store them in a new database field, and begin using that field while deleting the password field. I would then notify my users that now would be a good time to change passwords as you've implemented more security mechanisms to keep their data safe.
To have a backup, just do
SELECT * INTO Backup FROM UserData您可以通过为每次登录尝试运行两种身份验证方法（加密和未加密）来获得额外的信心，如果它们产生不同的结果，则会收到发送给您的警报电子邮件。 此更改对您的用户不可见，因此它可以运行数周甚至数月。 一旦您发现旧的和新的身份验证适用于足够高比例的用户，请停用旧的身份验证。
You can get extra confidence by running both authentication methods (encrypted and unencrypted) for each login attempt, and if they yield a different outcome, get an alert e-mail sent to you. This change is not visible to your users, so it can run for weeks and even months. Once you see that the old and the new authentication works for a high enough percentage of your users, deactivate the old one.
如果可能的话，您可以尝试以下操作：向所有用户发送一封电子邮件，要求其更新密码，并设置一个超时期限，在此之后，如果他们不更改密码，他们将无法工作。 对这些新密码进行哈希处理并存储哈希值。 这需要对前端进行一些更改（即它发送回的数据）。
If possible you can try this: Send out an email to all your users to update their passwords with a time-out period, after which they cannot work if they do not change their passwords. Hash these new passwords and store the hash. This would require some changes on the frontend (i.e. the data it sends back).