Bug 23362

First, the index.cgi screen does not do any strict authorization checking and
only looks to see if there is a cookie 'Bugzilla_login' set to obtain a username
from. I should take out the who Login part since this can be misleading at
times. 

Second I know I have suggested this time and time again but could you try moving
your .netscape/cookies file out of the way and re-trying. If this solves the
problem for you then just edit your .netscape/cookies file to remove all lines
containing 'Bugzilla_login' and Bugzilla_logincookie' and move the file back in
place. Bugzilla now does authentification off of the persons IP address as well
so sometimes old cookies can cause problems. Let me know if this works.

I know the reason now:

My HTTP-proxy has changed and the new one is doing load-balancing. So the IP
where I am coming from changes and the auth-token becomes invalid.

Because that's an usual configuration I am in doubt about the applicableness of
IP-based authentification with HTTP. Perhaps you can add any IP a valid
authentication came from to a list?


If you really want to keep the old way, can you please prefill the
username-field of the login-formular with the value of the
"Bugzilla_login"-cookie? That would save some time...

Would authentification based on hostname using reverse host lookup work better
for this type of situation? I could enable it if so.

No, the hostnames are different also. E.g. I can come from 
howe.hrz.tu-chemnitz.de, anderson.hrz.tu-chemnitz.de or
squire.hrz.tu-chemnitz.de. 

I can modify my configuration to use only one of them for my RH visits, but
other people are probably affected also.

The problem is is that bugzilla keys off of the cookie number associated with
Bugzilla_logincookie and also the ip/hostname of the client. So different ip's
would have different cookie numbers also which would mean to allow multiple
hosts access with the same  cookie number would be a major change to the way
Bugzilla currently handles authentification. The Bugzilla community as well as
myself are looking into other means of authentification for future releases of
Bugzilla. 

As for the part about affecting a wide range of people, I think you and maybe
one or two others have ever reported thisproblem but they just may not notice it
is happening.

The current authentication mechanism of Bugzilla is completely unsecure. It
seems `Bugzilla_logincookie' is a 16bit value only. Everybody who come from an
IP (proxy) where I have done my last login, can gain with a simple brute-force
attack my identity. 

At my (small) university some thousand people (a lot of them with the needed
knowledge about attacks) can use the proxy I am using also. Think of big
providers which are having ten- or hundredthousand users!

Again, I think that techniques which are using some kind of IP based
authentication are not working with HTTP. So Bugzilla needs a redesign.

The logincookie number is not really a 16bit number per say. It is a
continuously incrementing number to 38 bits of precision. This is only limited
by the integer data type used in the database field. When someone logs in, they
get whatever the next sequence number is from a number pool. For the number to
get saved to the Bugzilla_logincookie you also have to provide a valid password.
If not then the number is never used again anyway. Also Bugzilla now can use SSL
if people are worried about sniffing of passwords and logincookie numbers.

Ok, when I wrote my last report the number looked like 16bit and now I am seeing
it is really >2^16. But the used method is more worse then choosing a random
16bit number. E.g. the following attack would be possible:

1. I log into bugzilla in; bugzilla gives now enrico.scholz@inf... from
squire.hrz.tu-chemnitz.de (proxy by thousands of people) with authtoken X access

2. An attacker at my univerity knows that the current token-number is Y (can be
detected easily) and that I have done step #1. Now he sends the cookie-pair
[Bugzilla_login=enrico.scho..., Bugzilla_logincookie=Y-z] to bugzilla where `z'
is a small random number and `enrico.scho...' my public email-address. Bugzilla
sees that this connection comes from squire.hrz... and grants access if Y-z==X.

Because of the simple calculation of the authtoken, the last condition Y-z==X
can be true with a high propability. I don't know if bugzilla makes authtoken
invalid if a bad [email,login-cookie,ip]-tripel was provided. If not bugzilla is
highly insecure (a guess you will need only to choose `z' <20 to cover the last
day).


As seen above the IP or hostname does not enhance the security significantly.
Better use random auth-tokens from a 2^128 range in combination with the email.

To add my 2 cents: I too have this problem.  In my situation I am behind a 
firewall that round-robins (using squid) between my ISP's 4 web proxy servers.  
My login information is always lost of only shows up every 4 hits :-(

I think this type of situation will become more common as people get behind 
firewalls and realize they can increase their web speeds by round-robining 
between multiple servers.

Bugzilla should just use username/password for authentication like most other 
sites out there, with exceptions for RH employees as their the only ones who 
really need the security of an IP check anyways.