如何生成随机密码或临时 URL，用于在 Zend Framework 中重置密码？
我有一个使用 Zend_Auth_Adapter_DbTable 的基本身份验证过程。 我的身份验证控制器上有登录和注销操作。 现在我想创建一个功能，通过自动生成密码、保存新密码并向他们发送包含新生成密码的电子邮件来重置忘记的密码。
执行此操作的最佳流程是什么？ 我应该如何生成新密码？ Zend 框架有什么可以让这变得更容易吗？
我还听说过发送一封包含短期页面链接的电子邮件，让他们设置新密码。 使用 Zend 框架如何实现这一点？
I have a basic authentication process that uses Zend_Auth_Adapter_DbTable. I have login and logout actions on my Authentication Controller. Now I want to create a function to reset forgotten passwords by automatically generating a password, saving the new password, and sending them an email with the newly generated password.
What would be the best process to go about doing this? How should I generate a new password? Does the Zend Framework have anything that would make this easier?
I have also heard about sending an email with a link to a short term page that lets them set a new password. How might this be done with the Zend Framework?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Zend Framework 没有密码生成类。 这里有一篇关于如何使用 PEAR 模块
Text_Password生成密码的文章：https://web .archive.org/web/1/http://blogs.techrepublic%2ecom%2ecom/howdoi/?p=118
但是，通过普通电子邮件发送密码并不是一个好的安全做法。 相反，您应该重置他们的帐户，以便他们可以暂时登录而无需提供密码（给定您在电子邮件中发送给他们的过期 URL），并且一旦他们登录，要求他们将自己的密码更新为他们< /em> 知道。 然后存储密码的加盐哈希值。
以下是我在 Zend Framework 中执行此操作的一些建议：
AccountReset：reset_id（GUID 主键）、account_id（参考Accounts.account_id）和expiration（时间戳）。AccountController::resetAction()的操作，即在您用于创建帐户、登录、更改密码等的同一控制器中。AccountReset表中，其中包含新的 GUID、对用户帐户的引用以及未来 30 分钟左右的过期。<GUID>”（如果您擅长路由规则，则可以缩短该 URL，但保留 GUID）。AccountController::resetAction()收到请求时，它会在AccountReset表中查找其reset_id参数。 如果该 GUID 存在并且过期时间尚未过去，则向用户提供一个表单以更改其密码（不需要他进行身份验证并登录）。resetAction()收到没有 GUID 的请求，或者数据库中不存在该 GUID，或者该行已过过期，则可能会出现此操作用户可以通过按钮发起新的重置请求，并发送带有新 GUID 的电子邮件。 请记住将此按钮设置为 POST 请求！由于 GUID 仅通过电子邮件发送至该用户的地址，因此其他人无法获得更改密码的访问权限。 即使用户的电子邮件被拦截，GUID 也只能在有限的时间内授予该访问权限。
如果您想更加谨慎，可以记下
AccountReset表中的客户端 IP 地址，并要求在 30 分钟的时间内从具有相同 IP 地址的客户端更改密码。这只是即兴的，我还没有实现它或评估它的适当安全性。 如果您负责实施安全性，那么您就有责任阅读安全问题。 一个备受推崇的 PHP 安全资源是 http://phpsecurity.org/。
Zend Framework does not have a password-generating class. Here's an article on how to use the PEAR module
Text_Passwordto generate a password:https://web.archive.org/web/1/http://blogs.techrepublic%2ecom%2ecom/howdoi/?p=118
However, it's not a good security practice to send the password in a plain email. Instead, you should reset their account so they can temporarily log in without giving a password (given an expiring URL you send them in the email), and once they log in, require them to update their own password to something they know. Then store the salted hash of their password.
Here's some suggestion off the top of my head for doing this in Zend Framework:
AccountResetwith fields:reset_id(GUID primary key),account_id(reference toAccounts.account_id), andexpiration(timestamp).AccountController::resetAction(), i.e. in the same controller you use for creating accounts, logging in, changing passwords, etc.AccountResettable with a new GUID, a reference to the user's account, and anexpiration30 minutes or so in the future.<GUID>" (if you're clever with routing rules, you can shorten that URL, but keep the GUID in it).AccountController::resetAction()receives the request, it looks up itsreset_idparam in theAccountResettable. If that GUID exists and theexpirationtime has not passed, present the user with a form to change his password (without requiring he is authenticated and logged in).resetAction()receives a request with no GUID, or the GUID doesn't exist in the database, or that row has passed itsexpiration, then this action may instead present the user with a button to initiate a new reset request, and send an email with a new GUID. Remember to make this button a POST request!Because the GUID is communicated only in email to the address for that user, no one else can gain access to change the password. Even if the user's email gets intercepted, there's only a limited time the GUID would grant that access.
If you want to be even more cautious, you could make note of the client IP address in the
AccountResettable, and require the password be changed from a client with the same IP address, within that 30 minute window.This is only off-the-cuff, and I haven't implemented it or evaluated it for proper security. If you are responsible for implementing security, it's your duty to read up on security issues. A well-regarded resource for PHP security is http://phpsecurity.org/.