4.0 Authentication Testing
4.1 Testing for Credentials Transported over an Encrypted Channel
merged into: Testing for Sensitive Information Sent via Unencrypted Channels
4.2 Testing for Default Credentials
Testing for Vendor Default Credentials
Searching for “[SOFTWARE] default password”.
Reviewing the manual or vendor documentation.
Checking common default password databases, such as CIRT.net, SecLists Default Passwords or DefaultCreds-cheat-sheet.
Inspecting the application source code (if available).
Installing the application on a virtual machine and inspecting it.
Inspecting the physical hardware for stickers (often present on network devices).
If a default password can’t be found, try common options such as:
“admin”, “password”, “12345”, or other common default passwords.
An empty or blank password.
The serial number or MAC address of the device.
Testing for Organisation Default Passwords
A single common password such as “Password1”.
Organisation specific details, such as the organisation name or address.
Passwords that follow a simple pattern, such as “Monday123” if account is created on a Monday.
Testing for Application Generated Default Passwords
A single static string shared between accounts.
A hashed or obfuscated part of the account details, such as
md5($username).A time-based algorithm.
A weak pseudo-random number generator (PRNG).
4.3 Testing for Weak Lock Out Mechanism
Lockout Mechanism
Attempt to log in with an incorrect password 3 times.
Successfully log in with the correct password, thereby showing that the lockout mechanism doesn’t trigger after 3 incorrect authentication attempts.
Attempt to log in with an incorrect password 4 times.
Successfully log in with the correct password, thereby showing that the lockout mechanism doesn’t trigger after 4 incorrect authentication attempts.
Attempt to log in with an incorrect password 5 times.
Attempt to log in with the correct password. The application returns “Your account is locked out.”, thereby confirming that the account is locked out after 5 incorrect authentication attempts.
Attempt to log in with the correct password 5 minutes later. The application returns “Your account is locked out.”, thereby showing that the lockout mechanism does not automatically unlock after 5 minutes.
Attempt to log in with the correct password 10 minutes later. The application returns “Your account is locked out.”, thereby showing that the lockout mechanism does not automatically unlock after 10 minutes.
Successfully log in with the correct password 15 minutes later, thereby showing that the lockout mechanism automatically unlocks after a 10 to 15 minute period.
Testing CAPTCHA
A CAPTCHA may hinder brute force attacks, but they can come with their own set of weaknesses and should not replace a lockout mechanism. A CAPTCHA mechanism may be bypassed if implemented incorrectly. CAPTCHA flaws include:
Easily defeated challenge, such as arithimetic or limited question set.
CAPTCHA checks for HTTP response code instead of response success.
CAPTCHA server-side logic defaults to a successful solve.
CAPTCHA challenge result is never validated server-side.
CAPTCHA input field or parameter is manually processed, and is improperly validated or escaped.
To evaluate CAPTCHA effectiveness:
Assess CAPTCHA challenges and attempt automating solutions depending on difficulty.
Attempt to submit request without solving CAPTCHA via the normal UI mechanism(s).
Attempt to submit request with intentional CAPTCHA challenge failure.
Attempt to submit request without solving CAPTCHA (assuming some default values may be passed by client-side code, etc) while using a testing proxy (request submitted directly server-side).
Attempt to fuzz CAPTCHA data entry points (if present) with common injection payloads or special characters sequences.
Check if the solution to the CAPTCHA might be the alt-text of the image(s), filename(s), or a value in an associated hidden field.
Attempt to re-submit previously identified known good responses.
Check if clearing cookies causes the CAPTCHA to be bypassed (for example if the CAPTCHA is only shown after a number of failures).
If the CAPTCHA is part of a multi-step process, attempt to simply access or complete a step beyond the CAPTCHA (for example if CAPTCHA is the first step in a login process, try simply submitting the second step [username and password]).
Check for alternative methods that might not have CAPTCHA enforced, such as an API endpoint meant to facilitate mobile app access.
Unlock Mechanism
To evaluate the unlock mechanism’s resistance to unauthorized account unlocking, initiate the unlock mechanism and look for weaknesses. Typical unlock mechanisms may involve secret questions or an emailed unlock link. The unlock link should be a unique one-time link, to stop an attacker from guessing or replaying the link and performing brute force attacks in batches.
4.4 Testing for Bypassing Authentication Schema
Direct page request (forced browsing)
Parameter modification
Session ID prediction
SQL injection
4.5 Testing for Vulnerable Remember Password
Store the credentials in an encoded fashion in the browser’s storage mechanisms, which can be verified by following the web storage testing scenario and going through the session analysis scenarios. Credentials shouldn’t be stored in any way in the client-side application, and should be substitued by tokens generated server-side.
Automatically inject the user’s credentials that can be abused by:
ClickJacking attacks.
CSRF attacks.
Tokens should be analyzed in terms of token-lifetime, where some tokens never expire and put the users in danger if those tokens ever get stolen. Make sure to follow the session timeout testing scenario.
4.6 Testing for Browser Cache Weaknesses
The first and simplest test consists of entering sensitive information into the application and logging out. Then the tester clicks the Back button of the browser to check whether previously displayed sensitive information can be accessed whilst unauthenticated.
4.7 Testing for Weak Password Policy
What characters are permitted and forbidden for use within a password? Is the user required to use characters from different character sets such as lower and uppercase letters, digits and special symbols?
How often can a user change their password? How quickly can a user change their password after a previous change? Users may bypass password history requirements by changing their password 5 times in a row so that after the last password change they have configured their initial password again.
How often can a user reuse a password? Does the application maintain a history of the user’s previous used 8 passwords?
How different must the next password be from the last password?
Is the user prevented from using his username or other account information (such as first or last name) in the password?
What are the minimum and maximum password lengths that can be set, and are they appropriate for the sensitivity of the account and application?
Is it possible set common passwords such as
Password1or123456?
4.8 Testing for Weak Security Question Answer
Testing for Weak Pre-generated Questions
Try to obtain a list of security questions by creating a new account or by following the “I don’t remember my password”-process. Try to generate as many questions as possible to get a good idea of the type of security questions that are asked. If any of the security questions fall in the categories described above, they are vulnerable to being attacked (guessed, brute-forced, available on social media, etc.).
Testing for Weak Self-Generated Questions
Try to create security questions by creating a new account or by configuring your existing account’s password recovery properties. If the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. If the system uses the self-generated security questions during the forgotten password functionality and if usernames can be enumerated (see Testing for Account Enumeration and Guessable User Account, then it should be easy for the tester to enumerate a number of self-generated questions. It should be expected to find several weak self-generated questions using this method.
Testing for Brute-forcible Answers
Use the methods described in Testing for Weak lock out mechanism to determine if a number of incorrectly supplied security answers trigger a lockout mechanism.
The first thing to take into consideration when trying to exploit security questions is the number of questions that need to be answered. The majority of applications only need the user to answer a single question, whereas some critical applications may require the user to answer two or even more questions.
The next step is to assess the strength of the security questions. Could the answers be obtained by a simple Google search or with social engineering attack? As a penetration tester, here is a step-by-step walkthrough of exploiting a security question scheme:
Does the application allow the end user to choose the question that needs to be answered? If so, focus on questions which have:
A “public” answer; for example, something that could be find with a simple search-engine query.
A factual answer such as a “first school” or other facts which can be looked up.
Few possible answers, such as “what model was your first car”. These questions would present the attacker with a short list of possible answers, and based on statistics the attacker could rank answers from most to least likely.
Determine how many guesses you have if possible.
Does the password reset allow unlimited attempts?
Is there a lockout period after X incorrect answers? Keep in mind that a lockout system can be a security problem in itself, as it can be exploited by an attacker to launch a Denial of Service against legitimate users.
Pick the appropriate question based on analysis from the above points, and do research to determine the most likely answers.
The key to successfully exploiting and bypassing a weak security question scheme is to find a question or set of questions which give the possibility of easily finding the answers. Always look for questions which can give you the greatest statistical chance of guessing the correct answer, if you are completely unsure of any of the answers. In the end, a security question scheme is only as strong as the weakest question.
4.9 Testing for Weak Password Change or Reset Functionalities
Test Password Reset
What information is required to reset the password?
The first step is to check whether secret questions are required. Sending the password (or a password reset link) to the user email address without first asking for a secret question means relying 100% on the security of that email address, which is not suitable if the application needs a high level of security.
On the other hand, if secret questions are used, the next step is to assess their strength. This specific test is discussed in detail in the Testing for Weak security question/answer paragraph of this guide.
How are reset passwords communicated to the user?
The most insecure scenario here is if the password reset tool shows you the password; this gives the attacker the ability to log into the account, and unless the application provides information about the last log in the victim would not know that their account has been compromised.
A less insecure scenario is if the password reset tool forces the user to immediately change their password. While not as stealthy as the first case, it allows the attacker to gain access and locks the real user out.
The best security is achieved if the password reset is done via an email to the address the user initially registered with, or some other email address; this forces the attacker to not only guess at which email account the password reset was sent to (unless the application show this information) but also to compromise that email account in order to obtain the temporary password or the password reset link.
Are reset passwords generated randomly?
The most insecure scenario here is if the application sends or visualizes the old password in clear text because this means that passwords are not stored in a hashed form, which is a security issue in itself.
The best security is achieved if passwords are randomly generated with a secure algorithm that cannot be derived.
Is the reset password functionality requesting confirmation before changing the password?
To limit denial-of-service attacks the application should email a link to the user with a random token, and only if the user visits the link then the reset procedure is completed. This ensures that the current password will still be valid until the reset has been confirmed.
Test Password Change
Is the old password requested to complete the change? The most insecure scenario here is if the application permits the change of the password without requesting the current password. Indeed if an attacker is able to take control of a valid session they could easily change the victim’s password. See also Testing for Weak password policy paragraph of this guide.
4.10 Testing for Weaker Authentication in Alternative Channel
Understand the Primary Mechanism
Fully test the website’s primary authentication functions. This should identify how accounts are issued, created or changed and how passwords are recovered, reset, or changed. Additionally knowledge of any elevated privilege authentication and authentication protection measures should be known. These precursors are necessary to be able to compare with any alternative channels.
Identify Other Channels
Other channels can be found by using the following methods:
Reading site content, especially the home page, contact us, help pages, support articles and FAQs, T&Cs, privacy notices, the robots.txt file and any sitemap.xml files.
Searching HTTP proxy logs, recorded during previous information gathering and testing, for strings such as “mobile”, “android”, blackberry”, “ipad”, “iphone”, “mobile app”, “e-reader”, “wireless”, “auth”, “sso”, “single sign on” in URL paths and body content.
Use search engines to find different websites from the same organization, or using the same domain name, that have similar home page content or which also have authentication mechanisms.
For each possible channel confirm whether user accounts are shared across these, or provide access to the same or similar functionality.
Enumerate Authentication Functionality
For each alternative channel where user accounts or functionality are shared, identify if all the authentication functions of the primary channel are available, and if anything extra exists. It may be useful to create a grid like the one below:
Primary Mobile Call Center Partner Website Register
Yes
-
-
Log in
Yes
Yes
Yes(SSO)
Log out
-
-
-
Password reset
Yes
Yes
-
-
Change password
-
-
In this example, mobile has an extra function “change password” but does not offer “log out”. A limited number of tasks are also possible by phoning the call center. Call centers can be interesting, because their identity confirmation checks might be weaker than the website’s, allowing this channel to be used to aid an attack against a user’s account.
While enumerating these it is worth taking note of how session management is undertaken, in case there is overlap across any channels (e.g. cookies scoped to the same parent domain name, concurrent sessions allowed across channels, but not on the same channel).
Review and Test
Alternative channels should be mentioned in the testing report, even if they are marked as “information only” or “out of scope”. In some cases the test scope might include the alternative channel (e.g. because it is just another path on the target host name), or may be added to the scope after discussion with the owners of all the channels. If testing is permitted and authorized, all the other authentication tests in this guide should then be performed, and compared against the primary channel.
Last updated