Home > Articles

This chapter is from the book

This chapter is from the book


The Authentication section covers attacks that target a web site’s method of validating the identity of a user, service, or application. Authentication is performed using at least one of three mechanisms: "something you have," "something you know," or "something you are." This section will discuss the attacks used to circumvent or exploit the authentication process of a web site.

Brute Force

A Brute Force attack is an automated process of trial and error used to guess a person’s username, password, credit-card number, or cryptographic key.

Many systems will allow the use of weak passwords or cryptographic keys, and users will often choose easy-to-guess passwords, possibly found in a dictionary. Given this scenario, an attacker would cycle though the dictionary word by word, generating thousands or potentially millions of incorrect guesses searching for the valid password. When a guessed password allows access to the system, the Brute Force attack has been successful and the attacker is able access the account.

The same trial-and-error technique is also applicable to guessing encryption keys. When a web site uses a weak or small key size, it’s possible for an attacker to guess a correct key by testing all possible keys.

Essentially, there are two types of Brute Force attacks: normal Brute Force and reverse Brute Force. A normal Brute Force attack uses a single username against many passwords. A reverse Brute Force attack uses many usernames against one password. In systems with millions of user accounts, the odds of multiple users having the same password dramatically increase. While Brute Force techniques are highly popular and often successful, they can take hours, weeks, or years to complete.

Brute Force Example

    Username = Jon

    Passwords = smith, michael-jordan, [pet names], [birthdays], [car names],

    Usernames = Jon, Dan, Ed, Sara, Barbara, .....

    Password = 12345678

Apache Countermeasures for Brute Force Attacks

There are a few different approaches that we can take to mitigate the effectiveness of Brute Force attacks against authentication used by our Apache server. We need to break down the different factors that influence the effectiveness of a Brute Force attack.

Weak Passwords

The bane of most every multi-user system’s security is the fact that users will invariably choose weak passwords, as they are easier to remember. In order to help prevent a successful Brute Force attack, you must enforce a strong password policy. All passwords should have the following characteristics:

  • At least six characters in length.
  • Do not contain the username string.
  • Contain at least one numeric digit (0–9).
  • Contain at least one special character.
  • Forced to change every 90–120 days.
  • Forced not to repeat a previous password.

Unfortunately, Apache does not have a direct means to enforce this type of password complexity with its default password management tools: htpasswd and htdigest. In order to gain more robust password security capabilities, you should implement one of the many third-party authentication modules available for Apache at the Apache Module Registry site: http://modules.apache.org/search. A module such as Mod_SecurID (http://www.denyall.com/mod_securid/) can implement a strong two-factor authentication component to help thwart Brute Force attacks. With two-factor authentication, the user supplies something they know (such as a password or PIN) and then they utilize something they have (in this case, a hardware device that generates a new random number string every 60 seconds). In order to gain access to a two-factor authentication system, the attacker would need to have physical access to the RSA SecurID FOB hardware token.

Suppress Verbose Error Messages

When an invalid username/password combination is submitted, do not inform the user which piece of information (either the username or password) was invalid. This may lend an attacker the ability to determine which accounts on the system exist. We will discuss this concept further in Chapter 8 when we are securing the Buggy Bank application, as it has this same vulnerability. We can leverage the output filtering capabilities of Apache 2.0 to alter/remove this type of information from web pages that are generated by an authentication program.

Creating Authentication Failure Awareness

When Apache is being used as a reverse proxy front-end for an application that is authenticating users, it is difficult for Apache to be "aware" that an authentication failure has actually taken place. This is a result of the nature of the different authentication transactions. The easiest authentication mechanisms for Apache to recognize are when Basic or Digest Authentication is being utilized. With these two mechanisms, the client submits an additional Authorization client header containing their credentials. If the credentials are incorrect, a 401 Unauthorized status code is generated. If you configured Apache to utilize CGI script for this status code, then you can potentially be alerted when a client fails authentication. We will discuss the concepts and techniques of using custom 401 and 403 CGI error scripts to monitor and track failed requests in a later chapter.

When a form-based authentication mechanism is used, it becomes a bit trickier to identify login failures, as the HTTP response status code is no longer an indicator of the success or failure of the login attempt. As long as Apache is able to successfully serve the desired page, it will generate a 200 OK status code. The authentication failure information will therefore have to be identified by different means. Here are two possibilities:

  • Error message in html. As mentioned in the previous section on suppressing specific error messages, attackers will try and inspect the returned error messages, looking for any signs of information disclosure. You should work with your web developers to make sure that they update their error messages to contain benign information that will not be useful to the attacker. Although this information may not be leveraged by the attacker, it will be useful to Apache for identifying authentication failures. Let's say, for instance, that your authentication failure web page contains the following text: "Sorry, you did not supply the correct username or password." With this information, we can create a Mod_Security filter to identify this data in the output stream returned to the client. Here is an example filter:
  • <;Location /path/to/login>
    SecFilterSelective OUTPUT "you did not supply the correct username or password" status:401

    This new filter will identify the failure message being served to the client and trigger a 401 status code.

  • Failure URL. Similar to the technique mentioned previously, you could also create a Mod_Security filter that would trigger a 401 status code if the authentication program sends the client to a specific "failure" URL. Here is an example filter:
  • SecFilterSelective THE_REQUEST "/path/to/failure_webpage" status:401

Anti-Brute Force Code

Apache doesn’t natively have any capability to track failed login attempts for specific user accounts. The best way to track that, outside of updating the application’s code, is to use the 401 CGI scripts to send emails to security personnel. In this scenario, the recipient of the email will have to apply some analysis to identify Brute Force attacks against specific accounts. The best way to identify and react to an automated Brute Force attack against your site is to use Mod_Dosevasive. We touched on the high-level concepts of the module in Chapter 5, "Essential Security Modules for Apache;" however, now it is time to get into more detail and practical tips.

Mod_Dosevasive works equally well whether it is facing an application layer DoS attack or a brute force attack against one or more accounts. This is due to the similarity of request characteristics from the web server’s perspective when these two attacks are executed. They both have a mapping of a remote IP address connecting to a certain URL. In the case of a brute force attack, the URL just happens to have access controls implemented that require authentication. Mod_Dosevasive is not aware of this authentication, but is still effective in identifying this as an automated attack due to the velocity of requests received in the time interval observed.

When Mod_Dosevasive identifies an attack, it will deny (blackhole) the offending IP address for the time period specified in the DOSBlockingPeriod directive. This method has its uses; however, IP address restrictions must also be used with caution. Blocking a NATed proxy IP Address may prevent a large portion of legitimate user traffic as well. The main problem here is that only using the client IP address and URI as associations causes false positives. In order to better identify unique clients who may be connecting behind a proxy server, we can include the "User-Agent" information to the hash token. This creates a hash token of – Remote IP_User-Agent->URI. This extra variable will help us to avoid denying innocent clients. Here is a small snippet of the source code from before the update:

/* Has URI been hit too much? */
 snprintf(hash_key, 2048, "%s_%s", r->connection->remote_ip, r->uri);
 n = ntt_find(hit_list, hash_key);
 if (n != NULL) {

Here is the updated code:

/* Has URI been hit too much? */
 snprintf(hash_key, 2048, "
 %s_%s", apr_pstrcat(r->pool, r->connection->remote_ip, "_", 
apr_table_get(r->headers_in, "user-agent"), NULL), r->uri)
; n = ntt_find(hit_list, hash_key); if (n != NULL) {

While this concept does provide some level of protection from denying legitimate clients who happen to be behind a proxy, it does open up one more issue. What if an attacker were to update their DoS attack script to use rotating User-Agent fields? Sound too far fetched? Well, it isn’t. In Chapter 10, "Open Web Proxy Honeypot," I present concrete evidence of an attacker using this same strategy when using my Apache Open Proxy Honeypot. So, how do we combat this? I spoke with the Mod_Dosevasive creator, and the consensus was to implement code that will set a threshold on the total number of different User-Agent fields allowed per IP Address in the timeframe specified. This will catch attackers who are using rotating/spoofed User-Agent fields. By the time this book comes out, the updated code we have discussed here should be available either from the Mod_Dosevasive web site or from my personnel site: http://honeypots.sf.net.


Insufficient Authentication

Insufficient Authentication occurs when a web site permits an attacker to access sensitive content or functionality without having to properly authenticate. Web-based administration tools are a good example of web sites providing access to sensitive functionality. Depending on the specific online resource, these web applications should not be directly accessible without having the user required to properly verify their identity.

To get around setting up authentication, some resources are protected by "hiding" the specific location and not linking the location into the main web site or other public places. However, this approach is nothing more than "Security Through Obscurity." It’s important to understand that simply because a resource is unknown to an attacker, it still remains accessible directly through a specific URL. The specific URL could be discovered through a Brute Force probing for common file and directory locations (/admin, for example), error messages, referrer logs, or perhaps documented in help files. These resources, whether they are content or functionality driven, should be adequately protected.

Insufficient Authentication Example

Many web applications have been designed with administrative functionality location directory off the root directory (/admin/). This directory is usually never linked to anywhere on the web site, but can still be accessed using a standard web browser. Because the user or developer never expected anyone to view this page since it’s not linked, adding authentication is often overlooked. If an attacker were to simply visit this page, he would obtain complete administrative access to the web site.

Apache Countermeasures for Insufficient Authentication

Relying on "Security by Obscurity" is a recipe for disaster. I much prefer "Security with Obscurity." This means that it is a reasonable step to not publicly link to these administration functions of your web site; however, this should not be the only means of security that you apply. As discussed in Chapter 4, "Configuring the httpd.conf File," we can implement both host-based and user-based access control to these URLs. Using the (/admin/) directory from the example, we can implement appropriate access control with the following directives in the httpd.conf file:

<LocationMatch "^/admin/">
AuthType Digest
AuthName "Admin Area"
AuthDigestfile /usr/local/apache/conf/passwd_digest
Require user admin


This directive container for the "/admin/" location will force the following:

  • The connection must be over SSL.
  • Uses Digest Authentication.
  • The username "admin" and the correct password must be supplied.

Weak Password Recovery Validation

Weak Password Recovery Validation is when a web site permits an attacker to illegally obtain, change, or recover another user’s password. Conventional web site authentication methods require users to select and remember a password or passphrase. The user should be the only person who knows the password, and it must be remembered precisely. As time passes, a user’s ability to remember a password fades. The matter is further complicated when the average user visits 20 sites requiring them to supply a password (RSA Survey: http://news.bbc.co.uk/1/hi/technology/3639679.stm). Thus, Password Recovery is an important part in servicing online users.

Examples of automated password recovery processes include requiring the user to answer a "secret question" defined as part of the user registration process. This question can either be selected from a list of canned questions or supplied by the user. Another mechanism in use is having the user provide a "hint" during registration that will help the user remember his password. Other mechanisms require the user to provide several pieces of personal data such as his social security number, home address, zip code, and so on. to validate their identity. After the user has proven who they are, the recovery system will display or email them a new password.

A web site is considered to have Weak Password Recovery Validation when an attacker is able to foil the recovery mechanism being used. This happens when the information required to validate a user’s identity for recovery is either easily guessed or can be circumvented. Password recovery systems may be compromised through the use of Brute Force attacks, inherent system weaknesses, or easily guessed secret questions.

Weak Password Recovery Validation Examples

Information Verification

Many web sites only require the user to provide their email address in combination with their home address and telephone number. This information can be easily obtained from any number of online white pages. As a result, the verification information is not very secret. Further, the information can be compromised via other methods such as cross-site scripting and phishing scams.

Password Hints

A web site using hints to help remind the user of their password can be attacked because the hint aids Brute Force attacks. A user may have fairly good password of "122277King" with a corresponding password hint of "bday+fav author". An attacker can glean from this hint that the user’s password is a combination of the user’s birthday and the user’s favorite author. This helps narrow the dictionary Brute Force attack against the password significantly.

Secret Question and Answer

A user’s password could be "Richmond" with a secret question of "Where were you born." An attacker could then limit a secret answer Brute Force attack to city names. Furthermore, if the attacker knows a little about the target user, learning their birthplace is also an easy task.

Apache Countermeasures for Weak Password Recovery Validation

Solving Weak Password Recovery is not as simple as it would seem. Apache has a tough time handling this type of issue as it is more related to the application logic rather than HTTP transactions. Even though Apache would have a difficult time with this, it is still capable of detecting certain brute force attack characteristics associated with circumventing the secret question and answer restrictions listed in the following sections.

Secret Question and Answer

Some web sites have limited access to a user’s personal data for verification. These sites should implement a set of recovery functions at registration, such as having the user correctly answer several secret questions. The secret questions themselves should be subjective in nature. Having a relatively large list of potential questions increases the protection against Brute Force attack and lucky guessing. Choosing good questions is difficult, but is probably the most important part of the system described previously. It is possible to generate questions that should apply to nearly everyone. For example:

  • First company I worked for and the position I held.
  • First car I owned (make and model).
  • My favorite college professor.
  • First city I flew to.

It is also possible for users to generate questions or prompts personally tailored, although this procedure can add complexity to the system as it must now remember both the question and the corresponding answer. Further, users may find it hard to come up with several personal unique questions to ask themselves. Taking this difficulty aside, having the option for custom questions enhances the security of the system by further impeding the attacker.

If an attacker were to launch a Brute Force attack against this type of interface, Apache could be configured as described in the previous Brute Force section, which triggered on specific text in the returned html page and/or the client being sent to a certain URL upon failure. In these cases, an administrator should be altered to this activity.


InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020