User passwords improperly stored

From Safeval Wiki
Revision as of 15:08, 14 April 2015 by (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The storage of passwords in the database, if not done correctly, allows the database administrator to recover user passwords. As the password, by definition, should only be known by the user. Even system administrators should not be able to know the password for a given user. This prevents the user accountability for their actions. If a user is caught committing a fraud, he can always say that wasn't him but one of the administrators that also know his password. Besides the possibility of an attack by the system administrator, using passwords recovered in the database.

The password must be stored hashed, or one-way encryption. The hash algorithm must be of good quality (recommended today are SHA-2 384 or 512), the hash should be done on the concatenation of the login + password + salt, where the salt is a random generated number for each table record, stored in a separated column. Some systems implements the salt as a global number for all user records, that does not prevent the rainbow tables attack, which is the main concern when using the salt.

As the hash is an one way encryption, the validation of the password must repeat the same steps and compare the hash generated with the authentication credentials presented by the user with the hash stored in the database. The table which contains the authentication information of the users must be protected, with the minimum access possible.

These recommendations are usually implemented in LDAP password storage, so an alternative is to store the user passwords in a LDAP repository.