Using strong password hashing with OTRS

In the last years we saw several cases of websites getting hacked and having the passwords of their users leaked. This happened for instance at LinkedIn in 2012. The user passwords were not stored in the database in plain text but hashed with SHA-1 and this algorithm is pretty weak nowadays meaning if a hacker would be able to get the password hashes, it’s possible to expose the original passwords.

As a result of this, OTRS added support for hashing passwords for agents and customers using bcrypt starting OTRS 3.3.  Since it depends on an external module, it is not enabled by default! This means that, if you want to preventing the nasty event your systems would be compromised your users’ passwords are out there in the open, you’d better enable it manually. Luckily this is not hard.

Details of the hashing – skip if you want!

As all modern systems, OTRS uses two techniques called ‘salting’ and ‘hashing’ to store passwords. This means that OTRS does not store the users’ password in the database, so the passwords can’t be stolen directly. Instead, it stores the hashed value, and this is supposed to be a one way hash. This means, if your password would be ‘secret123’ (which would obviously be a terrible example of a password) OTRS takes this, along with a random value, the salt, and calculates the hash. It then stores the salt and the hash in the database. Salting is used to prevent a situation where two users with identical passwords would end up having the same hashes and thus preventing the use of pre-constructed rainbow tables. If the user tries to log in, he supplies his password in clear text. After that, the salt is read from the database and together with user input a hash is calculated and this hash is compared with the value in the database. If these are equal, access is allowed.

If the hashing operation is ‘expensive’ enough, i.e. it costs a relative lot of time to perform the hashing, crackers can not easily find out your passwords would they obtain a copy of your database.

If you don’t do anything by default, OTRS uses SHA-256 hashing which is not as bad as MD5, but it’s not industry best practice anymore either. Using special hardware you can calculate SHA-256 hashes pretty fast. bcrypt is really much stronger; especially because OTRS uses a better salting mechanism with bcrypt than what it uses with SHA-256. You don’t need to know any of these implementation details, just follow the simple steps below!

Installing the module

It might just be you already have the needed module installed. Log into your OTRS machine and run bin/otrs.CheckModules.pl

$ perl bin/otrs.CheckModules.pl 
  o Apache2::Reload..................ok (v0.12)
  o Archive::Tar.....................ok (v1.76)
  o Archive::Zip.....................ok (v1.30)
  o Crypt::Eksblowfish::Bcrypt.......ok (v0.008)
  ....

If the Crypt::Eksblowfish::Bcrypt module is installed, the output would look like above. If not, you’d need to install it. You can best do that from your package manager. On Red Hat or CentOS this is as simple as

sudo yum install "perl(Crypt::Eksblowfish::Bcrypt)"

although if you do not yet have the EPEL repository enabled, you should do that first!

sudo yum install epel-release

On Debian or Ubuntu, you would use

sudo apt-get install libcrypt-eksblowfish-perl

Now you can run the bin/otrs.CheckModules.pl script again to verify the installation.

Configuring OTRS

In OTRS, you should change the password hashing mechanism for both customers and agents. For customers, you can simply navigate to Admin > SysConfig > Frontend::Customer::Auth and change the CryptType setting to ‘bcrypt’.

For agents, there is no such convenient configuration setting available and you should modify the Kernel/Config.pm file with a text editor and add this option:

$Self->{'AuthModule::DB::CryptType'} = 'bcrypt';

After this, the changes are effective immediately for newly saved passwords. Passwords that were already set are NOT automatically upgraded.

Verifying the change

If you’d want to make sure the new mechanism works, you can change your password and log out & in in OTRS, then check the log. You’ll see the hashing method used:

Since this configuration change does NOT update existing user passwords, it is best to make this change before you take OTRS in production.