Password hashing/encryption in database

[Olaf Kock, modifié il y a 14 années.]

Foreword:
I've just locked myself out of a new playground installation by creating a new administrative user, not providing a password (and no working mail setup), then immediately remove the Administrator role from [e-mail]. This immediately locked me out of the system with no knowledge of any password (not that bad, as the extra user was the only data I've keyed in).

The issue:
In the process of recovering from this I've seen, that I can just copy the hashed password from [e-mail] (the hashed equivalent of "test") and get in with my new user and the password "test".

This shows, that the password seems to be "unsalted" before written in the database - e.g. it's breakable by a simple lookup table.

I believe it to be best practice to salt passwords, e.g. with the users screen name, mail address and maybe an installation-local random value. The first (salting with user data) would prevent admins to easily detect when two people share the same password (which then has a good chance to be dead simple). The suggestion (additional random salt) would add further complexity, so that rainbow table attacks are unfeasible.

I guess that the last scenario is not really a common one, but should be thought of if something along these lines should be realized. The first one (admins recognizing familiar values) is certainly an issue.

There are two issues with this approach:

• Migration most likely needs cleartext password, as it re-hashes the password (but could also hash twice, e.g. hash the unsalted password, add salt, hash again)
• users changing the information that is used as salt would invalidate their password

Should this be filed as bug? Or is the solution for proper password handling to delegate to LDAP?

[Artur Korol, modifié il y a 14 années.]

If You assume database is secure - salted passwords are not needed. You can even use plain text.

To have salted password as an option would be good thing - it should be implemented sooner or later.

Obviously, this depends on requirements - sometimes SHA or MD5 makes things easier eg. if we want to share user accounts and passwords with other system which uses SHA or MD5. In my case - I wanted to integrate Liferay and Openfire and authenticate users againts Liferay user table. Openfire uses MD5, so this is possible.

On the other hand - You may require that even admin could not decrypt user passwords.

As always there is trade-off between security and usability. Regarding LDAP, possibility to NOT store passwords in Liferay tables should be implemented as well (now I think is not possible without reprogramming).

Artur