Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

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

Brief Summary

The scope of this test is to verify if is possible to collect a set of valid users interacting with the authentication mechanism of the application. This test will be usefull for the brute force testing in which we verify if given a valid username it is possible to find a valid password.

Description of the Issue

The tester should interact with the authentication mechanism of the application to understand if sending particular request the application answer in a different manner.

Black Box testing and example

Testing for Valid user/right password
Record the server answer when you submit valid username and valid password.
Result Expected:
Using WebScarab notice the information retrieved from this successful authentication (HTTP 200 Response, lenght response).

Testing for Valid user/wrong password
Now, the tester should try to insert a valid username and a wrong password and record the error message server answer.
Testing for wrong user/wrong password
Now, the tester should try to insert a not valid username and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

Result Expected:
The application should response with the same error message and lenght to the different wrong requests. If you notice that the answer are not the same, you should investigate and find out the key that create a difference between the 2 requests. For example:

• Client request: Valid user/wrong password --> Server answer:'The password is not correct'
• Client request: Wrong user/wrong password --> Server answer:'User not regnognized'

The above answers let the client to understand that for the first request we hold a valid user name. So we can interact with the application requesting a set of possible username and observing the answer.
Looking at the second server answer, we understand in the same way that we don't hold a valid user name. So we can interact in the same manner and create a list of valid username looking at the server answers.

Gray Box testing and example

Testing for Authentication error messages
Verify that the application answer in the same manner for every client request of authentication that produce a fail authentication
Result Expected:
The application should anwser in the same manner for every failed attempt of authentication.
For Example:
'Credentials submitted are not valid'

References

Whitepapers
...
Tools
...