Public Web servers often support a range of technologies for identifying and authenticating users with differing privileges for accessing information. Some of these technologies are based on cryptographic functions that can provide an encrypted channel between a Web browser client and a Web server that supports encryption.
Without user authentication, organizations will not be able to restrict access to specific information to authorized users. All information that resides on a public Web server will then be accessible by anyone with access to the server. In addition, without some process to authenticate the server, users will not be able to determine if the server is the “authentic” Web server or a counterfeit version operated by a malicious entity.
Encryption can be used to protect information traversing the connection between a Web browser client and a public Web server. Without encryption, anyone with access to the network traffic can determine, and possibly alter, the content of sensitive information, even if the user accessing the information has been authenticated carefully. This may violate the confidentiality and integrity of critical information.
Determining Authentication and Encryption Requirements
Organizations should periodically examine all information accessible on the public Web server and determine the necessary security requirements. While doing so, the organization should identify information that shares the same security and protection requirements. For sensitive information, the organization should determine the users or user groups that should have access to each set of resources.
For information that requires some level of user authentication, the organization should determine which of the following technologies or methods would provide the appropriate level of authentication and encryption. Each has its own unique benefits and costs that should be weighed carefully with client and organizational requirements and policies. It may be desirable to use some authentication methods in combination.
Below are the authentication mechanisms most commonly associated with public Web servers and Web applications.
Address-Based Authentication
The simplest authentication mechanism that is supported by most Web servers is address-based authentication. Access control is based on the IP address and/or hostname of the host requesting information. Although it is easy to implement for small groups of users, address authentication can be unwieldy for Web sites that have a large potential user population (i.e., most public Web servers). It is susceptible to several types of attacks, including IP spoofing and DNS poisoning. This type of authentication should be used only where minimal security is required, unless it is used in conjunction with stronger authentication methods.
Basic Authentication
The basic authentication technology uses the Web server content’s directory structure. Typically, all files in the same directory are configured with the same access privileges. A requesting user provides a recognized user identification and password for access to files in a given directory. More restrictive access control can be enforced at the level of a single file within a directory if the Web server software provides this capability. Each vendor’s Web server software has its own method and syntax for defining and using this basic authentication mechanism.
From a security perspective, the main drawback of this technology is that all password information is transferred in an encoded, rather than an encrypted, form. Anyone who knows the standardized encoding scheme can decode the password after capturing it with a network sniffer. Furthermore, any Web content is transmitted as unencrypted plaintext, so this content also can be captured, violating confidentiality. These limitations can be overcome using basic authentication in conjunction with SSL/TLS.
Basic authentication is supported by standard-compliant Web browsers.
Basic authentication is useful for protecting information from malicious bots because the bots should not have the necessary credentials to access the protected directories. However, this mechanism should not be considered secure against more determined and sophisticated attackers.
Digest Authentication
Because of the drawbacks with basic authentication, an improved technique known as digest authentication was introduced in version 1.1 of the HTTP protocol.
Digest authentication uses a challenge-response mechanism for user authentication. With this approach, a nonce or arbitrary value is sent to the user, who is prompted for an ID and password, as with basic authentication. However, in this case, the information entered by the user is concatenated and a cryptographic hash of the result is formed. This hash is concatenated with the nonce and a hash of the requested method and URL, and the result is then rehashed as a response value that is sent to the server. Because the user’s password is not sent in the clear, it cannot be directly sniffed from the network. The user’s password is not needed by the server to authenticate the user—only the hashed value of the user ID and password. Because the nonce can serve as an indicator of timeliness (e.g., it can be composed of date and time information), replay attacks are also thwarted. Unfortunately, all other information is sent in the clear and is vulnerable to interception and alteration. Digest authentication is also susceptible to offline dictionary attacks, where the attacker tries various passwords in an attempt to recreate the captured digest value. These limitations can be overcome using digest authentication in conjunction with SSL/TLS.
Like basic authentication, digest authentication is useful for protecting information from malicious bots.
Brute Force Attacks
Many Web sites authenticate users via username and password combinations—whether through HTTP Basic, HTTP Digest, or a Web form over SSL. Regardless of implementation, username and password combinations are susceptible to brute force attacks. Brute force attacks can occur in multiple forms:
- Username Harvesting - Applications that differentiate between an invalid password and an invalid username can allow attackers to construct a list of valid user accounts.
- Dictionary Attacks — Attackers use common dictionary words and their variants to attempt to gain access to a user’s account.
- Brute Force Attacks — Attackers try every possible password to attempt to gain access to a user’s account. There are a number of methods for reducing a Web server’s vulnerability to brute force attack:
- Use Strong Authentication — Strong authentication techniques, such as hardware tokens, one-time passwords, biometric authentication, and SSL/TLS client certificates, are much more resistant to brute force attacks than passwords. Stronger authentication can be achieved by combining multiple authentication mechanisms to form a multi-factor authentication scheme. However, strong authentication may be prohibitively expensive or difficult to incorporate into a system.
- Use Timeouts — Incurring a delay of several seconds after a failed login attempt can slow an attacker down. However, attackers can attempt multiple logins at the same time from different clients.
- Use Lockouts - Locking out a user account after a number of failed login attempts prevents the attacker from successfully logging into an account. The primary disadvantage of this technique is that it can leave the system open to a DoS attack. Also, an attacker may try several common passwords against random usernames, which may grant the attacker access to the system while bypassing the lockout.
- Enforce a Password Policy — By requiring passwords to be of a certain length and to contain lowercase letters, uppercase letters, numerals, and/or symbols, a simple dictionary attack will not work on the system.
- Enforce a Password Change Policy By requiring passwords to be changed on a regular basis, an attacker might not have enough time to brute-force a potential password. However, strict password change policies can frustrate users and weaken passwords by causing users to follow patterns, such as using password1, password2, etc.
- Use Blacklists — Blocking IP addresses or domains known to attempt brute force attacks from accessing the system may stop some attackers, but it is possible that some attacks may come from compromised systems that would otherwise be considered legitimate.
- Use Log Monitoring Software — Vigilantly monitoring logs of invalid password attempts may help an organization detect brute force attacks, potentially giving the organization time to respond before the attack has been successful.
Aside from strong authentication, none of these mechanisms completely prevent brute force attacks; however, using one or more of these techniques makes it more difficult for an attacker to gain access to the system. Nevertheless, when considering which technologies to adopt, it is important to consider passwords as part of the system as a whole. For example, a Web site that uses usernames and passwords only to retrieve user customizations may not need to concern itself with preventing brute force attacks.
In systems where sensitive information is being protected, some of these techniques may be necessary. Regardless, an organization may already have policies regarding brute force attacks. If so, those policies should be followed and enhanced if necessary.
Learn more