Guide to Authentication

From OWASP
Revision as of 16:01, 19 November 2008 by Vanderaj (Talk | contribs)

Jump to: navigation, search
Development Guide Table of Contents

Contents


Objective

To provide secure authentication services to web applications, by:

  • Tying a system identity to an individual user by the use of a credential
  • Providing reasonable authentication controls as per the application’s risk
  • Denying access to attackers who use various methods to attack the authentication system

Environments Affected

All.

Relevant COBIT Topics

DS5 – All sections should be reviewed. This section covers nearly all COBIT detailed control objectives.


Architectural Goals

All applications should take into account the following architectural goals:

  • All applications within your organization SHOULD share a well-debugged and trusted authentication mechanism if possible
  • All secured functions and secured resources SHOULD be protected by a common authentication mechanism within the one application
  • All authentication processes SHOULD be conducted over encrypted links, particularly weak authentication mechanisms such as passwords
  • All pages SHOULD have an effective logout button on every single page in a common location
  • Applications SHOULD have the facility to alert the user as to failed login attempts and offer to allow them to change their password (if applicable)
  • Applications SHOULD have the facility to notify the user of their last logged in time, and subsequently report a fraudulent login if they disagree with that date and time
  • Applications MUST protect credentials from common authentication attacks as detailed in the Testing Guide. Following the sections in this chapter will produce such an outcome
  • Medium value applications SHOULD and High value applications MUST provide a mechanism to re-authenticate or transaction sign high value transactions
  • Authentication and registration processes, particularly login failures, SHOULD provide no information as to if an account exists or password or is wrong. A single error message for the end user covering both scenarios is more than adequate
  • Applications SHOULD possess administrative functions to detail and manage never logged in accounts, idle accounts, and accounts that have been administratively- or soft- locked
  • Credential stores MUST implement one-way hash and salted storage of secrets such as passwords using acceptable hashing algorithms.
  • Applications SHOULD be designed to implement several hashing algorithms as these will be replaced soon and change is inevitable and should be planned for today
  • Applications SHOULD implement configurable settings for thresholds, lockouts, password complexity and alerts

Things not to do:

  • Applications MUST NOT store any secret part of the credential in the clear (passwords or questions and answers if implemented)
  • Applications MUST NOT expose the credential in untrusted locations, such as cookies, headers or hidden fields
  • Applications MUST NOT implement CAPTCHA as there is case law against them with respect to universal access and ineffective
  • Applications MUST NOT implement questions and answers as they are contrary to most privacy regimes and ineffective


Thresholds Governor

All authentication systems are designed to be open to anonymous, unauthenticated users. Therefore, they are open to denial of service and brute force attacks.

Applications implementing their own authentication systems should consider a threshold governor to prevent the over-use of the following paths:

  • Account registration processes (if any)
  • Primary authentication path
  • Step up authentication (such as two factor tokens)
  • Password resets (Low value systems only)

Most medium and all high value systems should not be using passwords, and thus do not possess password reset capabilities.

Sequence Diagram

Suggested Timeouts

The following timeouts are suggested, but any value will do as long as it severely impacts

  • One failed attempt: 5-15 seconds
  • Two failed attempts: 15-45 seconds
  • Three failed attempts: 45 seconds to 3 minutes

If there's an obvious brute force attempt (for example, more than 100 attempts per minute), the IP address and/or session should be banned for a period of time, such as 15 minutes. In such cases, error messages should make it clear why this action has been taken.

Distributed Brute Force

If in case of a distributed brute force, the application should monitor the total number of failed authentication attempts per minute, and have a configurable threshold above which the authentication system automatically injects a configurable 45+ second delay between authentication attempts. This will make all but the largest distributed brute force attempt infeasible, even when looking for a single account with a well known password.

Authenticating Value Transactions with Transaction Signing

TBA

Token Based Transaction Signing Sequence Diagram

TBA

SMS Based Transaction Signing Sequence Diagram

TBA

Authenticating With Multi-Factor Systems

TBA

Sequence Diagram

TBA

Single-Sign On (SSO) Authentication

TBA. Discuss LDAP, AD, TAM, SiteMinder.

Sequence Diagram

TBA

Federated Authentication

TBA

Sequence Diagram

TBA

Authentication For Low Value Systems

Low value systems, such as blogs, social networks and so on, should be free to implement weak authentication mechanisms. If given the chance, users should be able to adopt stronger authentication mechanisms if you have them available.

Registration

Self-registration can be problematic, particularly for highly sought after resources such as free mail accounts.

Password Sequence Diagram

Internally, your application should:

  • Store the password in a strongly hashed and salted format to prevent rainbow table attacks.
  • Compare the return from the credential store to ensure that only one or zero results are returned


Password Guidelines

Passwords are intrinsically weak. Therefore, your application should encourage good password practices:

  • Credentials should only traverse encrypted links
  • Pass phrases (long passwords over 20 characters in length) should be encouraged
  • Short passwords should be prohibited
  • Do not force folks to change passwords frequently as this results in the users writing the passwords down insecurely
  • Where suitable, try to share the credential with as many low value systems as possible to encourage one single high quality password
  • Allow expert users to store strong passwords in approved password managers. Encourage them to use unique random passwords for each service

Lockouts

Lockouts are counter-productive if implemented badly.

In general, the threshold governor (see above) should be implemented to prevent any one IP address monopolizing authentication CPU, network, and IO resources. If necessary, such as for compliance with a national security standard, a configurable soft lockout of approximately 15-30 minutes should apply, with an error message stating the reason and when the account will become active again.

Ensure any lockout mechanism protects against both same username, many passwords and many usernames and same password attacks. This can only be done using the threshold governor approach as shown above.

Minimum hash strength

The minimum hash strength SHOULD be SHA-256 for the next few years.

Applications MUST be designed to allow selection of multiple algorithms, as the USA's NIST is currently running an hashing algorithm competition, which will choose a successor to SHA-256, SHA-384, and SHA-512. Your application MUST be able to transition to the new hashing algorithm by no later than one year after the new algorithms release. This doesn't mean that MD5 will be dead at that point, but your application should cope with the idea that insecure algorithms such as MD5 or SHA-1 can be retired at some point.

Authentication Anti-Patterns

Do not implement any of these features - they are either illegal, ineffective, or both.

CAPTCHA

CAPTCHA (Completely automated Turing Tests To Tell Humans and Computers Apart) are illegal in any jurisdiction that prohibits discrimination against disabled citizens. This is essentially the entire world. Although CAPTCHAs seem useful, they are in fact, trivial to break using on of three methods:

  • Optical Character Recognition. Most common CAPTCHAs are solvable using specialist CAPTCHA breaking OCR software.
  • Break a test, get free access to foo, where foo is a desirable resource
  • Pay someone to solve the CAPTCHAs. The current rate at the time of writing is $12 per 500 tests.

Therefore implementing CAPTCHAs in your software is most likely to be illegal in at least a few countries, and worse - completely ineffective.

Secret Questions And Answers

Questions and answers are back door credentials - they equate to the username and password for the user. Often such schemes use "Mother's Maiden Name" or other easily found information. If all systems use the same Q&As, it will be possible to break into many accounts using the same information.

They are unacceptable for the following reasons:

  • Collection of information about people without their explicit consent (such as "Mother's maiden name") is illegal in most privacy regimes. Such collection is subject to privacy laws, review and correction by the subject, and so on.
  • IT Security Policies and standards such as ISO 27000 prohibit the clear text storage of passwords, but almost all Q&A schemes store both the question and answer in the clear
  • The information in the answers is public for a goodly portion of the users of the Internet, and thus is found using public sources

Secret Questions and Answers have been publicly abused, most notably by the attack on Sarah Palin's e-mail account, exposing her use of her Yahoo free mail account for government business.

Development Guide Table of Contents