Track the source IP address of authentication attempts for an account. The specific IP address of a user can change due to proxies, time of day, travel, or other legitimate reasons. However, the IP address used to access the login page for an account should remain static during the brief login process and is very unlikely to hop geographic regions during failure attempts.
This method correlates login attempts for an account with the source IP of the request. If an IP address is hopping between class B addresses during a short period of time (a minute, for example), that behavior is a strong indicator of a brute force attack.
In addition, if successful authentication attempts occur contemporaneously or within a small timeframe of each other and have widely varied source IP addresses, then that may indicate a compromised account. It isn't likely that a user in California logs into an account at 10 a.m. PST followed by another login at 1 p.m. PST from Brazil. Organizations such as banks and credit-card companies use sophisticated fraud detection schemes that look for anomalous behavior. The same concept can be applied to login forms based on variables such as time of day, IP address block, geographic region of the IP address, or even details such as the browser's User-Agent header.
Outliers from normal expected behavior do not always indicate fraud, but they can produce ever-increasing levels of alert until passing a threshold where the application locks the account due to suspicious activity.
When users transition from anonymous to authenticated, it is good practice to regenerate the session ID. This blocks session fixation attacks. It may also help mitigate the impact of XSS vulnerabilities present on the unauthenticated portion of a Web site, though be warned there are many caveats to this claim so don't assume it is a universal protection from XSS.
One strategy for improving authentication is to move beyond password-based authentication into multifactor authentication. Passwords represent a static shared secret between the Web site and the user. The Web sites confirm the user's identity if the password entered in the login page matches the password stored by the site. Anyone presenting the password is assumed to be the user, which is why password stealing attacks such as network sniffing and XSS are useful to an attacker.
Alternate authentication schemes improve on passwords by adding additional factors required to identify the user. A one-time password scheme relies on a static password and a device (hardware or software) that generates a random password on a periodic basis, such as producing a nine-digit password every minute. For an attacker to compromise this scheme, it would be necessary to obtain not only the victim's static password but also the device used to generate the one-time password. So, while a phishing attack might trick the victim into divulging the static password, it isn't possible to steal a physical device that generates the one-time password.
One-time passwords also mitigate sniffing attacks by protecting the confidentiality of the user's static password. Only the one-time password generated by the combination of static password and generating device is sent to the Web server. An attacker may compromise the temporary password, but the time window during which it is valid is very brief – typically only a few minutes. A sniffing attack may still compromise the user's session cookie or other information, but the password is protected.
Web sites may choose to send one-time passwords out-of-band. Upon starting the login process, the user may request the site to send a text message containing a random password. The user must then use this password within a number of minutes to authenticate. Whether the site provides a token generator or sends text messages, the scheme is predicated on the idea that the user knows something (a static password) and possesses something (the token generator or a phone). The security of multifactor authentication increases because the attacker must compromise knowledge, which is relatively easy as proven by phishing and sniffing attacks, and a physical object, which is harder to accomplish on a large scale. (Alternately, the attacker may try to reverse engineer the token generation system. If the one-time passwords are predictable or reproducible, then there's no incremental benefit of this system.)
Convincing users to keep their passwords secure is a difficult challenge. Even security-conscious users may fall victim to well-designed phishing attacks. Also, many attacks occur outside the purview of the targeted Web application that makes it near impossible for the application to apply technical countermeasures against phishing attacks.
Web sites can rely on two measures to help raise users' awareness of the dangers of phishing attacks. One step is to clearly state that neither the Web site's support staff nor the administrators will ever ask a user to divulge a password. Online gaming sites such as Blizzard's World of Warcraft repeatedly make these statements in user forums, patch notes, and the main Web site. Continuously repeating this message helps train users to become more suspicious of messages claiming to require a username and password to reset an account, update an account, or verify an account's authenticity.
Web sites are also helped by browser vendors. Developers of Web browsers exert great efforts to make the Web experience more secure for all users. One step taken by browsers is to make more explicit the domain name associated with a URI. Web sites should always encourage visitors to use the latest version of their favorite Web browser. Figure 5.2 shows the navigation bar's background change in intensity (on color displays the background switches from white to green) that signifies the SSL certificate presented by the Web site matches the domain name. The domain name, ebay.com, stands out from the rest of the URI.
All the latest versions of the popular browsers support these Extended Validation (EV) SSL certificates and provide visual feedback to the user. EV SSL certificates do not guarantee the security of a Web site. A site with an XSS or SQL injection vulnerability can be exploited just as easily whether an EV SSL certificate is present or not. What these certificates and coloring of navigation bars are intended to provide is better feedback that indeed the Web site being visited belongs to the expected Web site and is not a spoofed page attempting to extract sensitive information from unwitting visitors.
We will cover more details about securing the Web browser in Chapter 7, “Web of Distrust.”
As users of Web application, we can also take measures to protect passwords and minimize the impact when a site doesn't protect passwords as it should. The most important rule is never divulge a password. Site administrators or support personnel will not ask for it. Use different credentials for different sites. You may use some Web applications casually and some for maintaining financial or health information. It's hard to avoid reusing passwords between sites because you have to remember which password corresponds to which site. At least, choose a password for your e-mail account that is different from other sites, especially if the site uses your e-mail address for usernames. A compromise of your password would easily lead an attacker to your e-mail account. This is particularly dangerous if you remember how many sites use password recovery mechanisms based on e-mail.
alt1 Note
If a Web site's password recovery mechanism e-mails you the plaintext version of your original password, then stop using the site. Sending the original password in plaintext most likely means that the site stores passwords without encryption, a glaring security violation that predates the Internet. E-mail is not sent over encrypted channels. Losing a temporary password to a sniffing or other attack carries much less risk than having the actual password compromised, especially if the password is used on multiple Web sites.
Web sites that offer customized experiences, social networking sites, e-commerce, and so on need the ability to uniquely identify each visitor. They do this by making a simple challenge to the visitor: prove who you say you are. This verification of identity is most often done by asking the user for a password.
Regardless of how securely the Web site is written or the configuration of its ancillary components such as firewalls, the traffic from an attacker with a victim's username and password looks no different form that of a legitimate user because there are no malicious payloads such as those found in fault injection attacks. The attacker performs authorized functions because the application only identifies its users based on login credentials.
The techniques for breaking authentication schemes vary widely based on vulnerabilities present in the application and the creativity of the attacker. The following list describes a few of the techniques. Their common theme is gaining unauthorized access to someone else's account.
Web sites must use different types of countermeasures to cover all aspects of authentication. Passwords must be confidential when stored (for example, hashed in a database) and confidential when transmitted (for example, sent via HTTPS). Session cookies and other values used to uniquely identify visitors must have similar protections from compromise. Otherwise, an attacker can skip the login process by impersonating the victim with a stolen cookie.
Authentication schemes require many countermeasures significantly different from problems such as SQL injection or XSS. The latter vulnerabilities rely on injecting malicious characters into a parameter or using character-encoding tricks to bypass validation filters. The defenses for those attacks rely heavily on verifying syntax of user-supplied data and preserving the grammar of a command by preventing data from being executed as code. Authentication attacks tend to target processes, such as the login page, or protocol misuse, such as sending passwords, over HTTP instead of HTTPS. By understanding how these attacks work, the site's developers can apply defenses that secure a site's logic and state mechanisms.