Authentication is a security measure in computing
designed to verify the claimed identity of an entity before it is given
a privilege to access any protected resources. Although authentication is conceptually the simplest of all
the security mechanisms employed within web applications, its
functionality is subject to more design weaknesses than any other
security mechanism commonly employed.
The Authentication Model
The authentication model is consisted of
- Authentication factor - a
piece of information offered by an entity to claim its
- knowledge-based (what the entity knows) - password, ID,
- possession-based (what the entity has) - passport, token,
- biometric-based (what the entity is) - fingerprint,
face geometry, etc.
- Input - the interface used to offer the
proof. This commonly is a computer keyboard, card reader,
OCR, video camera, and so on.
- Transport - the segment that transfers
the proof between the input interface and the verification
- Verification - the component that verify
- Factor-based: using one or more
types of factor for authentication.
- One factor: for example, one
knowledge-based factor such as username and password
- Multiple factor: for example, using an
account number (knowledge-based) and the IP or machine ID of the the
- Service-based: for example, using the
Microsoft Passport authentication service.
- Basic Authentication
- This authentication relies on the Web server for
authentication to protected areas and is supported by nearly all
- When a user accesses a site, a standard popup window is
created by the browser to ask for username and
- The username and password combination is then encoded
(base 64) and passed in an unencrypted form to the Web server. The Web
server compares the encoded value against values stored in a flat file,
a database, or a directory server.
- If the user is authenticated, the server then verifies
that the user has the privilege to access the requested page against a
file, such as httpd.conf.
- If the user has access, the Web server then serves the
- If the user is denied access, the server either requests
the username/password combination again or presents an error message on
the browser window.
- Form-based Authentication
- It is the most common authentication approaches
employed by web applications.
- It uses HTML forms to capture a username and password and
submit these to the application.
validating the user's credentials, the website stores an authentication
ticket cookie on the user's browser, which is sent with every
subsequent request to the website and is what is used to authenticate
- In more security-critical web applications, this basic
mechanism is often expanded into multiple stages, requiring the user to
submit additional credentials, such as PIN numbers or selected
characters from a secret word.
- Username enumeration is the efficient guessing of username.
- Error messages in login: Record every
detail of the servers responses to each login attempt, including the
status code, any redirects, information displayed on screen,
and any differences hidden away in the HTML page source. Use your
intercepting proxy to maintain a full history of all traffic
to and from the server.
- You have entered a bad username: The username does not
exist. In this instance, an automated attack can be used to iterate
through a large list of common usernames to enumerate which of these
- You have entered a bad password: The username exists,
but the password does not.
- You have entered a bad username/password: Unknown.
- Many web applications allow users to create their own
username and password, which would present a vector to determine the
- In the registration process, if the application returns a
error message saying please choose another username, it is likely
that the username just entered exists.
- Username in a hidden field or cookie: Username is usually
stored in a hidden filed or cookie that can be stolen.
- Account lockout:
- Many web applications lock out account after a certain
number of failed login attempts and automatically unlock the account
after a period of time.
- An application may set a cookie or hidden form to store
the number of login attempts and increment this number following each
- Account lockout policy is not valid for non-existing
- It is best not to inform the user that the account is
being locked out.
- ASP.net membership providers can choose to implement account lockouts mechanism.
- SqlMembershipProvider keeps track of failed attempts at using a password by storing tracking information in the FailedPasswordAttemptCount and FailedPasswordAttemptWindowStart columns of the aspnet_Membership table.
- The first time an incorrect password is supplied, two things occur:
- The FailedPasswordAttemptCount in the Default.aspx is incremented by one.
- The FailedPasswordAttemptWindowStart column is set to the current UTC date time.
- The next time a password parameter is called the AttemptWindow and maxInvalidPasswordAttempts are used.
- Email username: Many authentication
mechanisms disclose usernames either implicitly or explicitly. In a web
mail account, the username is often the email address, which is common
knowledge by design. Many other sites expose usernames within the
application without considering the advantage this grants to an
attacker, or allow usernames to be easily guessed
- General Steps:
- Review the web site for any description of the rules.
- If self-registration is possible, attempt to register
several accounts with different kinds of weak passwords to discover
what rules are in place.
- If you control a single account and password change is
possible, attempt to change your password to various weak values.
- Brute-force approach: If a web
application allows an attacker to make repeated login attempts with
different passwords until the correct one is guessed, then it is highly
vulnerable. Given todays bandwidth and processing
capabilities, it is possible to automatically make thousands of login
attempts per minute. As a result, even the most robust passwords will
be eventually broken.
- Manually submit several bad login attempts for an account
you control, monitoring the error messages received.
- After around 10 failed logins, if the application has not
message about account lockout, attempt to login correctly. If this
succeeds, there is probably no account lockout policy.
- If you
do not control any accounts, attempt to enumerate a valid username and
make several bad logins using this, monitoring for any error messages
about account lockout.
- To mount a brute-force attack, first
identify a difference in the applications behavior in response to
successful and failed logins, which can be used to discriminate between
these during the course of the automated attack.
- Obtain a list
of enumerated or common usernames and a list of common passwords. Use
any information obtained about password quality rules to tailor the
password list so as to avoid superfluous test cases.
- Use a
suitable tool or a custom script to quickly generate login requests
using all permutations of these usernames and passwords. Monitor the
servers responses to identify login attempts that are successful.
- User login credentials can be eavesdropped if a web
application uses an unencrypted HTTP connection.
- Even if login occurs over HTTPS, credentials may still be
disclosed to unauthorized parties if the application handles them in an
- The credentials are transmitted as query string
- Although most web applications do use the body of a POST
request to submit the HTML login form itself, it is surprisingly common
to see the login request being handled via a redirect to a different
URL with the same credentials passed as query string parameters.
- Web applications sometimes store user credentials in
cookies, usually to implement poorly designed mechanisms for login,
password change, remember me, and so on. These credentials are
- Use strong credentials: Suitable minimum
password quality requirements should be enforced. These may include
rules regarding: minimum length; the appearance of alphabetical,
numeric, and typographical characters; the appearance of both uppercase
and lowercase characters; the avoidance of dictionary words, names,
and other common passwords; the prevention of a password being set to
the username; and the prevention of a similarity or match with
previously set passwords.
- Employ sufficient entropy: Any
system-generated usernames and passwords should be created with
sufficient entropy that they cannot feasibly be sequenced or predicted
even by an attacker who gains access to a large sample of successively
- Handle credentials secretively:
- All credentials should be created, stored, and
transmitted in a manner that does not lead to unauthorized disclosure.
- All client-server communications should be protected
using a cryptographic technology, such as SSL.
- Only POST requests should be used for transmitting
credentials to the server. Credentials should never be placed in URL
parameters or cookies and should never be transmitted back to the
client, even in parameters to a redirect.
- All server-side application components should store
credentials in a manner that does not allow their original values to be
easily recovered even by an attacker who gains full access to all the
relevant data within the applications database.
- Client-side remember me functionality should in general
only remember non-secret items such as usernames. In less
security-critical applications, it may be considered appropriate to
allow users to opt in to a facility to remember passwords. In this
situation, no clear-text credentials should be stored on the client,
and users should be warned about the risks from an attacker with
physical access to their computer or who compromises their computer
- A password change facility should be implemented, and
users should be obliged to change their password periodically.
- Where applicable, consider capturing some of the users
login information (for example, single letters from a memorable word)
using dropdown menus rather than text fields. This will prevent any
keyloggers installed on the users computer from capturing all of the
data they submit.
- Validate credentials properly:
- Passwords should be validated in full that is, in a
case-sensitive way, without filtering or modifying any characters, and
without truncating the password.
- The application should be aggressive in defending itself
against unexpected events occurring during login processing.
- All authentication logic should be closely code-reviewed,
both as pseudo-code and as actual application source code, to identify
logic errors such as fail-open conditions.
- Multistage logins should be strictly controlled to
prevent an attacker from interfering with the transitions and
relationships between the stages.
- Prevent information leakage:
- The web application should not disclose any information
about authentication parameters, either through overt messages or
through inference from other aspects of the applications behavior.
- If the application supports self-registration, then it
can prevent this function from being used to enumerate existing
- Do not store password in cookies.
- Prevent brute-force attacks:
- Use unpredictable usernames and preventing their
enumeration presents a significant obstacle to completely blind
brute-force attacks, and HTTP status codes, other information hidden in
HTML, and the like.
- Disable an account after a small number of failed logins
and require that the account owner take various out-of-band steps to
reactivate the account, such as telephoning customer support and
answering a series of security questions.
- A web application can specifically protect itself against
this kind of attack through the use of CAPTCHA (Completely Automated
Public Turing test to tell Computers and Humans Apart) challenges on
every page that may be a target for brute-force attacks. A CAPTCHA is a
type of challenge-response test used in computing to determine that the
response is not generated by a computer. The process involves one
computer (a server) asking a user to complete a simple test which the
computer is able to generate and grade. Because other computers are
unable to solve the CAPTCHA, any user entering a correct solution is
presumed to be human. A common type of CAPTCHA requires that the user
type the letters of a distorted image, sometimes with the addition of
an obscured sequence of letters or digits that appears on the screen.
- Re-authentication: While authentication itself is critical aspect to secure, even solid
authentication mechanisms can be undermined by flawed credential
management functions, including password change, "forgot my
password", "remember my password", account update, and
other related functions. Because "walk by" attacks are likely for
many web applications, all account management functions should
require re-authentication even if the user has a valid session id, in
case an attacker has discovered a session where the original user has
failed to log out.