Authentication

The Authentication Model

• Authentication factor  - a piece of information offered by an entity to claim its authenticity. 
• knowledge-based (what the entity knows) - password, ID, PIN, etc.
• possession-based (what the entity has) - passport, token, ID-card, etc.
• 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 component. 
• Verification - the component that verify the proof.
  

Authentication Approaches

• 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 client (possession-based).
• Service-based: for example, using the Microsoft Passport authentication service.

Web-based Authentication

• Basic Authentication
• This authentication relies on the Web server for authentication to protected areas and is supported by nearly all browsers.  
• When a user accesses a site, a standard popup window is created by the browser to ask for username and password.  
• 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 page. 
• 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.
• Upon 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 the user.
• 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

• 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 are valid.
• You have entered a bad password: The username exists, but the password does not.
• You have entered a bad username/password: Unknown.
• Registration:
• Many web applications allow users to create their own username and password, which would present a vector to determine the username.
• 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 unsuccessful attempt.
• Account lockout policy is not valid for non-existing accounts.
• 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
  

Password Guessing

• 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 returned any 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.

Authentication Eavesdropping

• 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 unsafe manner:
• The credentials are transmitted as query string parameters.
• 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 vulnerable.
  

Defensive Mechanism

• 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 generated instances.
• 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 remotely.
• 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 usernames.
• 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.