Software Security

Table User
This technique has the following objectives:


 * 1) The user password will not be stored in the database.
 * 2) Avoid that intruses permute fields or overwrite table fields to acquire the desired role / privileges / rights.
 * 3) Avoid brutal force

The table user has 3 Fields:
 * 1) codUser - Integer (auto increment)
 * 2) strLogin - Varchar (50)
 * 3) strMasked - Text

This technique will not save the user password in the database. It will use the user password to crypt / decrypt everything into the database and a passphrase to mask the password.

A constant as String will be created in one Modul of the application that will be used as the passphrase.

The login is unique and the system will crypt the login using the user password and write it in the field strLogin. There are two reasons to do so: It facilitates the search function when the user logs in the system and it will check if the user entered the right password.

The rest of the fields inclusive the passphrase at the first position will be concatened using a separator like "@$@". The final string will be crypted / decrypted using the user password. For example, suppose that the table User will store the following information:


 * login
 * first name
 * last name
 * role
 * codDepartment

The final string to be saved into the field strMasked will be :

"passphrase@$@first name@$@last name@$@role@$@codDepartment"

This string will be crypted using the user password and saved in the database. Notice that the user password will not be stored in the database. The first objective was reached.

When the user logs on, the system crypts the entered login with the entered password and searchs on the field strLogin for this string. If the login is not found, the user receives a message that his login or password are incorrect.

If the login is found, the field strMasked will be decrypted using the user password. After this the system will retrieve the first field of the concatened string and check if it is equal to the passphrase. If it is not, the user receives a message that his login or password are incorrect.

Doing this the system avoids that an intruse updates the field strLogin of the table User with a known login and password to try to get the role with more privileges (e.g. administrator). The second objective was reached. Example:


 * Suppose that the intruse knows the login and password of the user Leonard. He knows also the database password.
 * The intruse logs on the database and execute an UPDATE on the table user to get more privileges of other users. He substitute the field strLogin with the strLogin of Leonard. He deletes the user Leonard.
 * The intruse starts the system and enter the login and password of Leonard. The system finds the record of Leonard, but when the system uses the entered password to decrypt the field strMasked, the crypt algorythm fails or the returned string makes no sense. The system checks if there is the passphrase on the first position and it doesn't match with the internal passphrase. The intruse will always receive a message of failed.

The only problem is that the intruse got the login or password of the person X. The person X possibilited the access to his/her password. And this problem is known in every system of security.

To reach the third objective, the system has to force the users to enter at least 6 characters in theirs password, to force the use of special characters. The system blocks the user for X minutes if the user failed three times to log in.