CRV2 ForgotPassword

Revision as of 11:07, 22 September 2013 by Larry Conklin (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


If your web site needs to have user authentication then most likely it will require user name and password to authenticate user accesses. However as computer system have increased in complexity, so has authenticating users has also increased. As a result the code reviewer needs to be aware of the benefits and drawbacks of user authentication referred to as “Direct Authentication” pattern in this section. This section is going to emphasis design patterns for when users forget user id and or password and what the code reviewer needs to consider when reviewing how user id and passwords can be retrieved when forgotten by the user and how to do this in a secure manner.

General Considerations

  • The identity and shared secret/password must be transferred using encryption to provide data confidentiality. HTTPS should also be used but in itself should not be the only mechanism used for data confidentiality.
  • A shared secret can never be stored in clear text format, even if only for a short time in a message queue.
  • A shared secret must always be stored in hashed or encrypted format in a database.
  • The organization storing the encrypted shared secret does not need the ability to view or decrypt users passwords. User password must never be sent back to a user.
  • If the client must cache the username and password for presentation for subsequent calls to a Web service then a secure cache mechanism needs to be in place to protect user name and password.
  • When reporting an invalid entry back to a user, the username and or password should no be identified as being invalid. User feed back/error message must consider both user name and password as one item “user credential”. I.e. “The username or password you entered is incorrect.”