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

Testing for authentication

From OWASP
Revision as of 11:29, 7 December 2008 by KirstenS (talk | contribs)

Jump to: navigation, search

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here


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 logon process. Testing the authentication schema means understanding how the authentication process works and using that information to circumvent the authentication mechanism.

4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)
Here, the tester will just try to understand if the data that users put into the web form, in order to log into a web site, are transmitted using secure protocols that protect them from an attacker or not.

4.4.2 Testing for user enumeration (OWASP-AT-002)
The scope of this test is to verify if it is possible to collect a set of valid users by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.

4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)
Here we test if there are default user accounts or guessable username/password combinations (dictionary testing)

4.4.4 Brute Force Testing (OWASP-AT-004)
When a dictionary type attack fails, a tester can attempt to use brute force methods to gain authentication. Brute force testing is not easy to accomplish for testers because of the time required and the possible lockout of the tester.

4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)
Other passive testing methods attempt to bypass the authentication schema by recognizing that not all of the application's resources are adequately protected. The tester can access these resources without authentication.

4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)
Here we test how the application manages the process of "password forgotten". We also check whether the application allows the user to store the password in the browser ("remember password" function).

4.4.7 Testing for Logout and Browser Cache Management Testing (OWASP-AT-007)
Here we check that the logout and caching functions are properly implemented.

4.4.8 Testing for CAPTCHA (OWASP-AT-008)
CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer. CAPTCHA implementations are often vulnerable to various kinds of attacks even if the generated CAPTCHA is unbreakable. This section will help you to identify these kinds of attacks.

4.4.9 Testing Multiple Factors Authentication (OWASP-AT-001)
Multiple Factors Authentication means to test the following scenarios: One-time password (OTP) generator tokens, Crypto devices like USB tokens or smart cards, equipped with X.509 certificates, Random OTP sent via SMS, Personal information that only the legitimate user is supposed to know [OUTOFWALLET].

4.4.10 Testing for Race Conditions (OWASP-AT-010)
A race condition is a flaw that produces an unexpected result when timing of actions impact other actions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.