Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Updates to the Password Management document. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | experimental |
Files: | files | file ages | folders |
SHA1: |
1cba86eabbb0dac64852268c740f52d0 |
User & Date: | drh 2010-01-11 16:09:12.000 |
Context
2010-01-11
| ||
16:21 | Additional clarification in the Password Management document. ... (Closed-Leaf check-in: 261e5534 user: drh tags: experimental) | |
16:09 | Updates to the Password Management document. ... (check-in: 1cba86ea user: drh tags: experimental) | |
15:07 | Add the /doc/tip/www/password.wiki document. ... (check-in: cac5675e user: drh tags: experimental) | |
Changes
Changes to www/password.wiki.
1 2 3 4 5 6 7 8 9 10 11 | <title>Fossil Password Management</title> <h1 align="center">Password Management</h1> Fossil handles user authentication using passwords. Passwords are unique to each repository. Passwords are not part of the persistent state of a project. Passwords are not versioned and are not transmitted from one repository to another during a sync. Passwords are local configuration information that can (and usually does) vary from one repository to the next within the same project. Passwords are stored in the PW field of the USER table. | | > | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | <title>Fossil Password Management</title> <h1 align="center">Password Management</h1> Fossil handles user authentication using passwords. Passwords are unique to each repository. Passwords are not part of the persistent state of a project. Passwords are not versioned and are not transmitted from one repository to another during a sync. Passwords are local configuration information that can (and usually does) vary from one repository to the next within the same project. Passwords are stored in the PW field of the USER table. In older versions of Fossil (prior to [/timeline?c=2010-01-10+20:56:30 | 2010-01-11]) the password is stored as cleartext. In newer versions of Fossil, the password can be either cleartext or an SHA1 hash (written as a 40-character lower-case hexadecimal number). If the USER.PW field contains a 40-character string, that string is assumed to be a SHA1 hash. If the size of USER.PW is anything other than 40 characters, then it is understood as a plain-text password. |
︙ | ︙ | |||
28 29 30 31 32 33 34 35 36 37 38 39 40 41 | </blockquote> That hash value is "f1b699cc9af3eeb98e5de244ca7802ae38e77bae". Note that by including the project-code and the login as part of the hash, a different USER.PW value results even if two or more users on the repository select the same "asdfg" password or if user alice reuses the same password on multiple projects. <h2>Web Interface Authtentication</h2> When a user logs into Fossil using the web interface, the login name and password are sent in the clear to the server. The server then hashes the password and compares it against the value stored in USER.PW. If they match, the server sets a cookie on the client to record the | > > > > > > > > > > > > > > > > > > > > | 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 | </blockquote> That hash value is "f1b699cc9af3eeb98e5de244ca7802ae38e77bae". Note that by including the project-code and the login as part of the hash, a different USER.PW value results even if two or more users on the repository select the same "asdfg" password or if user alice reuses the same password on multiple projects. Whenever a password is changed using the web interface or using the "user" command-line method, the new password is stored using the SHA1 encoding. Thus, cleartext passwords will gradually migrate to become SHA1 passwords. All remaining cleartext passwords can be converted to SHA1 passwords using the following command: <blockquote><pre> fossil test-hash-passwords <i>REPOSITORY-NAME</i> </pre></blockquote> Remember that converting from cleartext to SHA1 passwords is an irreversible operation. The only way to insert a new cleartext password into the USER table is to do so manually using SQL commands. For example: <blockquote><pre> UPDATE user SET pw='asdfg' WHERE login='alice'; </pre></blockquote> <h2>Web Interface Authtentication</h2> When a user logs into Fossil using the web interface, the login name and password are sent in the clear to the server. The server then hashes the password and compares it against the value stored in USER.PW. If they match, the server sets a cookie on the client to record the |
︙ | ︙ | |||
88 89 90 91 92 93 94 | Using this approach, the USER.PW value is treated as a shared secret between the client and server. The USER.PW value is never sent over the wire, but the protocol establishes that both client and server know the value of USER.PW. Furthermore, the use of a SHA1 hash over the entire message prevents an attacker from sniffing a valid login from a legitimate users and then replaying the message modified content. | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 | Using this approach, the USER.PW value is treated as a shared secret between the client and server. The USER.PW value is never sent over the wire, but the protocol establishes that both client and server know the value of USER.PW. Furthermore, the use of a SHA1 hash over the entire message prevents an attacker from sniffing a valid login from a legitimate users and then replaying the message modified content. If the USER.PW on the server holds a cleartext password, then the server will also accept a login-card signature that is constructed using either the cleartext password or the SHA1 hash of the password. This means that when USER.PW holds a cleartext password, the login card will work for both older and newer clients. If the USER.PW on the server only holds the SHA1 hash of the password, then only newer clients will be able to authenticate to the server. The client normally gets the login and password from the "remote URL". <blockquote><pre> http://<font color="blue">login:password</font>@servername.org/path </pre></blockquote> For older clients, the password is used for the shared secret as stated in the URL and with no encoding. For newer clients, the shared secret is derived from the password by transformed the password using the SHA1 hash encoding described above. However, if the first character of the password is "*" (ASCII 0x2a) then the "*" is skipped and the rest of the password is used directly as the share secret without the SHA1 encoding. <blockquote><pre> http://<font color="blue">login:*password</font>@servername.org/path </pre></blockquote> This *-before-the-password trick can be used by newer clients to sync against a legacy server that does not understand the new SHA1 password encoding. |