Fossil SCM
Removed a no-longer-correct doc passage which referenced the older practice of using an IP component in the login cookie.
Commit
1dc5e1ce6da482c7abda63f21830a137f58aff5565417cce107eb07205913194
Parent
67e8599874c2401…
1 file changed
-14
-14
| --- www/password.wiki | ||
| +++ www/password.wiki | ||
| @@ -77,24 +77,10 @@ | ||
| 77 | 77 | The USER.CEXPIRE field holds an expiration date |
| 78 | 78 | for the cookie, encoded as a Julian day number. On all subsequent |
| 79 | 79 | HTTP requests, the cookie value is matched against the USER table to |
| 80 | 80 | enable access to the repository. |
| 81 | 81 | |
| 82 | -A login cookie will only work if the IP address matches. This feature | |
| 83 | -is designed to make it more difficult for an attacker to sniff the cookie | |
| 84 | -and take over the connection. A cookie-sniffing attack will only work | |
| 85 | -if the attacker is able to send and receive from the same IP address as | |
| 86 | -the original login. However, we found that doing an exact IP match | |
| 87 | -caused problems for some users who are behind proxy firewalls where the proxy | |
| 88 | -might use a different IP address for each query. To work around this | |
| 89 | -problem, newer versions of fossil only check the first 16 bits of the | |
| 90 | -32-bit IP address. This makes a cookie sniffing attack easier since now | |
| 91 | -the attacker only has to send and receive from any IP address in a range | |
| 92 | -of IPs that are similar to the initial login. But that is seen as an | |
| 93 | -acceptable compromise in exchange for ease of use. If higher security | |
| 94 | -is really needed, then HTTPS can be used instead of HTTP. | |
| 95 | - | |
| 96 | 82 | Note that in order to log into a Fossil server, it is necessary to |
| 97 | 83 | write information into the repository database. Hence, login is not |
| 98 | 84 | possible on a Fossil repository with a read-only database file. |
| 99 | 85 | |
| 100 | 86 | The user password is sent over the wire as cleartext on the initial |
| 101 | 87 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -77,24 +77,10 @@ | |
| 77 | The USER.CEXPIRE field holds an expiration date |
| 78 | for the cookie, encoded as a Julian day number. On all subsequent |
| 79 | HTTP requests, the cookie value is matched against the USER table to |
| 80 | enable access to the repository. |
| 81 | |
| 82 | A login cookie will only work if the IP address matches. This feature |
| 83 | is designed to make it more difficult for an attacker to sniff the cookie |
| 84 | and take over the connection. A cookie-sniffing attack will only work |
| 85 | if the attacker is able to send and receive from the same IP address as |
| 86 | the original login. However, we found that doing an exact IP match |
| 87 | caused problems for some users who are behind proxy firewalls where the proxy |
| 88 | might use a different IP address for each query. To work around this |
| 89 | problem, newer versions of fossil only check the first 16 bits of the |
| 90 | 32-bit IP address. This makes a cookie sniffing attack easier since now |
| 91 | the attacker only has to send and receive from any IP address in a range |
| 92 | of IPs that are similar to the initial login. But that is seen as an |
| 93 | acceptable compromise in exchange for ease of use. If higher security |
| 94 | is really needed, then HTTPS can be used instead of HTTP. |
| 95 | |
| 96 | Note that in order to log into a Fossil server, it is necessary to |
| 97 | write information into the repository database. Hence, login is not |
| 98 | possible on a Fossil repository with a read-only database file. |
| 99 | |
| 100 | The user password is sent over the wire as cleartext on the initial |
| 101 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -77,24 +77,10 @@ | |
| 77 | The USER.CEXPIRE field holds an expiration date |
| 78 | for the cookie, encoded as a Julian day number. On all subsequent |
| 79 | HTTP requests, the cookie value is matched against the USER table to |
| 80 | enable access to the repository. |
| 81 | |
| 82 | Note that in order to log into a Fossil server, it is necessary to |
| 83 | write information into the repository database. Hence, login is not |
| 84 | possible on a Fossil repository with a read-only database file. |
| 85 | |
| 86 | The user password is sent over the wire as cleartext on the initial |
| 87 |