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"
m (proofreading) |
|||
| Line 1: | Line 1: | ||
| − | + | {{Template:OWASP Testing Guide v3}} | |
| − | |||
| − | {{Template:OWASP Testing Guide | ||
=== Authentication Testing === | === Authentication Testing === | ||
| Line 9: | Line 7: | ||
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. | 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. | ||
| − | [[Default or Guessable User Account | + | [[Testing for credentials transport|(new: G.Ingrosso - 80%) 4.5.1 Credentials transport over an encrypted channel]] |
| + | |||
| + | [[Testing for user enumeration|(new: M.Meucci - 70%) 4.5.2 Testing for user enumeration]] | ||
| + | |||
| + | [[Testing for Default or Guessable User Account|(to imp: K.Horvath - 95%) 4.5.3 Testing for Guessable (Dictionary) User Account]]<br> | ||
First we test if there are default user accounts or guessable username/password combinations (dictionary testing) | First we test if there are default user accounts or guessable username/password combinations (dictionary testing) | ||
| − | [[Brute Force | + | [[Testing for Brute Force|4.5.4 Brute Force Testing]]<br> |
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. | 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. | ||
| − | [[Bypassing Authentication Schema | + | [[Testing for Bypassing Authentication Schema|4.5.5 Testing for bypassing authentication schema]]<br> |
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. | 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. | ||
| − | [[ | + | [[Testing for Vulnerable Remember Password and Pwd Reset|4.5.6 Testing for vulnerable remember |
| − | + | password and pwd reset]]<br> | |
| − | |||
| − | |||
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). | 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). | ||
| − | [[Logout and Browser Cache Management | + | [[Testing for Logout and Browser Cache Management|4.5.7 Testing for Logout and Browser Cache Management Testing]] |
| − | + | Here we check that the logout and caching functions are properly implemented. | |
| + | [[Testing for Captcha|(new: P.Luptak - 100% ) 4.5.8 Testing for CAPTCHA]]<br> | ||
| + | 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. | ||
| − | + | [[Testing Multiple Factors Authentication| (new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication]]<br> | |
| + | 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]. | ||
Revision as of 21:57, 13 August 2008
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
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.
(new: G.Ingrosso - 80%) 4.5.1 Credentials transport over an encrypted channel
(new: M.Meucci - 70%) 4.5.2 Testing for user enumeration
(to imp: K.Horvath - 95%) 4.5.3 Testing for Guessable (Dictionary) User Account
First we test if there are default user accounts or guessable username/password combinations (dictionary testing)
4.5.4 Brute Force Testing
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.5.5 Testing for bypassing authentication schema
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.5.6 Testing for vulnerable remember
password and pwd reset
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.5.7 Testing for Logout and Browser Cache Management Testing Here we check that the logout and caching functions are properly implemented.
(new: P.Luptak - 100% ) 4.5.8 Testing for CAPTCHA
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.
(new: G.Fedon) 4.5.9 Testing Multiple Factors Authentication
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].
