As a system administrator I can make Liferay use strong encryption for passwords stored in the db

Portal default configuration use SHA-1 to protect passwords stored in the DB. This configuration is insecure.

Secure password storage should:
1, salt passwords
2, use a compute intensive algorithm

For more info on the topic please see https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet.

Goals of the story

1, Change default configuration to a safe one
2, Deprecate weak algorithms
3, Provide support for PBKDF2 algorithm
4, Provide support for changing 'work load' factor for the compute intensive algorithms
5, Provide a migration path for existing deployments

Overview

The current most widely used compute intensive algorithms are BCrypt, PBKDF2 and SCrypt. Alghough SCrypt seems to be the most safe one (employs both space and time complexity), it's not yet proven to be.

The supported algorithms are

• BCrypt
• PBKDF2, which is the default one, because it's more sensitive to performance tuning.

The upgrade process takes into account existing configuration, the new stronger encrypted password is saved into DB only when an user changes the password.

When migrating an old database into 6.2 release:

• presuming oldAlgorithm to be the one used in the old database (SHA by default)
• set: passwords.encryption.algorithm=oldAlgorithm, to keep using the old algorithm for new password hashes
• set: passwords.encryption.algorithm.legacy=oldAlgorithm, to use the new strong algorithm for new hashes

Notes

Performance tuning

Compute intensive algorithms slow down all processes that use password encryption.

These processes are:
1, Login process
2, Change password
3, Import of users from LDAP

To tune the performance, it's recommended to adjust 'work load' factor of the algorithms. This can be done using a configuration of "rounds" taken to encrypt the password:
1, For BCrypt use BCrypt/rounds, e.g. BCrypt/12
2, For PBKDF2 use PBKDF2WithHmacSHA1/key-size/rounds or simply PBKDF2WithHmacSHA1/rounds, e.g. PBKDF2WithHmacSHA1/96000

Hint for adjusting the right value: http://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pkbdf2-sha256/3993#3993

Note on possibility of DDoS attack

Compute intesive login process is a good entry point for DDoS attack.

Deployments with a high risk of the attack should customize the default implementation to:

• decentralize the encryption process using more HW
• implement security controls to avoid overloading of the process

Local salt (also known as a pepper) password enhancement

Implementation of the local salt is not part of this story.

Customers interested in increasing security level may customize the default implementation.