Difference between revisions of "Codereview-Authentication"

From OWASP
Jump to: navigation, search
m (Review - spelling etc)
Line 12: Line 12:
  
 
Password strength should be enforced upon a user setting/selecting ones password. Passwords should be complex in composition.
 
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 submitt a new password.
+
Such checks should be done on the backend/server side of the application upon an attempt to submit a new password.
  
 
====Bad Example====
 
====Bad Example====
Line 34: Line 34:
 
  a defined maximum length (as with all external input)
 
  a defined maximum length (as with all external input)
 
   
 
   
  no contigous characters (123abcd)
+
  no contiguous characters (123abcd)
 
  not more than 2 identical characters in a row (1111)
 
  not more than 2 identical characters in a row (1111)
  
 
Such rules should be looked for in code and used as soon as the http request is received.
 
Such rules should be looked for in code and used as soon as the http request is received.
The rules can be comples RegEx expressions or logical code statements:
+
The rules can be complex RegEx expressions or logical code statements:
  
 
  if password.RegEx([a-z])
 
  if password.RegEx([a-z])
Line 62: Line 62:
 
  SQL injection can be sued to bypass authentication functionality and even add a malicious user to a system for future use.
 
  SQL injection can be sued to bypass authentication functionality and even add a malicious user to a system for future use.
 
*[[Reviewing Code for Data Validation]]
 
*[[Reviewing Code for Data Validation]]
  Data validation of all external input musb be erfromed. This also goes for authentication fields.
+
  Data validation of all external input must be performed. This also goes for authentication fields.
 
*[[Reviewing code for XSS issues]]
 
*[[Reviewing code for XSS issues]]
  Cross site scripting can be used on the authentication page to perfrom identity theft, Phishing, and session hijacking attacks
+
  Cross site scripting can be used on the authentication page to perform identity theft, Phishing, and session hijacking attacks
 
*[[Reviewing Code for Error Handling]]
 
*[[Reviewing Code for Error Handling]]
 
  Bad/weak error handling can be used to establish the internal workings of the authentication functionality such as giving insight into the database structure, insight into valid and invalid user ID's etc
 
  Bad/weak error handling can be used to establish the internal workings of the authentication functionality such as giving insight into the database structure, insight into valid and invalid user ID's etc
 
*[[Reviewing Code for Authentication]]
 
*[[Reviewing Code for Authentication]]

Revision as of 15:20, 26 August 2008

OWASP Code Review Guide Table of Contents

Contents


Introduction

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

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.

Bad Example

Simply checking that a password is not NULL is not sufficient:

String password = request.getParameter("Password");
if (password == Null) 
   {throw InvalidPasswordException()
   }

Good Example

Passwords should be checked for the following composition or a variance of such

at least: 1 Upper character (A-Z)
at least: 1 Lower character (a-z)
at least: 1 digit (0-9)
at least one special character (!"£$%&...)
a defined minimum length (8 chars)
a defined maximum length (as with all external input)

no contiguous characters (123abcd)
not more than 2 identical characters in a row (1111)

Such rules should be looked for in code and used as soon as the http request is received. The rules can be complex RegEx expressions or logical code statements:

if password.RegEx([a-z])
   and password.RegEx([A-Z])
   and password.RegEx([0-9])
   and password.RegEx({8-30})
   and password.RexEX([!"£$%^&*()])
   return true;
else
return false;


(?=^.{8,30}$)(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%^&*()_+}{"":;'?/>.<,]).*$ 


Vulnerabilities related to authentication

There are many issues relating to authentication which utilises form fields. Inadequate field validation can give rise to the following issues:


SQL injection can be sued to bypass authentication functionality and even add a malicious user to a system for future use.
Data validation of all external input must be performed. This also goes for authentication fields.
Cross site scripting can be used on the authentication page to perform identity theft, Phishing, and session hijacking attacks
Bad/weak error handling can be used to establish the internal workings of the authentication functionality such as giving insight into the database structure, insight into valid and invalid user ID's etc