CRV2 ForgotPassword - Revision history

Abbas Naderi: /* AntiPatterns: Forget password. */ user listing

2013-10-18T17:28:16Z

‎AntiPatterns: Forget password.: user listing

Larry Conklin at 22:17, 13 October 2013

2013-10-13T22:17:31Z

Larry Conklin at 22:05, 13 October 2013

2013-10-13T22:05:33Z

Larry Conklin: Created page with "==Overview== 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 syst..."

2013-09-22T16:07:40Z

Created page with "==Overview== 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 syst..."

New page

==Overview==
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.”

← Older revision		Revision as of 17:28, 18 October 2013
Line 34:		Line 34:
	# Do not send a onetime password to allow user to reset his/her password. This password would be stored even if for a short time in clear text and email storage is not the place to store passwords.		# Do not send a onetime password to allow user to reset his/her password. This password would be stored even if for a short time in clear text and email storage is not the place to store passwords.
	# Do not have an error message saying account does not exists for this email address. This could be used to find out if user has an account for a porn or another site if hacker knows users email address.		# Do not have an error message saying account does not exists for this email address. This could be used to find out if user has an account for a porn or another site if hacker knows users email address.
		+	# '''Important''': Do not allow listing of users. The password reset tokens should be uniquely generated, and be cryptographically secure random. Otherwise a listing of users can be generated from forget password feature.

@@ Line 12: / Line 12: @@
 Send notifications that account information has been changed for registered email.
 Set appropriate time out value. I.e. If user does not respond to email within 48 hours then user will be frozen out of system until user re-affirms password change.
@@ Line 30: / Line 21: @@
 # 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.”

@@ Line 1: / Line 1: @@
 ==Overview==
 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.
+# 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 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.
+# 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.
+# 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.
+# 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.”
+# 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.”