Authentication plays a critical role in the security of web applications. When a user provides his login name and password to authenticate and prove his identity, the application assigns the user specific privileges to the system, based on the identity established by the supplied credentials.

HTTP can embed several different types of authentication protocols. These include:

Basic - Cleartext username/password, Base-64 encode (trivially decoded)
Digest - Like Basic, but passwords are scrambled
Form-based - A custom form is used to input username/password (or other credentials) and is processed using custom logic on the backend.
NTLM - Microsoft’s proprietary authentication protocol, implemented within HTTP request/response headers.
Negotiate - A new protocol from Microsoft that allows any type of authentication specified above to be dynamically agreed upon by the client and server. Also adds Kerberos for clients using Microsoft’s IE v5+.
Client-side Certificates - Although rarely used, SSL/TLS provides an option that checks the authenticity of a digital certificate present by the Web client, essentially making it an authentication token.
Microsoft Passport - A single-sign-in (SSI) service run by Microsoft Corporation that allows web sites (called “Passport Partners”) to authenticate users based on their membership in the Passport service. The mechanism uses a key shared between Microsoft and the Partner site to create a cookie that uniquely identifies the user.

These authentication protocols operate right over HTTP (or SSL/TSL), with credentials embedded right in the request/response traffic.

What an attacker can do if your site is vulnerable
When the attacker breaks into the system by proving to the application that he is a known and valid user, the attacker gains access to whatever privileges the administrator assigned that user.

This means that if the attacker manages to enter as a normal user, he might have limited access to only view some important information. On the other hand, if he manages to enter as an administrative user with global access on the system, he would have almost total control on the application together with its content (with the limitations of the web application in itself).

Here are some common Username/Passwords used by attackers in authentication guessing attacks:

Username Guesses	Password Guesses
[NULL]	[NULL]
root, administrator, admin	[NULL], root, administrator, admin, password, [company_name]
operator, webmaster, backup	[NULL], operator, webmaster, backup
guest, demo, test, trial	[NULL], guest, demo, test, trial
member, private	member, private
[company_name]	NULL], [company_name], password
[known_username]	[NULL], [known_username]

If password guessing achieves no result, the next step for an attacker is to try other password combinations using special custom tools, like WebCracker and Brutus, which are readily available on the internet.

These custom tools attempt to authenticate into the system using predefined lists of usernames and passwords, dictionary attacks and brute-force attacks. A dictionary attack uses pre-computed wordlists like dictionaries to try to authenticate on the web applications by trying thousands of combinations of these dictionary words as usernames and passwords.

A brute force attack is a method of defeating a cryptographic scheme by trying a large number of possibilities; for example, exhaustively working through all possible keys in order to decrypt a message.

Solution

Preventing Authentication Hacking attacks
To verify whether an attack phase has succeeded or not, automated tools assess the returned error codes and page information from the host web server. A secure practice is to force any error or unexpected request to generate a HTTP 200 OK response, instead of the numerous 400 type errors. This will make it more difficult for the attacker to distinguish between valid and invalid login attempts.

An important measure in stopping automated brute-force authentication attacks is by adding random content on the page presented to the authenticating client browser. The client must be capable of successfully submitting this random content as part of the authentication process to proceed further in the web site or application. The best way to do this is to present the random phrase in a graphic GIF, JPG or PNG format using random fonts or colours each time.