ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
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.
Salted user passwords (Feature #323)
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.
|related to Feature #288: Review latest Redmine commits||Closed||2011-03-18||2011-04-08|
Stephan Eckardt wrote:
Are there any plans to use SHA2 instead of SHA1 as SHA1 is so insecure?
I don't have any plans. Is there an easy way to upgrade to SHA2?
I've also just merged in the salted passwords from Redmine into unstable (9964c43) so if you want to rebase your patches we can review the differences.
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.