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:
- Forgotten password
- Change password
- Account deletion
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.
- 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.
- 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.
- 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.
- The browser can display the timestamp of the previous successful 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.
- If the user has forgotten the password, the user clicks on the forgotten password link which brings the user to the forgotten password page.
- 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.
- When the user clicks on the link in the email, they are brought back to the secret question page.
- 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.
- 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.
- 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.
- 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.