存储可解密密码的安全方法
我正在用 PHP 制作一个应用程序，并且要求必须能够解密密码，以避免将来将用户数据库切换到不同系统时出现问题。考虑到不可能修改这个未来系统的密码方法，并且我需要纯文本密码才能生成密码。
该计划是使用存储在服务器上的公钥来加密用户的密码。身份验证是通过加密输入并比较结果来完成的。没有完成解密。能够解密的私钥存储在异地供以后使用。
您建议使用什么加密/解密算法？当您认为攻击者无法获得私钥时，加密的密码是否仍与散列（MD5/SHA1）一样安全？
I'm making an application in PHP and there is a requirement that it must be possible to decrypt the passwords in order to avoid problems in the future with switching user database to different system. Consider that it's not possible to modify this future system's password method and I need plain text passwords in order to have the passwords generated.
The plan is to encrypt the user's password with a public key that is stored on the server. Authentication is done by encrypting the input and comparing the results. There is NO decryption done. The private key capable of the decryption is stored off-site for later usage.
What encryption/decryption algorithm would you suggest? Are the encrypted passwords still as safe as hashing (MD5/SHA1) when you consider the private key is not available to the attacker?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我将重新表述 Jammer 的方法 -
如果攻击者获得了数据库，他无法解密密码，因为他没有私钥。他无法获得私钥，因为私钥位于他无法触及的银行金库中。由于盐的原因，两个相同的密码仍然会以不同的方式存储在数据库中。
我不建议使用上述方法，因为将来任何时候有人都可能滥用私钥并访问所有密码。
但如果你保证私钥始终保持私密，那么我不认为存在技术缺陷。
当然，我可能是错的。
I'll rephrase Jammer's approach -
If an attacker gets the database, he can't decrypt the passwords because he doesn't have the private key. He cannot get the private key because it is in a bank vault outside his reach. Two identical passwords will still be stored differently in the database because of the salt.
I don't recommend using the above approach because at any point of time in the future someone could abuse the private key and get access to all passwords.
But if you guarantee that the private key will always remain private, then I don't see a technical flaw.
I could be wrong, of course.
不要解密密码。如果您将来需要更改密码系统，请添加一个名为 storage_type （或其他）的字段。
然后，当您需要更改密码时，您将检查它是否是旧密码。如果是，下次登录时，您可以更改密码编码。否则，请使用新系统登录。
Don't decrypt the password. If you need to change the password system in the future, add a field called storage_type (or whatever).
Then, when you need to change the passwords, you will check if it's an old password. If it is, next time they login, you can change the password encoding. Otherwise, login with the new system.
能够解密密码是一个坏主意（并且可能没有任何方法比未加密地存储它们更好）。听起来您的主要问题是如果您更改存储方法，则无法使用密码。就像 Linux 所做的那样，存储你如何用密码对密码进行哈希处理。例如 $1$salt$hash 就是 MD5。这样，如果您决定更改密码的存储方式，您仍然可以检查旧密码（如果有人正确登录，您可以使用新的哈希值更新他们的密码）。
Being able to decrypt the passwords is a bad idea (and there's probably not any way of doing it that would be much better than storing them unencrypted). It sounds like your main problem is being able to use the passwords if you change your storage method. Just do what Linux does, store how you're hashing the password with the password. So for example $1$salt$hash is MD5. That way, if you decide to change how passwords are stored, you can still check against the old passwords (and if someone logs in correctly, you can update their password with the new hash).
我看到的唯一问题是，大多数公私密钥加密代码将使用公钥加密对称密钥，并依赖私钥解密，然后使用对称密钥加密消息。
你想用公钥直接加密密码+盐。
因此，针对您的系统的攻击可以归结为：
The only problem I see is that most public-private key encryption code out there will encrypt a symmetric key using the public key, and rely on the private key decrypting that, then use the symmetric key to encrypt the message.
You want to use the public key to directly encrypt the password+salt.
So attacks against your system boil down to:
对于大多数应用程序来说，存储密码的 SHA-1 哈希值就足够了。
是的，大多数哈希算法中都存在已知的冲突，但这并不意味着实际的攻击向量。尤其是当你对哈希值加盐时。
对于您的 salt：将其存储在一个配置文件中，该文件无法从外部访问，但可以由您的 PHP 安装读取。
For most applications it is more than sufficient to store SHA-1 hashes of passwords.
Yes, there are known collisions in most hashing algorithms, but that doesn't imply an actual attack vector. Especially when you're salting the hashes.
For your salt: Store it in a configuration file that is not accessible from the outside but can be read by your PHP installation.