[OWASP-TESTING] Testing Guide II - Authentication

Irene Abezgauz irene.abezgauz at gmail.com
Sat Aug 13 05:56:30 EDT 2005

Hey all,
Following is the Default User Accounts and Blank Passwords section.
I will be releasing the rest once I'm done finalizing and touch-uping.
The tools section is empty in this one, and will probably be empty on
most of the other sections because I am a big fan of testing things
manually, so I'm not too familiar with most of the tools of this sort.
Feel free to send me names of tools I could add.
p.s - If you rather wait for the whole thing together – just let me
1         Default or Guessable User Accounts and Empty Passwords
1.1      Causes
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.
1.2      Blackbox Testing

1.2.1      Manual

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 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.
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:
*        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
*        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.

1.2.2      Suggested Tools

1.3      Whitebox Testing
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
*        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.
1.4      Further Reading
*        HYPERLINK
*        HYPERLINK
*        HYPERLINK
*        HYPERLINK

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 8/12/2005

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 8/12/2005
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/owasp-testing/attachments/20050813/8237988b/attachment.html 

More information about the Owasp-testing mailing list