On Jan 9, 2010, at 11:04 AM, Ron Aaron wrote:

> I didn't see an option, perhaps it's not even on the list of  
> requests... but
> when I look at the 'user' table, the user's password is stored in  
> cleartext.
>
> Having my fossil file on a shared server, this makes me a bit  
> nervous.  Anyone
> who has access to that file can read all the user passwords.
>
> It would be trivial to change the password stored to sha1(login 
> +pw).  In that
> case it would also be difficult to hack, since different users with  
> the same
> password would have wildly different values saved in the user table.


OK.  Beginning with http://www.fossil-scm.org/fossil/ci/cfe33dcf92  
Fossil will store passwords on servers as either cleartext or as a  
SHA1 hash of the password.  It tells the difference by looking at the  
length of the password.  A password in the USER table that is exactly  
40 characters long is assumed to be a SHA1 hash.  Otherwise, the  
password is assumed to be cleartext.

Whenever you change a password, the new password is stored as the SHA1  
hash.   When you create new users, the password is stored as the SHA1  
hash.  There is no mechanism to force the password to be cleartext.   
You can force all cleartext passwords to become SHA1 hashes using this  
command:

     fossil test-hash-password REPOSITORY

Converting from cleartext to SHA1 hash is irreversible, of course.

The client always uses the SHA1 hash as the shared secret, unless the  
password for a sync operation begins with '*'.  If the password for a  
sync begins with '*', then the characters after the '*' are taken to  
be the cleartext password used as the shared secret.  This allows  
newer clients to communicate with legacy servers that do not know  
about the password format change.  If  you have a new fossil client  
and you want to sync against a legacy server, do it this way:

      fossil sync http://userid:*passw...@legacy-server.com/

The new server accepts both the cleartext passwords and the SHA1 has  
as the shared secret, assuming the cleartext is stored in the USER  
table.  That means that newer servers will work with older clients as  
long as you do not update the USER table to store hashes.  Once a hash  
is stored in the USER table, the sync protocol will only work with  
newer clients.

So, older clients will work with newer servers as long as cleartext  
passwords are stored in the USER table, and older servers will work  
with newer clients by adding '*' before the password in the URL.

The simplest upgrade path is probably just to upgrade all clients and  
servers all at once.

The second simplest upgrade path is:

(1) Upgrade servers, but do not modify the USER table.
(2) Start upgrading clients.
(3) After all clients are upgraded, run [fossil test-hash-password] to  
convert the USER table to use hashes instead of cleartext.

I have not yet done step (1) on  the server that runs www.fossil- 
scm.org.  I'll do that after additional testing and after you, gentle  
readers, have reviewed my changes and informed me that my changes are  
free of new security boo-boos.  I eagerly await the results of your  
review.  Tnx.

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

Reply via email to