Bug 1118148 - [EPIC] Enforce stronger passwords
[EPIC] Enforce stronger passwords
Status: CLOSED CURRENTRELEASE
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
4.4
Unspecified Unspecified
high Severity high (vote)
: ---
: ---
Assigned To: Simon Green
Matt Tyson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-10 00:34 EDT by Simon Green
Modified: 2014-10-12 18:52 EDT (History)
7 users (show)

See Also:
Fixed In Version: 4.4.4022
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-27 20:43:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 1009013 None None None Never

  None (edit)
Description Simon Green 2014-07-10 00:34:15 EDT
Description of problem:
It's become clear that there is a large minority of employees that cannot follow Infosec's guide to creating a strong password, so we are going to help them :)

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

How reproducible:
always

Actual results:
People can currently use any password they want, as long as it is six characters long.

Expected results:
People use password that adhere to Infosec guidelines (page 18 of https://home.corp.redhat.com/sites/home.corp.redhat.com/files/attachments/informationsecurityoperatingguidelines-1.99.pdf ), specifically: >= 8 characters, and a combination of letters, numbers and symbols.

Additional info:
Bugzilla already has built in code to enforce strong password (as mentioned above) via the params. There are two additional things I want to do:

1) Log out all accounts, and expire their tokens. This will be done via an SQL script that eng ops runs as part of the upgrade. When annoucehtml is set, we should mention this, so people aren't too surprised post upgrade.

2) If a user tries to log in with a password that does not meet the set criteria, refuse them, and ask them to change their password via the 'forgot password' link, or contact bugzilla-owner/requests@redhat.com if they cannot do this (for role accounts for example)

The one thing for discussion is whether we do the above two steps for all accounts, or only accounts that have privileges. My gut feeling is that we should only do this for accounts that have privileges. A non privileged user does not have access to anything that the general public can see.

Everyone creating a new account or changing passwords will need to have a strong password.

  -- simon
Comment 1 Simon Green 2014-07-10 00:44:10 EDT
Slight clarrification

USER_PASSWORD_MIN_LENGTH is set in Bugzilla::Constants
password_complexity is set in the params (should be letters_numbers_specialchars)
Comment 2 Simon Green 2014-07-13 01:18:20 EDT
I've submitted a patch upstream, as this involves a lot more hacking than I thought. Our patch is nearly identical (one hunk is different), with the increased password length and the SQL to revoke all cookies.

This change will apply to all users. At the point we check the passwords, we aren't able to tell if a user has groups or not.
Comment 3 Jason McDonald 2014-07-13 23:38:30 EDT
kbaker, rlowe: Please indicate your agreement (or otherwise) with this change.
Comment 4 Kevin Baker 2014-07-16 08:08:00 EDT
This is potentially hugely disruptive. Consider the bots and automation (like maitai, bugbot) that have privileged accounts. For example, when IT was pursuing me to update my kerberos password a year or two ago they reached out to me personally to walk me through it. We may not need to do that level of hand-holding for the entire engineering organisation but we will need to do it for certain key users (PGM, PM, management, tool owners etc).

What is your plan to make this as smooth a change as possible for our userbase?
Comment 5 Simon Green 2014-07-16 08:37:39 EDT
(In reply to Kevin Baker from comment #4)
> What is your plan to make this as smooth a change as possible for our
> userbase?

We are going send an e-mail out to the three Bugzilla mailing lists and prod-dept informing users of this change, and why we are doing it. This will give people a weeks notice to get their passwords into shape. The annoucehtml advisory will also advise people they need to log back in after the upgrade, and a link to the bugzilla-announce-list post, since we realise that even mailing for lists isn't going to get everyone.

The biggest issue will be Bugzilla users that aren't real e-mail addresses (pm-rhel@redhat.com being a good example). For the bugbot accounts, we will ensure the passwords are updated. Other accounts may need to contact bugzilla-owner or FLS to get their passwords updated.
Comment 6 Marco Grigull 2014-07-16 20:34:06 EDT
perhaps we could do something else.

a) dump password table, substituting account number with a randomized set-once mapping of users.
b) the list of randomised and password is passed to another team, perhaps infosec or another tiger team
c) The security team then uses bruteforce and/or rainbow tables against this list
d) the security team replaces the password field with a grading of how secure or weak that password was to some scale
e) this list is passed back to eng-ops allong with the scale used
f) A userlist is made from this reverse mapping
g) the automated accounts that are vulnerable are identified and manually updated
h) a communication plan is created targeting the users with the weak password to whatever threshold is agreed upon
i) those user accounts are flagged for password reset at the nominated communicated date.


I realise its a few steps to go through though it does allow us to be least disruptive to already compliant users whilst conforming to infosecs request.
Comment 7 Jason McDonald 2014-07-17 01:48:53 EDT
(In reply to Kevin Baker from comment #4)
> This is potentially hugely disruptive. Consider the bots and automation
> (like maitai, bugbot) that have privileged accounts. For example, when IT
> was pursuing me to update my kerberos password a year or two ago they
> reached out to me personally to walk me through it. We may not need to do
> that level of hand-holding for the entire engineering organisation but we
> will need to do it for certain key users (PGM, PM, management, tool owners
> etc).

There are actually two parts to the change:

1. Force all newly-set passwords to be stronger (i.e. when a user creates and account or changes their password).  The code for this is in the 4.4.4022 package that we are proposing to deploy on July 28th.

This part is not disruptive to bots at all, as it has no impact unless you are setting a password for the first time or changing an existing password, neither of which is something a bot should be doing for itself.

2. Force each existing weak password to be changed the next time it is used to log in (and forcibly log out all currently logged-in users so that they have to log in again and have their password checked).  This code is also in the 4.4.4022 package, but can be disabled by setting the 'password_check_on_login' field in data/params to false, and then enabled at some agreed later date.

If enabled, this part will be disruptive to bots, but only if they currently have a weak password, or aren't capable of logging in to Bugzilla for themselves without human intervention.  I would be very surprised if there are any bots that have the latter limitation, so I think we only need to agree on an approach for handling bots that currently have weak passwords.

It is worth noting that the owner of any bot account with a weak password will need to request a password reset via email to bugzilla-owner@redhat.com or bugzilla-requests@redhat.com if the account doesn't use a real email address.

Accurately identifying all bots (and scripts) is impossible -- some users use their own login credentials to run bots or scripts rather than having an account dedicated to the bot, and evidence in the logs suggests that there are many bots/scripts that are run by users outside of Red Hat.

We already have a good idea of the list of the heaviest Bugzilla users that we can target with direct communications due to the usage analysis work done earlier this year.

The best approach for identifying other bots is probably to just generate a list of all users who have logged into Bugzilla since we started recording a "last seen" date in May 2013 and applying some heuristics to narrow that list down to likely bot users.  I'll undertake to do that if necessary, as I assume that nobody else will volunteer.

> What is your plan to make this as smooth a change as possible for our
> userbase?

Based on the above, I'd propose:

* Agree on a suitable notice period.

* Issue general notification via announcehtml and appropriate mailing lists.

* Identify likely bot owners and issue targetted notifications (and ask for an ack that their password was already strong or has been changed).

* Release the 4.4.4022 package with the code enabled for checking newly-set passwords but disabled for existing passwords.

* After the agreed notice period, run the one-time script to log all users out (could be done in conjunction with another release/outage to minimize disruption) and enable the code for checking existing passwords.
Comment 8 Kevin Baker 2014-07-20 07:53:27 EDT
Hi Jason,

thanks for the detailed response. 

For (1) I give the greenlight. 

For (2) I do NOT give the greenlight until we've had further discussion.

I've created RT#306902 to track EIP's action in this regard.

https://engineering.redhat.com/rt/Ticket/Display.html?id=306902
Comment 9 Simon Green 2014-07-20 07:57:16 EDT
One possible option for (2) is to only enable this check for web based logins. This means that accounts (like pm-rhel@redhat.com) that are used exclusively for API calls do not need to change.

The upstream bug is for web logins only.
Comment 10 Matt Tyson 2014-07-27 20:43:02 EDT
This change is now live. If there are any issues, do not reopen this bug.
Instead, you should create a new bug and reference this bug.

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