This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for authentication"

From OWASP
Jump to: navigation, search
m (Amend Authentication links)
 
(42 intermediate revisions by 9 users not shown)
Line 1: Line 1:
{{Template:OWASP Testing Guide v2}}
+
{{Template:OWASP Testing Guide v4}}
  
 +
''' 4.5 Authentication Testing '''
 +
----
  
==4.4.1 Default or guessable user accounts==
 
  
===Causes===
+
Authentication (Greek: αυθεντικός = real or genuine, from 'authentes' = author ) is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the thing are true. Authenticating an object may mean confirming its provenance, whereas authenticating a person often consists of verifying her identity. Authentication depends upon one or more authentication factors.
The source for this problem is often inexperienced IT personnel, unaware of the importance of changing default passwords on installed infrastructure components, programmers, leaving backdoors so they can easily access and test the application, later forgetting to remove them, application administrators and users that chose an easy username and password for themselves, and application with built in, non-removable default accounts with a preset username and password. Another problem is blank passwords, which are simply a result of security unawareness and willingness to simplify things.
 
  
===Blackbox Testing===
 
  
Note - before approaching the test, it is important to understand whether the environment you are testing is a production environment. Modifying passwords or locking out users on a production environment can lead to undesired consequences.  
+
In computer security, authentication is the process of attempting to verify the digital identity of the sender of a communication. A common example of such a process is the log on process. Testing the authentication schema means understanding how the authentication process works and using that information to circumvent the authentication mechanism.
  
In blackbox testing we know nothing about the application, its underlying infrastructure, and any username and/or password policies. Often this is not the case and some information about the application is provided – simply skip the steps that refer to obtaining information you already have.
 
  
When testing a known application interface, such as a Cisco router web interface, or Weblogic admin access, check the known usernames and passwords for these devices. This can be done either by Google, or using one of the references in the Further Reading section.
+
[[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel  (OTG-AUTHN-001)]]
  
When facing a homegrown application, to which we do not have a list of default and common user accounts, we need to test it manually, following these guidelines:
+
[[Testing for default credentials (OTG-AUTHN-002)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]]
* Try the following usernames - "admin", "administrator", "root", "system", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing", and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you successfully managed to identify any of the above usernames, attempt passwords in a similar manner.
 
* Application administrative users are often named after the application. This means if you are testing an application named "Obscurity", try using obscurity/obscurity as the username and password.
 
* When performing a test for a customer, attempt using names of contacts you have received as usernames.
 
* Attempt using all the above usernames with blank passwords.
 
  
===Suggested Tools - <TBD>===
+
[[Testing for Weak lock out mechanism (OTG-AUTHN-003)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]]
  
===Whitebox Testing===
+
[[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]]
The steps described next rely on an entirely White Box approach. If only some of the information is available to you, refer to blackbox testing to fill the gaps.
 
* Talk to the IT personnel to determine which passwords they use for administrative access. Check whether these usernames and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system"). Note blank passwords.
 
* Check in the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.
 
* Examine the code for hardcoded usernames and passwords.
 
  
===Further Reading===
+
[[Testing for Vulnerable Remember Password (OTG-AUTHN-005)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]]
* http://www.cirt.net/cgi-bin/passwd.pl
 
* http://phenoelit.darklab.org/cgi-bin/display.pl?SUBF=list&SORT=1
 
* http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
 
* http://www.virus.org/index.php?module=defaultpwd&func=display&cid=1
 
  
==Control for automated attacks? - <TBD> ==
+
[[Testing for Browser cache weakness (OTG-AUTHN-006)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]]
(ie. does the authentication mechanism block remote systems that try a brute force attack against a simple user/password form?
 
  
 +
[[Testing for Weak password policy (OTG-AUTHN-007)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]]
  
 +
[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]]
  
[[OWASP Testing Guide v2 Table of Contents]]
+
[[Testing for weak password change or reset functionalities (OTG-AUTHN-009)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]  
  
{{Template:Stub}}
+
[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]

Latest revision as of 13:32, 5 August 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project


4.5 Authentication Testing



Authentication (Greek: αυθεντικός = real or genuine, from 'authentes' = author ) is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the thing are true. Authenticating an object may mean confirming its provenance, whereas authenticating a person often consists of verifying her identity. Authentication depends upon one or more authentication factors.


In computer security, authentication is the process of attempting to verify the digital identity of the sender of a communication. A common example of such a process is the log on process. Testing the authentication schema means understanding how the authentication process works and using that information to circumvent the authentication mechanism.


4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

4.5.2 Testing for default credentials (OTG-AUTHN-002)

4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)

4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)

4.5.5 Test remember password functionality (OTG-AUTHN-005)

4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)

4.5.7 Testing for Weak password policy (OTG-AUTHN-007)

4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)

4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)

4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)