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:
http://blogs.techrepublic.com.com/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/.