I am attaching a patch to start discussion on some alterations to the login cookie structure that we have been using a for while successfully at Red Hat. Basically what the patch enables is: 1. Combines Bugzilla_login and Bugzilla_logincookie into single cookie containing userid, token, and mac signature. 2. Add mac_secret parameter that can be used to contain a site specific secret key that is used to create a hash based on the secret, the userid, and the unique token. 3. When the cookie is verified, the userid, token, and mac signature is obtained from the cookie and verified with the site secret that the cookie has not been tampered with. 4. Then the token and userid are compared against the database same as before. Also something that is not currently in the patch but would also like to suggest is the possibility of issuing new tokens for each successful page load. So basically what would happen is: 1. A user logs in with a username/password pair in the beginning. 2. The user is issued a token embedded in the cookie and the token is stored in the logincookies table. 3. The next page load, the token is pulled from the users cookie and compared to the one in the database. 4. If the token matches, then the user is considered authenticated, a new token is generated from scratch, and restored in the user cookie. The logincookies table row matching the old token/userid is updated with the new token value. 5. If the token does not match then the user is invalidated and required to login same as before. The benefits to this new feature that is if in the rare case the cookie is compromised somehow, the token will work for the offender until the rightful owner loads another page successfully at which time a new token will be offered. The offenders stolen cookie will no longer be valid and will not work. Please let me know what you think about the patch as well as the additional feature discussed. Thanks Dave
Created attachment 298771 [details] [diff] [review] Patch to combine login cookies to single cookie and add signature support
I don't think we need this level of security. login cookies are already generated randomly, are per IP (IIRC) and bug 320726 already lets you invalidate other sessions in case you suspect your cookies to be stolen or forgot to close your session on another computer. I'm not a fan of all this traffic in the logincookies table.
We have decided to not implement this with the 3.2 roll out as we are now using X_FORWARDED_FOR successfully and decided to keep the auth code as close to upstream as possible. Closing. Dave
Wrong radio button. Really closing this time.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.