Bug 406231 - 3.13: Login system enhancements
3.13: Login system enhancements
Status: CLOSED WONTFIX
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
devel
All Linux
high Severity medium (vote)
: ---
: ---
Assigned To: David Lawrence
https://bugzilla.mozilla.org/show_bug...
12 hours
:
Depends On: 429495
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-30 11:58 EST by David Lawrence
Modified: 2013-06-24 00:16 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-23 17:22:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to add series key based login to 3.x Bugzilla code (16.41 KB, patch)
2008-01-22 00:00 EST, David Lawrence
no flags Details | Diff
Pacth to add signing support to bugzilla login cookie (7.57 KB, patch)
2008-01-23 16:01 EST, David Lawrence
no flags Details | Diff

  None (edit)
Description David Lawrence 2007-11-30 11:58:19 EST
Description:
The login system has been enhanced to use more secure cookies in order to prevent possible tampering and security issues. Since the new server environment no longer allowed using IP addresses as a way to enforce logins, session cookies were added that allow a more secure method for validating a user's login.

Function Requirements:
Bugzilla/Auth.pm Bugzilla/Auth/CGI.pm Bugzilla/Auth/Cookie.pm
Comment 1 David Lawrence 2007-12-21 14:10:38 EST
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
Comment 2 David Lawrence 2007-12-21 17:26:52 EST
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

Comment 3 Kevin Baker 2007-12-31 17:18:22 EST
Risking repeating myself, but this *must* get upstream. We don't want to be 
supporting this alone.
Comment 4 David Lawrence 2008-01-22 00:00:29 EST
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.
Comment 5 David Lawrence 2008-01-22 00:02:08 EST
Will submit this patch upstream for review asap and attach the link here.
Comment 6 David Lawrence 2008-01-23 15:59:59 EST
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
Comment 7 David Lawrence 2008-01-23 16:01:11 EST
Created attachment 292694 [details]
Pacth to add signing support to bugzilla login cookie
Comment 8 David Lawrence 2008-01-23 16:22:39 EST
Submitted bug report upstream to discuss this new patch.

https://bugzilla.mozilla.org/show_bug.cgi?id=413722
Comment 9 David Lawrence 2008-01-23 17:45:55 EST
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. 
Comment 10 Kevin Baker 2008-01-25 09:29:09 EST
> 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.
Comment 11 David Lawrence 2008-04-14 00:06:34 EDT
Removing from 3.2 blocker for now. Maybe revisit this post 3.2 work.
Comment 12 David Lawrence 2009-04-23 17:22:41 EDT
We are no longer interested in this change. Closing.

Note You need to log in before you can comment on or make changes to this bug.