What did you do to cause this? nothing
What page were you on? The one with the SQL injection on it. (ticket #242)
Describe the defect: I was looking into the source code, where I noticed, that password hashes stored in database are not salted. If you use SQL injection (such as #242), you can SELECT all users and their details (including hash). Then you run the hashes through Rainbow Tables, and you'we got plaintext passwords, paired with user names and e-mails. Now you have pretty good identification of the user (email and his widely used nickname) along with one of his passwords. You can then start to look for other services (such us gmail, facebook, ...), where the user can be with the same credentials. None of this would happen, if the password hashes have been salted.
I have to agree that passwords need to be salted. To say that salting passwords "really doesn't do much" seems dubious... there is a well accepted standard out there for storing password hashes in a database. I would not like for traq to come under fire for not properly storing password hashes. Companies have already recently gotten plenty of negative attention... see the recent linkedin breach, eHarmony, last.fm, etc...
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet http://crackstation.net/hashing-security.htm
I've decided that Traq 3.0 will not be supporting PHP 5.2 at all, it's holding development back quite a lot. Instead 5.3 will be the minimum version and passwords will be handled with the crypt() function using Blowfish.
Passwords are now secured with Blowfish using the crypt() function. However this does not require everyone to reset their passwords as compatibility has been added for the old style passwords that used SHA1.
Salting passwords really doesn't do much compared to
crypt(). But I can't do exactly what I want to do with PHP 5.2, which is why 3.0 will be the last version of Traq to support is, all versions starting with 3.1 will be PHP 5.3+ only.