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):
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
In step 2, rememberlogin is set to 'off'.
After step 3, you are not logged in.
Same as Bugzilla 4 - the user remains logged in until they explicitly log out.
Please define "very frequently", I've not had to change my behavior so have nothing to base what that means on.
(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.
Long lived cookies have been identified as a security weakness and we won't be reverting this change.
*** Bug 1667830 has been marked as a duplicate of this bug. ***
(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.
(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.
I'm going to reopen this bug and hand off policy changes to the security teams.
*** Bug 1667379 has been marked as a duplicate of this bug. ***
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.
Maybe InfoSec want to make the call on this?
*** Bug 1676787 has been marked as a duplicate of this bug. ***
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.
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.
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.
(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.
(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.