1. Software Standards Specification
  2. Software Requirements Definition
  3. Software Best Practices
  4. Input Validation
  5. Output Validation
  6. Cookie Requirements
  7. Access Failure Error Checking
  8. Buffer Overflow
  9. Code Structure
  10. Software Functions
  11. Software Modules
  12. Requirements for Variables
  13. Software Code Comment Requirements
  14. Quality Code Requirements
  15. Software Code Review
  16. Software Code Testing Requirements
  17. Software Change Control

    Security Best Practices

  18. Secure Functional Requirements
  19. Account Creation
  20. Change Password
  21. Forgot Password
  22. Personal Question
  23. Contact Webmaster
  24. CAPTCHA Tests
  25. Answer Verification

Forgot password recommendations

This page provides a password reset processes that can be used to securely reset a user's forgotten password. This process is one of the simplest for the user and is secure. It's only drawback is that an HTTPS Certificate Authority (CA) signed certificate is required for security. If your site or application contains anything that should be kept at all secure or even to prevent minor fraud including fraud from people falsely rating sites or products, you should follow these recommendations. These recommendations are very strongly recommended and should be required by your project manager.

Never email the password for the account in the clear for a "forgot my password" situation. A recommended method and simplest method would be use of the following process:

  1. The user enters their email address or account ID and clicks on the "forgot password" link or button.
  2. The server displays the security question and the user answers the question. The security question must be a strong question and answer combination. This will be discussed later. This could be a password hint if done well but a good security question is normally more secure.
  3. If the answer is incorrect, the registered email address for the account should be emailed with the information so the account owner will know someone may be trying to break in.
  4. If the answer is correct, a new password should be created automatically and at random by the system and displayed to the user but the account should be locked. The new password should be displayed during a secure HTTPS session and the user should be told to memorize it and use the password change page later to change it to something they can more easily remember later.
  5. An email is sent to the account on record. The user must click on a link in the email within 1 hour to accept the password change and unlock the account. Part of the link in the email is a random security code needed to indicate the email account on record received the email.
  6. If the hour expires before the link is clicked on, the password is changed back to the original password.

Security Requirements

  • The page that receives the password hint must be able to lock the password reset capability for at least an hour after three failed attempts to use it. If the password reset attempt fails, the system could become progressively slower until the password reset ability is effectively locked. Then a minimum period of password reset inactivity would be required for it to return to a normal state. If the ability to attempt to reset forgotten passwords is limited to a small enough tries in a set period of time, a CAPTCHA test wouold not be required and it would be more secure than the use of CAPTCHA.
  • The page that displays the password hint or security question must either limit the ability to reset forgotten passwords or use a CAPTCHA test to prevent automated attempts to use it.
  • The new password must be transmitted to the user using the HTTPS protocol with a CA signed certificate.
  • The password hint question and answer must be transmitted using the HTTPS protocol with a CA signed certificate.
  • The password hint question or answer must not be cached in the user's browser.
  • The user must be prevented from using the "reload page" function in their browser to retransmit the information.
  • The system should always store the sender's (person who resets or attempts to reset the password) information in a database or a log file on the server so administrators can examine it later. The system should store this information whether the attempt is successful or not.
  • If a password reset attempt fails, the registered email address for the account should be emailed with the information so the account owner will know someone may be trying to break in. Information to be sent to the user should merely be an indication of a password reset failure after three failed attempts. The date and time of the attempts should be sent. The email should not include the question asked or the answer given, since the answer could be a typo of the correct answer. The information about the IP address of the user and other information could be sent but is not recommended since this information should be stored on the server and there may be legal issues.
  • Dont allow eother an email change or a secret question change for a week after the user account has successfully performed the forgot password process. This will prevent an attacker from completely taking over the account if they successfully defeat the secret question.


There is no good way to do a password reset without using the HTTPS protocol. If your security needs are that low, you should question whether user accounts are really necessary. If you don't use the HTTPS protocol, the password reset process will not be secure at all. A server certificate will be required to use the HTTPS protocol. Obviously the certificate to use HTTPS costs money (unless you want to generate your own unregistered certificate which creates another security risk) because it must be registered with a publically known Certificate Authority (CA). Without the use of a digitally signed certificate from a CA, the HTTPS session is vulnerable to a man in the middle attack. This means that someone in the middle could intercept the information being exchanged between your server and the client. The person in the middle could substitute their certificate to the user rather than yours and not only see what the user and your server are sending, but they could change the information.