将用户安全问题的答案作为加密密钥的一部分，并且不要将安全问题答案存储为纯文本(而是散列)

抱歉，但只要你有办法破解他们的密码，就不可能是安全的。痛苦地抗争，如果你输了，CYA。

我也有同样的问题。同样的，我总是认为有人入侵我的系统不是“如果”的问题，而是“什么时候”的问题。

所以，当我必须做一个网站，需要存储一个可恢复的机密信息，如信用卡或密码，我所做的是:

使用openssl_encrypt(字符串$data，字符串$method，字符串$password)进行加密 PHP手册。 数据参数: 敏感资料(例如用户密码) 如果需要，序列化，例如，如果信息是一个数据数组，如多个敏感信息 密码arg:使用一个只有用户知道的信息，比如: 用户牌照 社会保险号码 用户电话 用户母名 在注册时通过电子邮件和/或短信发送的随机字符串 方法参数: 选择一种密码方法，如“aes-256-cbc” 永远不要将password参数中使用的信息存储在数据库(或系统中的任何地方)

当需要检索此数据时，只需使用“openssl_decrypt()”函数并向用户询问答案。例如:“要收到你的密码，请回答这个问题:你的手机号码是多少?”

PS 1:永远不要将存储在数据库中的数据用作密码。如果您需要存储用户的手机号码，那么永远不要使用此信息来编码数据。总是使用只有用户知道的信息，或者非亲属很难知道的信息。

PS 2:信用卡信息，比如“一键购买”，我所做的就是使用登录密码。这个密码在数据库中哈希(sha1, md5等)，但在登录时，我将明文密码存储在会话或非持久性(即在内存中)安全cookie中。这个简单的密码永远不会留在数据库中，实际上它总是留在内存中，在节结束时销毁。当用户点击“一键购买”按钮时，系统使用此密码。如果用户使用facebook, twitter等服务登录，那么我会在购买时再次提示密码(好吧，这不是完全的“点击”)，然后使用用户曾经登录的服务的一些数据(如facebook id)。

另一个你可能没有考虑到的选择是允许通过电子邮件进行操作。这有点麻烦，但我为一个客户端实现了这个功能，该客户端需要系统“外部”的用户来查看(只读)系统的某些部分。例如:

一旦用户注册，他们就拥有完全的访问权限(就像普通用户一样) 网站)。注册必须包括电子邮件。 如果需要数据或操作，而用户不需要 记住他们的密码，他们仍然可以通过 点击一个特殊的“给我发邮件以获得许可”按钮，就在常规的“提交”按钮旁边。 然后，请求以超链接发送到电子邮件，询问他们是否希望执行该操作。这类似于密码重置电子邮件链接，但它不是重置密码，而是执行一次性操作。 然后用户点击“Yes”，它确认应该显示数据，或者应该执行操作，显示数据等等。

正如你在评论中提到的，如果电子邮件被泄露，这将不起作用，但它确实解决了@joachim关于不想重置密码的评论。最终，他们将不得不使用密码重置，但他们可以在更方便的时候这样做，或者根据需要在管理员或朋友的帮助下这样做。

该解决方案的另一种方法是将操作请求发送给第三方可信管理员。这对于老年人、智障人士、非常年轻或其他困惑的用户来说效果最好。当然，这需要一个可信的管理员来支持这些人的行动。

如果您不能拒绝存储可恢复密码的要求，那么您的反对论点如何?

我们可以正确地散列密码并为用户建立一个重置机制，或者我们可以从系统中删除所有个人身份信息。您可以使用电子邮件地址来设置用户偏好，但仅此而已。使用cookie可以自动提取未来访问的偏好，并在一段合理的时间后丢弃数据。

密码策略中经常被忽视的一个选项是是否真的需要密码。如果你的密码策略所做的唯一一件事就是导致客户服务电话，也许你可以摆脱它。

Michael Brooks一直对cwe257直言不讳——事实上，无论您使用什么方法，您(管理员)仍然可以恢复密码。那么下面这些选项怎么样:

使用其他人的公钥(一些外部授权机构)加密密码。这样，您就不能亲自重建密码，用户必须去外部权威机构要求恢复他们的密码。 使用从第二个口令短语生成的密钥加密密码。在客户端进行加密，绝不将其明文传输到服务器。然后，为了恢复，通过从他们的输入重新生成密钥，再次在客户端解密。不可否认，这种方法基本上是使用第二个密码，但您总是可以告诉他们把它写下来，或者使用旧的安全问题方法。

我认为1。是更好的选择，因为它允许您在客户的公司内指定某人持有私钥。确保他们自己生成密钥，并将其与指示一起存储在保险箱等。您甚至可以通过选择只加密密码并向内部第三方提供密码中的某些字符来增加安全性，这样他们就必须破解密码才能猜测它。将这些字符提供给用户，他们可能会记住它是什么!