User Lifecycle - Part II

Introduction
The first article in this two part series looked at user identification, and registration. The second part, considers other important phases of the user lifecycle:

• Logon
• Forgotten password
• Change password
• Logout
• Account deletion

User Lifecycle - Logon
At this stage the user has registered. As part of the registration phase, the user will have entered their email address and chosen a password. This article assumes that the application uses the email address as their username.

1. To logon, the user enters their email address and password on a logon screen. These credentials are sent via SSL/TLS to the application for verification.
   
2. The username and password are verified. The first step is to verify that the email exists. If the email address does not exist, then an error is returned to the user. However, the error message should be generic, saying that the incorrect credentials were entered. It should not say which credential (email address or password) was incorrect. This is to prevent harvesting of valid email addresses.
3. If the email address exists, then the next step is for the application to verify the password. To verify the password, the application should take the entered password and hash it, using the same salting and hashing values that were used at registration. If the hashed value of the entered password and the stored hashed password match, then the application can log the user in successfully.
4. The browser can display the timestamp of the previous successful logon.
   

Some notes to the logon:
To help prevent brute-force automated attacks, only allow a login attempt every few seconds. The normal user will not notice the delay, however it will significantly slow down the rate at which an automated script can attempt to logon.

After a few unsuccessful logon attempts (e.g. five), consider disabling the account for a few minutes (e.g. five) before the user can attempt to logon again. Again the purpose of this is to prevent brute-force attacks.

User Lifecycle - Forgotten Password
The forgotten password mechanism is a tricky part of the user lifecycle. Many websites just email out the password in cleartext. This is a very poor practice, as the password could be intercepted in transit. It will also remain in the user's inbox, where it could be read by a casual user. In addition, many users will reuse the same password across multiple websites. So a casual user who sees the password gets access to several applications.

In an ideal world, the user contacts a customer support assistant (CSA). After the user successfully confirms their identity to the CSA, the CSA will reset the password for the user.

However, this is often not a financially acceptable option. It is expensive to operate. The alternative is usually based on secret questions and an email link. Care needs to be taken in implementing this solution. It is certainly not suitable for all applications and needs to be thought through.

The following steps outlines a general approach and leaves several issues unresolved. The mechanism you ultimately implement will depend on the application, the type of data that is being processed and the relationship with the user.

During the registration phase, the user created a number of secret questions and answers. These are now used for the forgotten password mechanism.

1. If the user has forgotten the password, the user clicks on the forgotten password link which brings the user to the forgotten password page.
   
2. On this page, the user is asked to enter the email address. If the email address exists, the application sends a unique forgotten password email link to the user at that email address. Whether the email address exists or not, the user should be told that an email has been sent. This is to prevent harvesting of valid email addresses. The password link should be time-limited.
3. When the user clicks on the link in the email, they are brought back to the secret question page.
   
4. The user is presented with a number of the secret questions (e.g three) which were answered during the registration phase. The user must answer the three questions using the same answers that were entered during the registration phase.
   
5. If the user answers the questions correctly, they are brought to the password entry page. As during the original registration phase, the user must enter a password and confirm password page. The password must conform to the chosen password complexity rules.
   
6. Once the new password has been set, the forgotten password link should be deactivated. If the user goes through the password mechanism, then sensitive information (e.g. payment card numbers etc.) should be deleted.
7. Once the password has been changed, a notification email should be sent to the user.
   

The issue remains, what happens if the user cannot remember the answers to the secret questions. This effectively locks the user out of the application - which is usually not what the website operator wants. It comes down to a tradeoff between usability and security. At this stage it might be possible to consider other options. For example the user can send in a letter via normal mail requesting that their password be reset. Ultimately, it is important that the forgotten password mechanism be at least as difficult as the normal logon. It cannot be stressed enough that this element of the user lifecycle needs to be carefully worked out.

User Lifecycle -Change Password
The application should also have an option to for a user to change the password. Usually this facility is available when the user has logged on. The password update screen should require the user to enter their old password, the new password and the confirm password (which is the same as the new password). The new password should comply with the chosen complexity rules.

After the password has been updated, it would be worthwhile sending a notification email to the user.

User Lifecycle - Logout
The application needs have a logout option. A logout button should appear on every page of an authenticated session.

User Lifecycle -Account Deletion
At some stage the user may wish to end their relationship with the website. How this happens may depend on the type of data that is being processed. Personal data legislation usually states that data be held only as long as is necessary. This would imply that if the user wants to delete their account, all data associated with that account should be deleted as well.

However other types of applications (especially financial) may require that transaction records be held for a number of years.

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

User Lifecycle - Part I

Introduction
Originally published July 20th 2010
Updated July 28th 2010
Updated June 2012 - Slow Password Hashing
Management of the user lifecycle in online web applications is generally fairly poor. For example, the forgotten password mechanism is often a weak link. Web applications regularly email out the password in cleartext. This is not good. The password then remains in the user's inbox. Anybody who gets access to the email will be able to see the password.

The lifecycle covers all phases of the user's interaction with the website, starting with the registration/enrolment phase, through logon, logoff, and account deletion.

The password thicket: technical and market failures in human authentication on the web is an academic paper that "report the results of the first large-scale empirical analysis of password implementations deployed on the Internet". It is well worth reading and gives excellent information about logon and password practices.


This series of articles discusses some good practices in relation to the user lifecycle. It covers the important phases. It is aimed at web applications that rely on passwords as the authentication mechanism, as well as secret questions to handle the forgotten password mechanism.

Disclaimer

Your mileage may vary. Passwords are not suitable for all web applications. Depending on the type of data that your application processes, you may need to use two factor authentication or some other approach. This would apply, for example, in the banking sector.

You need to decide if a password based authentication approach and the use of secret questions as the forgotten password mechanism are secure enough for your development.

User Lifecycle- Identification

Some applications may require formal identification of potential users. This could be for anti-money laundering or other legislative purposes. The would-be users may need to provide proof of identity (e.g. passport) and proof of address (e.g. utility bills). They might have to go to a physical location in order to do this.

This scenario is probably beyond the scope of this document. However, it does mean that it might be possible to distribute logon credentials (e.g. passwords or activation codes) during the physical encounter.

User Lifecycle- Registration

If users decide to create an account with your website, these are some steps to consider:

1. On the registration screen, the user enters an email address.
2. The application checks to see if the email address is already being used. This step could be abused by an attacker to harvest a list of valid email addresses. Captcha technology could be used to prevent this. However this can put potential users off.
3. If the email address is available, the application then sends an email containing a unique activation link, to the email address. The main reason for this is to ensure that the user controls this email address.
4. The user clicks on the email activation link and is brought back to the website to complete registration.
5. The user enters the password and confirmation password on the password entry screen.
6. The application then checks that the chosen password meets the appropriate complexity requirements (e.g minimum length, mixture of letters and numbers etc.) and stores the password.
   
   The next step is to prepare for the forgotten password mechanism (otherwise known as the second logon mechanism). The most popular approach is to use some sort of secret questions.
   
7. The application should present the user with a list of secret questions (e.g. 20). The user must provide answers to a number of these (e.g. six). The good security questions website discusses security questions in more detail and also provides potential lists of questions.
8. When the user has entered the security answers, the user should be forcibly logged out. A notification email should be sent to the user confirming that the account has been created.
9. The user should then have to login again before continuing to use the website.

Some Notes:

• The email activation link should be time limited to something like 24 hours. If the user does not click on the link within this period, the account should be deactivated.
• Once the user has clicked on the activation link, the link should be deactivated.
• The HTML autocomplete field should be disabled on all sensitive fields.
• An attacker could (ab)use steps 1 and 2 to harvest email addresses of accounts which already exist. Consider using Captcha technology to prevent this.
• Use SSL/TLS to protect all communication related to the user lifecycle. In fact, just use SSL/TLS everyplace.
• Sensepost has a password strength checker with more information.
• Password should be stored using salt and hash techniques. Consideration should be given to using slow password hashing algorithms such as bcrypt. Older algorithms such as MSD5 should not be used . The password must not be stored in cleartext. In fact the password should never be visible in cleartext.

Future Article:
In a future article I will cover further phases in the lifecycle:

• Logon
• Forgotten password
• Update password
• Logoff
• Account deletion

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Session Management - Some Good Practices

Updated: April 9th 2012. Mainly addition of new HTTP headers to reflect developments over the last year or so.
 
"Broken Authentication and Session Management" is in at number 3 in the OWASP Top 10 - 2010 (up from number 7 in OWASP Top 10 - 2007). So here are a few good practices for managing sessions:

• Mark session cookies as secure
• Set the HTTPOnly flag on session cookies
• Generate a new session cookie on successful logon
• Have a Logout button on all pages where the session is authenticated. This should terminate the session.
• Set the AUTOCOMPLETE to off on sensitive HTML fields/forms such as credit card numbers:
  <INPUT NAME="name" AUTOCOMPLETE=OFF>
• Use the http meta refresh for browser timeouts. This will redirect to a timeout page after a period of inactivity:
  <meta http-equiv="refresh" content="300;url=timeoutpage " />
• Set caching parameters to prevent sensitive data from being left on browser
  
  1. Pragma: no-cache
  2. Cache-Control: no-cache
  3. Expires: -1

These are some other useful HTTP headers, which may or may not be supported by your user's browsers. Many of these are easy security wins. Set them once and forget about them and they should not have any negative impact. You need to find out how to implement them in your environment.

• Strict Transport Security - STS. This forces the browser to use SSL/TLS when connecting.
• X-Frame-Options: DENY or SAMEORIGIN. These control the handling of frames.
• X-XSS-Protection is a Microsoft Internet Explorer option aimed at helping to prevent XSS attacks in IE
• X-Content-Type-Options: nosniff  This tells the browser not to try and guess the content type of responses. However, your application should always set the proper content type in its responses.
• Content Security Policy - CSP.  This is aimed at preventing XSS. Essentially it tells browsers where content can be loaded from.  This is a very useful addition, but does require some effort to understand and implement correctly.

For details on how to implement them in your environment, use your favourite search engine.

Useful Links

• Wikipedia: Strict Transport Security - STS 
• Mozilla X-Frame-Options 
• Microsoft IE Internals X-XSS-Protection
• Microsoft X-Content-Type-Options
• W3 Content Security Policy Specification
• OWASP Session Management Cheat Sheet

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Tuesday Top Tip - Autocomplete

The following screenshot is from a Credit Card payment page which I regularly use.


I use Firefox mostly. When I double-click on the CVV2 field, the value that I used the previous time appears. The same applies to all the other Credit Card fields (number, name, address, etc). While this is great from a usability perspective, it's bad from a security point-of-view. A casual user in an Internet cafe scenario could easily get a list of valid credit cards by just double clicking on these fields. The Expiration Date is the only field which is not prefilled.

To prevent this from happening on your website, make sure to set the AUTOCOMPLETE field to OFF. You can do this at the HTML field or form level:

• <INPUT NAME="name" AUTOCOMPLETE=OFF >

That's Tuesday's Top Tip #1

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

OWASP Talk Dublin June 30th 2010

Here is the link to the talk that I gave at the OWASP Dublin meeting held on June 30th 2010. The title was:

"Define Security Requirements - A practical approach "

The link is about half-way down (JUN 2010) on the OWASP Ireland page.

The actual slides from the presentation are here.

In the talk I outline some steps that you should take at the beginning of a web development project to help you define security requirements. There are also some suggestions for good practice in relation to session management.

Finally, I have some slides about the User Life Cycle good practices, which I never got to during the talk. This section suggests good practices around the various stages:

• Identification
• Registration/Enrolment
• Logon/Logoff
• Forgotten Password Mechanism
• Logoff/Account Deletion

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot