Most web applications combine a front end, customer facing website with a backend administration system. Typically the backend admin area will be accessed by many different people with varying levels of access rights from various locations.

The security of these backend systems often requires more safeguards than typical User Account systems you might find on the front end of a website, as the administrators may have access to lots of personal information about customers etc.

However, the principles below can be applied to any web application, front end or back end, that has User Accounts, if you want them to. Just bear in mind that some of them can be a bit of a pain for the genuine user.

Password Strength Validation

The idea is that passwords are of sufficient strength to reduce the chances of brute forcing the system. Since the strength of a password is an indefinite term, there are many different ways of determining it.

The implementation is achieved through the application of one or more validation rules applied to the password to ensure it is of valid strength, before the password is changed or the user created.

Such rules include:

1. Minimum length, e.g. at least 6 characters
2. Does not contain strings like password, passwd, pass etc
3. Contains characters from at least 2 or 3 of the following character classes:
   - Lower case characters: a-z
   - Upper case characters: A-Z
   - Numerals: 0-9
   - Non alphanumeric character e.g. punctuation
4. Does not contain strings (tokens) from the user’s data (tokens are strings from the user’s name or username etc, split on non alphabetic chars, that are 3 or more chars long).

Account Lockout

The idea is that when a user enters the incorrect password 3 times in a row, their account is locked, and all subsequent login attempts, even those with the correct password will fail.

This is implemented by incrementing a “failed login attempts” field in the “users” database table on detecting a failed login, for a given user, identified by their username.

Following a successful login, if the failed login attempts field is 3 or more, the user is logged out, and they are informed their account has been locked and provides instructions on how to reset it. Else, if the failed login attempts field is less than 3, it is reset to 0 and the user is allowed to proceed.

Recent Account Activity

The idea is that a user should frequently (say at least every 90 days) log in to their account, else it is deemed expired.

It is implemented by updating a “last login” field in the “users” database table to the current time, every time a successful login occurs. Then, adding a check to the login process to ensure that the last login time was not more than 90 (or whatever) days ago.

You’ll need to display a helpful error message for how the user can actually get their account re-activated, and build in functionality for an appropriately senior user to do this too.

Password Change Frequency

The idea is that users are forced to change their password frequently (say at least every 90 days).

It is implemented by updating a “last password” change field in the “users” database table to the current time, every time the user’s password is changed.

Then, on each request for a page that requires a user to be logged in, you should also check that the password has been changed within the predetermined time period. If it hasn’t, the user should be redirected to the “change password” page.

In addition, for this to be effective, the user cannot re-use the same password each time, so you need another database table to record the “password histories” with fields for the “user id” and the “password”.

Then, before allowing a new password to be chosen, you can check whether it is already in the history, if it is, the password is invalid. And when the password is changed (or the user is created) you can add it to the history.