Codereview-Authentication - Revision history

Thomas Herlea: Added navigation to facilitate sequential reading online

2010-09-09T15:51:25Z

Added navigation to facilitate sequential reading online

2009-05-05T11:55:13Z

‎Vulnerabilities related to authentication

2009-05-05T11:54:05Z

‎Password Storage Strategy

2009-01-25T23:35:10Z

‎Password Storage Strategy

2009-01-25T23:34:03Z

‎Cookieless Forms authentication

2009-01-25T23:33:37Z

‎Cookieless Forms authentication

2009-01-25T23:32:24Z

‎Good Example

2009-01-25T23:31:45Z

‎Weak Passwords and Password Functionality

2009-01-25T23:31:13Z

‎Introduction

2009-01-16T13:53:23Z

‎'''.NET Authentication controls'''

@@ Line 1: / Line 1: @@
-[[OWASP Code Review Guide Table of Contents]]__TOC__
+{{LinkBar
-[[Category:OWASP Code Review Project]]
+  | useprev=PrevLink | prev= Code Reviews and Compliance| lblprev=
+  | usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
 ==Introduction==
@@ Line 151: / Line 154: @@
 *[[Hashing Java|Hashing with Java]]
+{{LinkBar
 [[Category:OWASP Code Review Project]]

@@ Line 145: / Line 145: @@
 *[[Reviewing Code for Data Validation]]
 Data validation of all external input must be performed. This also goes for authentication fields.
-*[[Reviewing code for XSS issues]]
+*[[Reviewing Code for Cross-site scripting]]
 Cross site scripting can be used on the authentication page to perform identity theft, Phishing, and session hijacking attacks.
 *[[Reviewing Code for Error Handling]]

@@ Line 116: / Line 116: @@
 Passwords should be stored using a one-way hash algorithm. One way functions (SHA-256 SHA-1 MD5, ..;) are also known as Hashing functions. Once passwords are persisted, there is no reason why they should be human-readable. The functionality for authentication performs a hash of the password passed by the user and compares it to the stored hash. If the passwords are identical, the hashes are equal.
-Storing a hash of a password, which can not be reversed, makes it more difficult to recover the plain text passwords. It also ensures that administration staff for an application does not have access to other users’ passwords, and hence helps mitigate the internal threat vector.
+Storing a hash of a password, which cannot be reversed, makes it more difficult to recover the plain text passwords. It also ensures that administration staff for an application does not have access to other users’ passwords, and hence helps mitigate the internal threat vector.
 Example code in Java implementing SHA-1 hashing:

@@ Line 114: / Line 114: @@
 The storage of passwords is also of concern, as unauthorized access to an application may give rise to an attacker to access the area where passwords are stored.
-Passwords should be stored using a one-way hash algorithm. One way functions (SHA-256 SHA-1 MD5, ..;) are also known as Hashing functions. Once passwords are persisted, there is not reason why they should be human-readable. The functionality for authentication performs a hash of the password passed by the user and compares it to the stored hash. If the passwords are identical, the hashes are equal.
+Passwords should be stored using a one-way hash algorithm. One way functions (SHA-256 SHA-1 MD5, ..;) are also known as Hashing functions. Once passwords are persisted, there is no reason why they should be human-readable. The functionality for authentication performs a hash of the password passed by the user and compares it to the stored hash. If the passwords are identical, the hashes are equal.
 Storing a hash of a password, which can not be reversed, makes it more difficult to recover the plain text passwords. It also ensures that administration staff for an application does not have access to other users’ passwords, and hence helps mitigate the internal threat vector.

@@ Line 107: / Line 107: @@
 * UseDeviceProfile – the default setting if not defined; uses cookie-based authentication tickets only if the device profile supports cookies. A probing function is not used.
- cookieless="UseUri" : What may be found in the <forms> element above
+cookieless="UseUri" : What may be found in the <forms> element above
 When we talk about probing we are refering to the user agent directive in the HTTP header. This can inform ASP.NET is cookies are supported.

@@ Line 98: / Line 98: @@
 ====Cookieless Forms authentication====
-Authentication tickets in forms are by default stored in cookies (Authentication tickets are used to remember if the user has authenticated to the system), such as a unique id in the cookie of the HTTP header. Other methods to preserve authentication in the stateless HTTP protocol. The directive cookieless can define thet type of authentication ticket to be used.
+Authentication tickets in forms are by default stored in cookies (Authentication tickets are used to remember if the user has authenticated to the system), such as a unique ID in the cookie of the HTTP header. Other methods to preserve authentication in the stateless HTTP protocol. The directive cookieless can define thet type of authentication ticket to be used.
 Types of cookieless values on the <forms> element:

@@ Line 26: / Line 26: @@
 Passwords should be checked for the following composition or a variance of such
-* at least: 1 Upper character (A-Z)
+* at least: 1 uppercase character (A-Z)
-* at least: 1 Lower character (a-z)
+* at least: 1 lowercase character (a-z)
 * at least: 1 digit (0-9)
 * at least one special character (!"£$%&...)

@@ Line 13: / Line 13: @@
 ===Weak Passwords and Password Functionality===
-Password strength should be enforced upon a user setting/selecting ones password. Passwords should be complex in composition. Such checks should be done on the backend/server side of the application upon an attempt to submit a new password.
+Password strength should be enforced upon a user setting/selecting a password. Passwords should be complex in composition. Such checks should be done on the backend/server side of the application upon an attempt to submit a new password.
 ====Bad Example====

@@ Line 8: / Line 8: @@
 Depending on your requirements, there are several available authentication mechanisms to choose from. If they are not correctly chosen and implemented, the authentication mechanism can expose vulnerabilities that attackers can exploit to gain access to your system.
-The storage of passwords and user credentials is also an issue from a defense in depth approach, but also from a compliance standpoint. The following section also discusses password storage and what to review for.
+The storage of passwords and user credentials is an issue from a defense in depth approach, but also from a compliance standpoint. The following section also discusses password storage and what to review for.
 The following discusses aspects of source code relating to weak authentication functionality. This could be due to flawed implementation or broken business logic: Authentication is a key line of defence in protecting non-public data, sensitive functionality.

@@ Line 54: / Line 54: @@
 The <'''authentication'''> element configures the authentication mode that your applications use.
 <'''authentication'''>
@@ Line 70: / Line 69: @@
 Next, configure Forms authentication using the child <forms> element. The
 following fragment shows a secure <forms> authentication element configuration:
   <authentication mode="Forms">