Tuesday, July 10, 2012
Liferay Portal: Passwords (Part Five)
This is part five of a seven part analysis of Liferay Portal and its security model. I previously covered authentication, authorization, services and automation. Today, I will focus on the problem space of how Liferay handles passwords...
User Passwords
If you haven't been asleep over the last few months, you may have heard about the scenario of many users of LinkedIn having their passwords compromised. The anatomy of the vulnerability had to do with how LinkedIn stored passwords where the algorithm used to hash them was discovered along with the salt value.
Liferay too is vulnerability to the same thing occurring in that there is no administrative process that mandates every unique installation of Liferay either have a unique salt or even requests having one at all. Think about it for a moment, while I can't simply download a copy of LinkedIn and run it on my laptop, I can download a copy of Liferay Portal and generate many of the same passwords as some other user of Liferay.
System Passwords
It is a security best practice to make sure that user passwords are hashed using a one-way algorithm and not stored in a manner that is either cleartext or uses a form of reversible encryption. This however is not always possible for passwords that are used by systems. For example, if you want Liferay to bind to say Active Directory then the password needs to be stored in a reversible form.
Liferay currently stores many passwords in the liferay.properties file in a cleartext manner. This of course would be deemed as non-compliance for applications that need to comply with PCI/DSS. A better way would be for Liferay to create a utility that allows a user to change all passwords to an encyrpted form where the key used to encrypt/decrypt is passed in as a command-line parameter. Of course, someone may also decide to put the password in a command file that starts Liferay, but this at least doesn't make it Liferay's specific problem.
Alternatively, it is a best practice to store keys in a keystore. Java provides a keystore implementation which is callable via Liferay. For Liferay deployments that run on Microsoft Windows, you can also externalize keys to the Windows Keystore as an alternative pluggable/configurable implementation...
| | View blog reactionsUser Passwords
If you haven't been asleep over the last few months, you may have heard about the scenario of many users of LinkedIn having their passwords compromised. The anatomy of the vulnerability had to do with how LinkedIn stored passwords where the algorithm used to hash them was discovered along with the salt value.
Liferay too is vulnerability to the same thing occurring in that there is no administrative process that mandates every unique installation of Liferay either have a unique salt or even requests having one at all. Think about it for a moment, while I can't simply download a copy of LinkedIn and run it on my laptop, I can download a copy of Liferay Portal and generate many of the same passwords as some other user of Liferay.
System Passwords
It is a security best practice to make sure that user passwords are hashed using a one-way algorithm and not stored in a manner that is either cleartext or uses a form of reversible encryption. This however is not always possible for passwords that are used by systems. For example, if you want Liferay to bind to say Active Directory then the password needs to be stored in a reversible form.
Liferay currently stores many passwords in the liferay.properties file in a cleartext manner. This of course would be deemed as non-compliance for applications that need to comply with PCI/DSS. A better way would be for Liferay to create a utility that allows a user to change all passwords to an encyrpted form where the key used to encrypt/decrypt is passed in as a command-line parameter. Of course, someone may also decide to put the password in a command file that starts Liferay, but this at least doesn't make it Liferay's specific problem.
Alternatively, it is a best practice to store keys in a keystore. Java provides a keystore implementation which is callable via Liferay. For Liferay deployments that run on Microsoft Windows, you can also externalize keys to the Windows Keystore as an alternative pluggable/configurable implementation...
