Secure Password Storage

This feature will be part of ILIAS with version 4.5.x and above. As an administrator you will be able to choose the password encoding method in the ILIAS setup (default is still md5).
 
We suggest to upgrade to PHP 5.3.7+ when choosing bcrypt as the desired password encoder because of security flaws in the bcrypt implementation used by PHP. Please see the following link for details on the matter: http://php.net/security/crypt_blowfish.php
Furthermore ILIAS generates a random salt for the key derivation function bcrypt when it is selected for the first time. You are advised to copy this salt to a secure location for backup purposes. Each time a user's password gets stored, ILIAS will generate an additional salt for the individual password. Never change any salt used by ILIAS if it is generated once. Otherwise users will not be able to login anymore!

1 Description

The password of ILIAS is stored as a MD5 hashed string in the database. This is not state of the art and not recommended by the PHP documentation.
 
http://de2.php.net/manual/en/function.md5.php

Note: Secure password hashing
It is not recommended to use this function to secure passwords, due to the fast nature of this hashing algorithm.

Conclusion: We should improve the password security in ILIAS by changing the storage method.

2 Status

• Scheduled for: Release 5.0
• Funding: Databay AG and Mrs. Jansen
• Development: Databay AG
• Tester: Colin Kiegel
• Tested by: Machine (PHPUnit)

3 Additional Information

• If you want to know more about this feature, its implementation or funding, please contact: Michael Jansen / mjansen [at] databay [dot] de

4 Discussion

MJ 27 June 2012: I already implemented a more secure way to store passwords in the database for one of our customers.

JF 9 July 2012: We highly appreciate this feature and schedule it, if possible, for 4.3. Please add an additional password type field to the user data table. Migration can be done, when users authenticate. Export of the new password types should not be possible.

JF 20 Aug 2012: Since we have not the resources to implement this for 4.3 we will postpone it to 4.4.

SW 21 Aug 2012: Please consider for implementation, that md5 is also used in the excel-sheet for user management, where it is created by VBA and broadly used by community. It is to check if blowfish is supported by VBA and how to make the other security measures (random salt etc.) work along with ILIAS.

MJ 27 Nov 2012:
 
Concerning Export:
JF 9 July 2012: Export of the new password types should not be possible.
 
For a trunk integration, the JF and the core developers have to decide how to handle the import.

JF 14 Oct 2013: We would like to discuss the feature with Michael Jansen, who implemented the patch, before deciding on its  integration into the trunk.

JF 6 Jan 2014: We schedule the feature for 4.5. MD5 and plain text imports should still be possible. Michael will provide a detailed specification on this page.

FS: Interesting articles on this topic:
- http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html
- http://www.phpgangsta.de/schoener-hashen-mit-bcrypt

MJ 06 May 2014: @Fabian: My implementation is based on the article of phpgangsta.

JF 6 Aug 2014: We support the current concept of Michael.

• We still reject the exporting of the passwords (import of all encryption types is ok).
• Types in the import are PLAIN, ILIAS3 (=MD5), MD5, and BCRYPT.
• The setup should not allow to enter or display the global salt. It should just offer a "generate" button, if no salt exists.
• The global salt should be stored in a file in the external data directory.

JF 28 Aug 2014: The setting in the setup should mention flaws of older PHP bcrypt implementations (<5.3.7).

MJ 2 Sept 2014: Implemented

5 Implementation

5.1 Prototype/Draft

• A global key has to be set in the client.ini.php which was used to generate a hash during the encryption process. This key must not be changed after set once!
• To encrypt a password, the developer has to call ilBcrypt::encode($hashpart, $string). The clear text password, the global key and a user related hashpart (a user attribute which must not be changed under any circumstances, e.g. the registration date) were used to generate a hash representation. Afterwards, a random salt was generated. Both mentioned components will be encrypted with a blowfish algorithm.
• This storage method can be currently activated by adding a special setting in the client.ini.php. If a users' password is still stored as a MD5 representation, it will be migrated after the next successful login. This can be done because we can retrieve the clear text password at this time from the global $_POST array.
• To detect whether a password is already migrated or not, ilBcrypt::isBcryptString($string) can be used.
• ilBcrypt::check($hashpart, $string, $stored) can be called to verify a password.
• We changed all (we hope so) relevant source code where passwords are saved/changed, e.g. "Personal Profile" and the "User Administration".
• In regards to quality, it is worth mentioning, that the code is covered with unit tests (only 10, but better than none).

The list above is not valid for the current implementation for 4.5.x. It was only a first implementation/draft.

5.2 Core Integration

Feature SVN branch: http://svn.ilias.de/svn/ilias/branches/databay/mjansen/secure_password_storage/

5.3 Testing

5.3.1 Test Documentation (PHPUnit)

ilMd5PasswordEncoder

• Instance can be created
• Password should be correctly encoded
• Password can be verified
• Exception is raised if the password exceeds the supported length on encoding
• Password verification should fail if the raw password exceeds the supported length
• Name should be md 5

• Instance can be created
• Costs can be retrieved when costs are set
• Costs cannot be set above range
• Costs cannot be set below range
• Costs can be set in range
• Password should be correctly encoded and verified
• Exception is raised if the password exceeds the supported length on encoding
• Password verification should fail if the raw password exceeds the supported length
• Exception is raised if salt is missing is on encoding
• Exception is raised if salt is missing is on verification
• Exception is raised if a generated client salt could not be stored on encoder selection
• Client salt is generated and stored on encoder selection
• Instance can be created and initialized with client salt
• Backward compatibility can be retrieved when backward compatibility is set
• Backward compatibility
• Exception is raised if the raw password contains a 8 bit character and backward compatibility is enabled
• Exception is not raised if the raw password contains a 8 bit character and backward compatibility is enabled with ignored security flaw
• Name should be bcrypt

• Exception is raised if password manager is created without encoder information
• Exception is raised if password manager is created without factory
• Exception is raised if password manager is created without valid factory
• Instance can be created
• Password manager encodes raw password with salt
• Password manager encodes raw password without salt
• Password manager verifies password
• Password manager migrates password on verification with variant encoders
• Password manager never migrates password on failed verification with variant encoders
• Factory can be created
• Getters of factory should return what was set by setters
• Factory raises an exception if an unsupported encoder was injected
• Exception is raised if an unsupported encoder is requested from factory
• Factory raises an exception if an unsupported encoder is requested and no default encoder was specified in fallback mode
• Factory raises an exception if an unsupported encoder is requested and the default encoder does not match one of the supported encoders in fallback mode
• Factory returns the default encoder if an unsupported encoder is requested and a supported default encoder was specified in fallback mode
• Factory returns correct encoder if a matching encoder was found