So, I was one of the people asking for passwords to be stored hashed (or if I didn't ask out loud, I certainly agreed). Now as I'm trying to admin a small collection of fossil repos for a small collection of users, a problem comes up.
At this org, we have three projects that I've put into three fossil repos. I thought I would just copy the passwords from one to the others, but I see that the project-code is also hashed into the stored password, so the password wouldn't work if copied to another repo. <Digression> Some people were skeptical of hashing the stored passwords at all, since it wouldn't protect the passwords while traveling over the wire: briefly, the idea was to protect users from anyone who has access to the repo file--in case users used the same password elsewhere, as they often do. </Digression> All things considered, I'd rather have what we now have than plain text storage, but I don't think the current way is quite right either (apologies for explaining things that most probably already know): * The more common way to store hashed passwords is to add a pseudorandom salt to the text to be hashed and store the salt together with the hash (depending on the system there may be a convention for how to join them, but just concat is fine if they're fixed length or pipe-separated or whatever), so that given a plaintext username and password the salt used for the hash can be retrieved and the submitted username, password, and salt can be hashed and compared to the stored hash. * Adding the project code to the hash means a prefab rainbow table cannot be used to crack the passwords in a repo. * But using the same project code on all passwords means that it's easier to build a custom rainbox table to attack at once all passwords stored in a given repo. * The only plausible benefit of using the project code instead of a random salt that I can think of is to make stored passwords non-portable across repos. (With salt and hash stored together, the lot could be copied to a user in another repo with the same name and used.) But for my use case this is a hinderance, not a benefit, and I can't think of any situation in which it would actually help. So for improved utility (for certain uses, anyway) and slightly improved security, the project code in the hash should be replaced with a per-row random salt. -- Joshua Paine LetterBlock LLC http://letterblock.com/ Web applications built with joy. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
