Bug 406231

LOC Estimation:

Inputs: UI form (direct), browser cookies, XMLRPC methods (cookies), XMLRPC
methods (direct) = 4
Outputs: Screen, XMLRPC response = 2
Inquiries: 1 (looks up a entry in logincookies based on key given)
Logical internal files: logincookies = 1
External interface files: data/params = 1

FP (total count) = (4*4)+(5*2)+(4*1)+(10*1)+(7*1)
                    16 + 10 + 4 + 10 + 7 = 47

FP = 47 * 1.11 = 52

288 Bugzilla/Auth.pm
190 Bugzilla/Auth/CGI.pm
444 Bugzilla/Auth/Cookie.pm
130 Bugzilla/Auth/DB.pm
172 Bugzilla/Auth/RPC.pm
1224 total

LOC (for Auth modules) = 52 * 1224 = 63648

Selenium tests to verify proper operation of auth in UI and XMLRPC: 12 hours

LOC Estimation:

Inputs: UI form (direct), browser cookies, XMLRPC methods (cookies), XMLRPC
methods (direct) = 4
Outputs: Screen, XMLRPC response = 2
Inquiries: 1 (looks up a entry in logincookies based on key given)
Logical internal files: logincookies = 1
External interface files: data/params = 1

FP (total count) = (4*4)+(5*2)+(4*1)+(10*1)+(7*1)
                    16 + 10 + 4 + 10 + 7 = 47

FP = 47 * 1.11 = 52

LOC = 52 * 60 = 3120

Selenium tests to verify proper operation of auth in UI and XMLRPC: 12 hours

Risking repeating myself, but this *must* get upstream. We don't want to be 
supporting this alone.

Created attachment 292459 [details]
Patch to add series key based login to 3.x Bugzilla code

Attaching patch needed to add series based cookie support to 3.x login code to 

match what we are doing in 2.18. One thing to note is logging support is
missing
as it is dependent on the Log4perl patch to be applied later. Also added
mac_secret param for allowing a custom mac_secret to be configured in the admin
interface.

Will submit this patch upstream for review asap and attach the link here.

Attaching new patch which does not do series cookies.

1. combines the Bugzilla_login and Bugzilla_logincookie into single
Bugzilla_login cookie.
2. Uses Digest::SHA1 to sign the key by hashing the userid, token and a mac
secret  and includes the resulting hash in the Bugzilla_login cookie

Created attachment 292694 [details]
Pacth to add signing support to bugzilla login cookie

Submitted bug report upstream to discuss this new patch.

https://bugzilla.mozilla.org/show_bug.cgi?id=413722

http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice

Parts form the comments:

Hi,

Isn't there still a problem with having a new randomly choosen cookie as an id?
- when the customer arrives onto the site, the previous cookie is invalidate and
the new one is created.
- And as long as the customer goes onto the site it sends the newer cookie with
the new key.
Someone can sniff the network to catch one good new key.

Am I missing something?
Posted by: Gabriel Kastenbaum at February 7, 2004 12:37 AM (#link)

@Gabriel:

If user A (legitimately) enters your site, (s)he gets a new token. Should user B
(maliciously) want to enter the site he could sniff for the cookie (and thus the
token). He then has to use that token before user A enters (another page on) the
site again. Suppose he succeeds - then user A will be logged out upon the next
visit. He has to log in again (using the password) and thus creates a new string
of one-time-tokens. User B can continue to impersonate A until the cookie expires.
Posted by: Frank at May 8, 2004 05:49 AM (#link)

So in summary, Frank is saying that if UserA's token is stolen by UserB and
UserB is somehow able to login again before UserA is able to, UserA is logged
out and UserB's token chain continues to be valid. This would make using one
time use cookies a bad idea in this case.

The only way to do the one time cookies and fix the problem mentioned above
is to purge the database of old cookies when UserB logs in the second time. But
then UserB cannot use multiple clients at any one time as (s)he can now. 

> of one-time-tokens. User B can continue to impersonate A until the cookie 
expires.

So we would need to set a time that the cookie expires and then force the user 
to re-login when the time is hit. IIRC correctly in our bz we set it to set a 
new cookie expires for every connect right? So we could improve our security 
by changing to force a re-login after 3 days. So if a cookies was stolen then 
have at most 3 days before they would be forced to enter a password.

Removing from 3.2 blocker for now. Maybe revisit this post 3.2 work.

We are no longer interested in this change. Closing.