| | 1 | = Trac Security Overview = |
| | 2 | |
| | 3 | This is just a quick'n'dirty document to help users make informed decisions about the Trac. |
| | 4 | |
| | 5 | |
| | 6 | == Recommendations == |
| | 7 | |
| | 8 | * Don't use a password which you use elsewhere. (See: Twitter incident) [FIXME: Find ref.] |
| | 9 | * Don't expect the ticket database to be non-corrupt or reliable or persistent. |
| | 10 | * Backup the ticket database and wiki pages regularly! Use snapshots so corruption does not overwrite correct data. |
| | 11 | |
| | 12 | |
| | 13 | == Vulnerabilities == |
| | 14 | |
| | 15 | * HTTP without SSL means a passive attacker can see all your traffic (except password on login, see below). |
| | 16 | * HTTP without SSL means an active attacker can do anything at all with your account privileges. |
| | 17 | * Password reset over HTTP means the attacker knows your password with minimal effort. |
| | 18 | * HTTP Auth uses Digest mechanism, which means (if implemented correctly): |
| | 19 | * Attacker cannot learn your password during a login request. |
| | 20 | * The database must store your plaintext password (in order to compute the correct digest). [FIXME: verify.] |
| | 21 | * Anyone with file system read access to the machine also has all passwords. |
| | 22 | |
| | 23 | |
| | 24 | == To Do == |
| | 25 | |
| | 26 | * Search for existing Trac security references. |
| | 27 | * Verify that plaintext passwords are stored. |
| | 28 | * Find Twitter incident ref (the short story is that there were no technical security flaws, but users used the same creds on an "unimportant" service as well as a different critical service, so the attacker could escalate the attack across services.) |
