Issues

We do not recommend that you setup new ChiliProject instances and
we urge all existing users to migrate their data to a maintained
system, e.g. Redmine. We will
provide a migration script later. In the meantime, you can use the
instructions by
Christian Daehn.

Hashed passwords without a salt are a security risk. Redmine has a patch for it in r4936. I applied this patch to ChiliProject and changed their scheme for hashing passwords. In Redmine hashed passwords are saved as SHA1(salt+SHA1(cleartext_password)) to allow migrating the hashed passwords in one single migration. I found it a cleaner scheme to save passwords as SHA256(salt+cleartext_password). Nevertheless the code works with old unsalted passwords and also with Redmine's scheme. The salting occurs when the user successfully logs in. Also the used hashing algorithm is saved in the database to allow using stronger algorithms in the future when SHA256 is not considered secure enough anymore.

Stephan, rather than implementing SHA scheme, have you considering looking into bcrypt? The latest version of rails has it built in and the sound advice of many people nowadays is to use bcrypt over other hash algorithms. The major difference with bcrypt is that it's slow and that is exactly the kind of quality one wants to prevent brute-forcing a password.

I think this sums it up quite nicely:

Why is bcrypt such a huge win? Think of the problem from two perspectives: the server, and the attacker.
First, the server: you get tens of thousands of logins per hour, or tens per second. Compared to the database hits and page refreshes and IO, the password check is negligable. You donâ€™t care if password tests take twice as long, or even ten times as long, because password hashes arenâ€™t in the 80/20 hot spot.
Now the attacker. This is easy. The attacker cares a lot if password tests take twice as long. If one password test takes twice as long, the total password cracking time takes twice as long.