How to generate random password, or temporary URL, for resetting password in Zend Framework?

Question

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 f

Answer 1

Zend Framework does not have a password-generating class. Here's an article on how to use the PEAR module Text_Password to 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:

• Define a table AccountReset with fields: reset_id (GUID primary key), account_id (reference to Accounts.account_id), and expiration (timestamp).
• Implement an action called AccountController::resetAction(), i.e. in the same controller you use for creating accounts, logging in, changing passwords, etc.
• When a user chooses to reset his account, insert a new row in an AccountReset table with a new GUID, a reference to the user's account, and an expiration 30 minutes or so in the future.
• Send an email to the address on file for that user, including an URL he should click on: "https.../account/reset/reset_id/<GUID>" (if you're clever with routing rules, you can shorten that URL, but keep the GUID in it).
• When AccountController::resetAction() receives the request, it looks up its reset_id param in the AccountReset table. If that GUID exists and the expiration time has not passed, present the user with a form to change his password (without requiring he is authenticated and logged in).
• If resetAction() receives a request with no GUID, or the GUID doesn't exist in the database, or that row has passed its expiration, 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 AccountReset table, 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/.