总体而言，这对于普通网站来说似乎是合理的。我会建议一些小的改动：

• 就个人而言，我会考虑删除秘密问题。我认为安全问题不会增加太多安全性。但它们是用户可能忘记或出错的另一个秘密，因此安全问题会对用户体验产生实际影响。有学术研究表明，秘密问题的答案具有低熵，并且可以像密码一样容易地通过网络钓鱼。因此，我认为删除秘密问题会提高可用性，并且不会对安全性产生太大影响。实际上，系统的安全性依赖于用户的电子邮件地址。秘密问题解决的主要风险是用户关闭了他们的电子邮件帐户，然后其他人注册了相同的电子邮件并能够猜出用户的用户名；或用户在哪里 s 电子邮件帐户被劫持；或用户与其他人共享他/她的电子邮件帐户的地方。

• 我会在用户选择密码的页面上添加一个密码强度指示器。看看像谷歌这样的网站使用什么网站，那里有一个动态指示密码强度的栏，并且会改变颜色（红色 = 差，黄色 = 边界线，绿色 = 好）。这可能会诱导/帮助用户选择更好的密码。您可能不需要强加最低强度要求——这可能会提供足够的推动力。

• 我会让恢复代码有时间限制，因此它必须在一两个小时内（比如说）使用，然后在有效期结束后不再被接受。此外，该链接应在首次使用时立即过期（感谢@AviD 指出这一点）。

• 对与选择/设置/提交用户密码相关的所有活动使用 SSL/TLS（即 HTTPS）。这将防止通过开放无线网络访问您网站的用户的密码被窃听；但是，它不能防止 Firesheep。考虑在站点范围内采用 SSL/TLS，这将防止 Firesheep。

（我假设您没有任何特别敏感的安全需求：例如，这不适用于网上银行等。）

像往常一样 - 取决于您所保护的内容的性质。对于基本信息似乎足够体面。如果您正在为高端的东西（如网上银行）编写代码，可能需要更多。

每当使用秘密问题/答案时，答案最终会在某个地方代替密码，这很容易成为您最薄弱的环节。由于秘密答案很容易被攻击者通过谷歌搜索找到，因此它们可能是一个真正的风险因素 - 并且很难触及那些非常不寻常以至于它们相对不容易弄清楚的问题和问题如此深奥或不适用，以至于帐户所有者无法回答。

我喜欢@Iszi 让人们编写自己的问答集的想法——这很好地规避了这个问题。

如果您提到攻击者是否可以拦截来自您系统的电子邮件，那么他们不需要用户的帐户。这意味着最大的防线是共享的秘密。

您没有说，但我假设所有帐户设置和密码重置都发生在 SSL/TLS 保护下，对吗？如果不是，那可能是更大的问题。