I guess what Jonathan was asking about was the following scenario: 1) Hacker gets credentials from SQL injection 2) Hacker logs in, gets cookie 3) Project detects issue, resets all passwords to prevent hacker from logging in 4) Hacker logs in using cookie or contents of cookie
It is an interesting question really. I seem to recall that originally the cookies were based on (or directly contained?) the strong user authenticator. Since this key is also present on the user account page it doesn't give the attacker any more powers in and by itself, but since the authenticator allows the attacker to log in it should probably also have been reset in step 3 (which in turn would invalidate both the cookies and any hosts signed on to the project). -- Janus On 2011-10-25 21:15, Carl Christensen wrote: > boinc pages set an "auth cookie"on the client/browser side - so people don't > have to login every time they visit. it is just a string (authenticator) in > a local file on their client web browser, i.e. cached in Internet Explorer, > Safari, etc. So it is safe, i.e. a hacker would have to be on their local > computer or get access to their local cache file to find the authenticator > string etc (and if they could do that then the person is royally screwed > anyway ;-) > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
