[fossil-users] be careful what you wish for
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
Re: [fossil-users] be careful what you wish for
On Apr 3, 2010, at 12:27 PM, Joshua Paine wrote: * 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. Not so in this case. The stored has is computed as follows: SHA1( project-code + / + login + / + password ) This means that the password hash will always be unique (to an exceedingly high probability) even if the same password is used by two or more users on the same project, or by the same user on different projects. * 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. Another (important) benefit of using the project code instead of random salt is that the client already knows the project code, and hence it does not need to do a preliminary round-trip to the server just to get the salt prior to encoding the users password whenever it does a push or pull. You cannot copy the hashed password between repositories. But Fossil still accepts unhashed passwords in the USER table. If the USER.PW field contains text that is not 40 characters in length, then that text is interpreted as an unhashed password and is hashed at run-time. So if you want to add a user to multiple repositories, you can simply write a script that inserts entries into the USER table of the various repositories with a cleartext password. Or, if you are writing scripts, your script can invoke fossil user password LOGIN PASSWORD --repository REPOSITORY-FILENAME which will cause the password to be inserted hashed instead of cleartext. 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 D. Richard Hipp d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] be careful what you wish for
On 04/03/2010 05:52 PM, D. Richard Hipp wrote: Another (important) benefit of using the project code instead of random salt is that the client already knows the project code, and hence it does not need to do a preliminary round-trip to the server just to get the salt prior to encoding the users password whenever it does a push or pull. D'oh--I forgot that the hash is sent over the wire for authentication as well. Nevermind--I withdraw my argument/request. So if you want to add a user to multiple repositories, you can simply write a script that inserts entries into the USER table of the various repositories with a cleartext password. Or, if you are writing scripts, your script can invoke fossil user password LOGIN PASSWORD --repository REPOSITORY-FILENAME which will cause the password to be inserted hashed instead of cleartext. These don't really solve my problem, as I've only just created the latest project repo. I'll probably add another one or two later on. It would be really nice to be able to copy the users from one project to another in some cases (or have a delegated single source for authentication--maybe the CGI REMOTE_USER variable as someone mentioned recently), but I now agree that my suggestion wouldn't be a good way to achieve it. -- 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
Re: [fossil-users] Fossil GUI for local source tree operations
Mercurial has a whole subsystem (mq) to manage unpublished patches. Git implements 'rebase', and allows you to move unpublished commits forward. This is dangerous and we have faced issues when we used commit ids from a git repository managed by another team. After few months, the commit ids we used in our scripts were no longer in the repository and we could not reproduce historical packages (just a couple of months old). I assume fossil will not encourage such features. There is a feature called 'shunning' that can be used for the third use case. - Altu -Original Message- From: Gé Weijers g...@weijers.org To: e...@deptj.eu; fossil-users@lists.fossil-scm.org Sent: Sun, Apr 4, 2010 4:47 am Subject: Re: [fossil-users] Fossil GUI for local source tree operations On Thu, 1 Apr 2010, Eric wrote: And that is the way SCM should be - _no_ opportunity to rewrite history.There are arguments for allowing some editing in history:- 'rebasing' commits allows you to keep a linear flow the the commits in a repo which makes things easier to follow. Mercurial has a whole subsystem (mq) to manage unpublished patches. Git implements 'rebase', and allows you to move unpublished commits forward.- abandoned branches just clutter up the repo, and it would be nice if they would not clutter up the branch name space forever.- some clueless soul can commit copyrighted material to your repo, and when you find out three years later because of a cease-and-desist letter you _need_ to edit history. The FreeBSD project did not go with Mercurial for this exact reason, but stuck to SVN because of previous experience. If that ever happens to the Linux kernel Git tree___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi -bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
