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