Authentication & Authorisation
If you fail to build strong authentication processes into your application an attacker could access sensitive content without having to properly authenticate. Although this sounds like an issue principle number 7 (Secure Resource Access) should address there is a clear difference between the two.
The Authentication and Authorisation principle will aim to remove
the following risks (this is not an exhaustive list):
- Lack of an appropriate timeout
- The use of weak password
- The use of weak “secret question” system
- The use of broken CAPTCHA system
- Failure to protect credentials in transit
- Failure to implement least privilege access
If you are required to provide a logon within your application you should also implement timeouts and the requirement for users to set strong passwords. To determine how long your timeouts should be you need to establish the sensitivity of the data or resource you are trying to protect. The timeout for an online bank would more than likely be shorter than the timeout for an online game site for example.
The same question would apply when you are determining how strong your users passwords should be, what are you trying to protect? In general your application should enforce the use of complex passwords with a minimum length of 7 characters. Complex passwords normally mandate the use of 3 of the following 4 elements:
- Uppercase characters
- Lowercase characters
- Special characters (i.e. @$^&)
Depending on the applications purpose you should implement additional password controls such as a maximum age and prevention of password re-use. The passwords must be protected whilst being stored on application servers and whilst they are transmitted. There are several points during the lifetime of a password which I feel require special attention.
The passwords must be stored in a secure location and encrypted, they must never be transmitted in the clear (i.e. without using protection such as SSL) and never fully visible in account management emails.
At this point we are beginning to construct a secure authentication system but this hard work can be undone by the incorrect use of automated systems designed to help you and your users. Almost every web application will have some form of password reminder system and a high percentage of them would have security weaknesses. These systems are designed to provide self service capabilities to the end users but they can also assist attackers in hijacking user’s accounts. The point at which these system traditionally fail is the secret questions used for password reminders, the answers to these questions can be easily guessed with a small amount of social engineering or brute forcing of the values. If your system used a question such as “What is your favourite capital city” the attacker knows this has a finite set of answers and can attempt to brute force the correct answer. If the secret question system fails to prevent a brute force attacks the user’s password can be easily obtained. To prevent these kinds of attacks you could allow the user to define their own secret question or require the users to answer multiple questions before revealing the password.
In addition to weaknesses in the secret questions many systems fail when they attempt to create information verification functions. The information verification piece of password reminder systems will often fail to demand enough information from the end user before granting them the account password. It is a common mistake made by these systems and you should attempt to avoid this where possible, make sure that your systems require information from the user that isn’t easily obtainable such as an email address.
A second system often used during user account creation and management is CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart). As the name implies these system are used to validate that a user as opposed to a computer is providing the input to your system but there have been many high profile failures of such systems. CAPTCHA systems implemented by Google, Microsoft and Yahoo have been broken which shows how difficult it can be to get this right. If you do decide to utilise this technology you need to ensure that CAPTCHAS are not simple to guess (i.e. What is 2+3) or clear enough to be read by OCR software.
The final thing to remember in this principle is the enforcement of authorisation through least privilege. A simple application could have two levels of access, user access and administrative access and each one will have its own access requirements. An obvious difference between the two levels of access is the authorisation to use the administrative functions of the application. The administrative functions should only be available to users in the admin group and the standard users must not have the capability to elevate their privileges. The user accounts used for your application should be given the least amount of privileges required for them to function correctly. The ideal starting point would be to configure access controls to deny all access and gradually increase the access until you find the right level for each user role.
You should always avoid using client side values to make access decisions, avoid using information such as client side tokens, URL values or hidden fields because they can be manipulated to give a user elevated privileges.