Sage CRM uses the bcrypt algorithm to generate hashes for user passwords.
Bcrypt adds a salt (a random string of characters) to each password hash before storing it in the database.
You may be familiar with encryption as the process of encoding data, like a password, in such a way that only an authorized party can access it. Encrypting data is a two-way mechanism and works well in systems where you need to retrieve data and display it in its original form.
But passwords don't need to be 'read' or 'decrypted' as we only need to compare the stored password with the data that the user inputs and then verify it as the same. Encryption of passwords can be a vulnerability because if an attacker learnt how one password was encrypted then potentially they would have access to all passwords stored on the system.
Sage CRM uses the idea of hashing. Hashing in Sage CRM uses the bcrypt algorithm to convert passwords into a unique string. The important thing about hashing is that this is a one-way method. Consider the idea of writing a password on a bit of paper and then burning the paper. The paper will have been transformed into ash by the process of burning it but this process can not be reversed.
So when we check a password in Sage CRM, the password is not 'decrypted' and compared with the plain text example. Instead to compare a password, when a user logins on, the same bcrypt hashing operation is performed on the password the user has entered and then this is compared with the previously hashed version stored in the database. If they're identical, the password is verified.
I mentioned at the top of the article that the bcrypt hashing function adds a "salt" to the password. In cryptography, a salt is random data that is used as an additional input to a one-way function that "hashes" data.
In Sage CRM system administrators can change the password hash strength using a new Use Dynamic Password
Hash Cost field in
Administration | Users | User Configuration.
This field can take the following values:
l Yes (default). Enables optimum password hash strength based on the Sage CRM server hardware capabilities. Provides increased security but consumes more system resources because it increases the number of hashing rounds used to generate a password hash.
l No (not recommended). Disables optimum password hash strength. Provides weaker security (less hashing rounds) but frees up system resources. System administrators might want to set this value to speed up the system performance, for example, when there is a high number of simultaneous Sage CRM user logins.
This ability to use a dynamic password hash cost allows Sage CRM to use password security that scales with computation power. The hashing of the password will be scalable with hardware via a dynamic number of rounds. The cost within bcrypt is the power-of-two number of rounds of bcrypt applied. This means that a cost of 10 implies 1,024 rounds of hashing.
Add that the per-password salts that bcrypt requires and you can be sure that the feasibility of a password attack on Sage CRM is reduced to the minimum without either unlimited time, money or hardware to through at the attack.
The bcrypt algorithm is applied only when a user password is changed.
This means that existing user passwords are not re-hashed using bcrypt after upgrading Sage CRM.
Therefore you may wish to consider forcing users to change password at next login after an upgrade. This can be done by running a simple script within the database.
update users
set User_MustChangePassword = 'True'
