Bug 1410316 - logins don't survive between browser sessions
Summary: logins don't survive between browser sessions
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Bugzilla
Classification: Community
Component: Administration
Version: 5.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: PnT DevOps Devs
QA Contact: tools-bugs
URL:
Whiteboard:
: 1667379 1667830 1676787 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-05 06:16 UTC by Jason McDonald
Modified: 2019-03-04 09:08 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-28 03:42:32 UTC


Attachments (Terms of Use)
login page on bugzilla.mozilla.org (82.24 KB, image/png)
2019-01-23 09:35 UTC, Milan Crha
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1659832 0 unspecified CLOSED Add a cookie to remember authentication choice 2021-02-22 00:41:40 UTC

Description Jason McDonald 2017-01-05 06:16:11 UTC
Description of problem:
It appears that the Bugzilla 5 beta site is configured with the 'rememberlogin' parameter set to 'off', whereas for the current production Bugzilla 4 that parameter is set to 'on'.

This change to long-standing behaviour is likely to annoy many users, and does virtually nothing to enhance security because most users either have their browser remember their username and password or use a yubikey.  Either way, forcing the user login repeatedly proves nothing other than that they have physical access to a machine they have previously used to login -- this change just makes the user type/click more for no real security benefit.

Please change 'rememberlogin' back to 'on'.

Version-Release number of selected component (if applicable):
5.0.3 

How reproducible:
Always

Steps to Reproduce:
1. Login as an admin user
2. Inspect the 'rememberlogin' setting at Administration->Parameters->User Authentication.
3. Restart your browser and return to Bugzilla

Actual results:
In step 2, rememberlogin is set to 'off'.
After step 3, you are not logged in.

Expected results:
Same as Bugzilla 4 - the user remains logged in until they explicitly log out.

Additional info:
none

Comment 1 Jeff Fearn 🐞 2017-01-09 01:37:35 UTC
Please define "very frequently", I've not had to change my behavior so have nothing to base what that means on.

Comment 2 Jason McDonald 2017-01-09 02:37:32 UTC
(In reply to Jeff Fearn from comment #1)
> Please define "very frequently", I've not had to change my behavior so have
> nothing to base what that means on.

At least every time I restart Firefox, which is at least a couple of times a day due to the poor quality of the Fedora 25 KDE spin.  I think I've also been asked to login a couple of times where I closed the window but not the entire browser instance, but I can't reproduce that scenario at will.

Comment 4 Jeff Fearn 🐞 2018-03-13 05:14:06 UTC
Long lived cookies have been identified as a security weakness and we won't be reverting this change.

Comment 5 Jeff Fearn 🐞 2019-01-21 22:32:58 UTC
*** Bug 1667830 has been marked as a duplicate of this bug. ***

Comment 6 Milan Crha 2019-01-22 09:24:41 UTC
(In reply to Jeff Fearn from comment #4)
> Long lived cookies have been identified as a security weakness and we won't
> be reverting this change.

If I recall correctly, the old bugzilla had something like:
   [ ] Remember me
   [ ] Restrict to this IP only
options on the login page. That allowed the user to have a choice, not a developer. While I agree with security concerns, how does the developer know that the user doesn't use other security mechanisms which help him/her to limit the weakness? The developer simply cannot know that. That's why the options were there.

Comment 7 Jeff Fearn 🐞 2019-01-22 21:38:10 UTC
(In reply to Milan Crha from comment #6)
> (In reply to Jeff Fearn from comment #4)
> > Long lived cookies have been identified as a security weakness and we won't
> > be reverting this change.
> 
> If I recall correctly, the old bugzilla had something like:
>    [ ] Remember me

The above is incorrect, there was never a UI option for this. The change here is that cookies now have the session  property set.

Comment 8 Jeff Fearn 🐞 2019-01-22 22:42:47 UTC
I'm going to reopen this bug and hand off policy changes to the security teams.

Hi Jan, what should the login cookie policy be bugzilla.redhat.com?

Comment 9 Jeff Fearn 🐞 2019-01-22 22:43:41 UTC
*** Bug 1667379 has been marked as a duplicate of this bug. ***

Comment 10 Milan Crha 2019-01-23 09:35:54 UTC
Created attachment 1522603 [details]
login page on bugzilla.mozilla.org

(In reply to Jeff Fearn from comment #7)
> (In reply to Milan Crha from comment #6)
> > (In reply to Jeff Fearn from comment #4)
> > > Long lived cookies have been identified as a security weakness and we won't
> > > be reverting this change.
> > 
> > If I recall correctly, the old bugzilla had something like:
> >    [ ] Remember me
> 
> The above is incorrect, there was never a UI option for this.

Honestly, I do not know what that option serves for, I do not know bugzilla internals and its usage there. I also do not recall how it looked like in pre-update of bugzilla.redhat.com, that's why I wrote "something like". The attached is what it looks like on bugzilla.mozilla.org, whatever version they use.

The popup login is different, it has only one check, called "Remember", on the bugzilla.mozilla.org.

> The change here is that cookies now have the session property set.

Is that a specific change in Red Hat's bugzilla, or a general change in bugzilla 5? I'm just wondering. Thanks.

Comment 11 Jeff Fearn 🐞 2019-01-24 01:11:55 UTC
Maybe InfoSec want to make the call on this?

Comment 14 Zdenek Dohnal 2019-02-19 11:06:08 UTC
*** Bug 1676787 has been marked as a duplicate of this bug. ***

Comment 15 achapman 2019-02-28 02:04:09 UTC
Given the additional risks from client-side vulnerabilities, as well as the potentially sensitive information stored in Bugzilla, InfoSec will always advocate for short-lived session cookies where possible. This reduces our exposure to a number of attacks and provides an overall improvement in user session security.

Comment 16 Jeff Fearn 🐞 2019-02-28 03:42:32 UTC
Given Comment 15 and the fact that https://access.redhat.com/ and other public facing Red Hat sites are using session cookies for authentication cookies we will not be changing how authentication cookies are set.

Comment 17 Milan Crha 2019-03-01 06:57:22 UTC
Could you, at least, as a compromise, refresh the cookie when it's more than half-lifetime old?

Say the life time is set to 7 days. When I open bugzilla with a cookie which is older than 3 days, you'll refresh it and it'll stay valid for another 7 days. This way people using bugzilla regularly will not be asked for the password every week, while people not opening the page for more that 7 days will be asked for it.

It's really odd to be able to just open the page one day and be prompted for the password the very next day (or the next browser start). I do not know how precisely these authentication cookies work, but a corner case of opening the page with to-be-expired-in-one-minute cookie and it expires before I finish writing my comment, thus submitting the changes would ask for the password, would be quite bad. I guess it doesn't work like that, but still.

And when you want to talk about security, I noticed a change in Seamonkey after updating from some ancient version. It caches the content of the tab and it doesn't refresh it after the Seamonkey is started, which is fine, except it does the same for authenticated pages as well, thus anyone opening the browser is greeted with a cached content of an authenticated page, where it would not have access without giving proper credentials otherwise. Older versions always asked for the password after open. This is not a claim against Seamonkey (maybe it's already changed/fixed there, I've no idea), this is just an example that there are things the user cannot influence, which you try to workaround by some obscurity, but this obscurity fails anyway in some cases.

Comment 18 Jeff Fearn 🐞 2019-03-03 23:25:08 UTC
(In reply to Milan Crha from comment #17)
> Could you, at least, as a compromise, refresh the cookie when it's more than
> half-lifetime old?

AIUI The whole point of requiring you to re-authenticate is to force you to confirm you are who you say you are. Even as someone who isn't a security specialist I can see that something that extends your authentication without requiring you to actually authenticate is fundamentally flawed in regards to that.

I think Bug 1659832 is a reasonable compromise.

Comment 19 Milan Crha 2019-03-04 09:08:27 UTC
(In reply to Jeff Fearn from comment #18)
> ...is to force you to...

Yeah, I, as many others, do not like this kind of force.

> I think Bug 1659832 is a reasonable compromise.

Supposing you usually do login with Kerberos, which I do not.

Anyway, it's fine, it was only an idea. Thanks for commenting.


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