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)

Added by Stephan Eckardt at 2011-04-08 04:37 pm. Updated at 2011-05-26 11:35 am.

Status:Ready for review Start date:2011-04-08
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:User accounts
Target version:-
Remote issue URL:http://www.redmine.org/issues/7410 Affected version:

Description

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 issues

related to Feature #288: Review latest Redmine commits Closed 2011-03-18 2011-04-08

History

#1
Updated by Eric Davis at 2011-04-08 10:26 pm

I think I have some of r4936 in my upstream merge plan (#288).

#2
Updated by Stephan Eckardt at 2011-04-09 04:23 pm

Are there any plans to use SHA2 instead of SHA1 as SHA1 is so insecure?

#3
Updated by Eric Davis at 2011-04-16 11:50 pm

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.

#4
Updated by Eric Thomas at 2011-04-18 01:55 pm

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.

#5
Updated by Eric Thomas at 2011-04-18 02:23 pm

Also, bcrypt does it's own salting so that should make things less complicated.

#6
Updated by Ammler _ at 2011-05-26 11:35 am

just be sure to have a solution which works cross over other applications like hgredmine (python)

Also available in: Atom PDF