This feature is enabled based on permissions

Once the MVP is proven then reset password will be mandatory for all projects so we can ensure all users on all instances are not compromised in future. Until then it's fine to use a feature flag so projects can opt-in to try it out.

Subsequent logins won't require a password change.

One addition to this, is the user loses their phone, or forgets their password and the administrator resets it for them, then the user will be required to change their password again. This is because the password has almost certainly been shared in plaintext so it's once again vulnerable to future leaks.

Hi @garethbowen

I'll be starting this tomorrow (Oct 23). Probably start with conceptualizing the data flow then work on the UI first. Just checking whether you have any comment / clarification before I start ..(anything to add other that what we have in this thread) ?

cc @n-orlowski are we going with the single password input design or confirm password design in Figma?

@Benmuiruri Nothing to add regarding the UX. Potentially explore ways to keep it simple for the MVP, for example, is the password strength bar strictly necessary or something we can do in a separate issue?

From an implementation point of view, I think it's a fairly simple process of flagging the user with password_change_required: true (or something). This gives us flexibility to implement further features like forgotten password and admin reset easily using the same logic. We need to make sure this flag is set when users are created or have passwords changed whether that's done using the user management app, the admin app, direct to the db, or any other way. Make sure everyone is using the API or we'll have to intercept the POST request...

Finally, because this is in the authentication system we'll have to be very careful not to accidentally break anything. For example, if the feature flag is enabled once users are already logged in they should not be forced to change their password.

@Benmuiruri let's do with the confirmation input. Also happy to drop the progress bar for MVP (but we should keep the written prompts)

Adding this to 4.16

Okay, sorry for the last-minute design questions here, but I am a bit concerned about how the MVP functionality is going to work from a Programs perspective. (Started this discussion in this PR thread, but wanted to continue it here at a higher level for better visibility....)

• My primary concern is that the can_skip_password_change permission is essentially an "opt-out". By default, users will have to reset their password whenever it is changed by an admin. Unless a project updates their permissions, this password reset behavior will automatically take effect for all users.
  • This seems to be the opposite of the behavior @garethbowen described above "Until then it's fine to use a feature flag so projects can opt-in to try it out." Perhaps I missed more conversations that happened elsewhere....
• If we are going to make this default behavior, then it really feels like our MVP needs to contain a more sophisticated "out-out" mechanism than a permission. As things are, it really feels like we could seriously complicate things for admins in the field (where getting users logged in has historically already been a problem). Other user management tools I have used (e.g. Keycloak) have included a check-box when modifying a user's password to "Require user to reset password on next login".
  • I understand the security posture is much better with the automatic password reset. However one consequence of this change that seems likely to me is that, for many user accounts, no one will actually remember the password after it gets reset by the user. (I know I struggle with this, myself, if I don't immediately take the time to record a new password that I set.) This will likely result in increased churn in passwords as users will need admins to reset their password each time they need to log in again.
  • If we have decided that we don't want programs to be able to manage passwords for users (for security purposes) it seems like token login links would be less burdensome to both the admins and the end user....
• Have we gotten feedback from Programs folks on possible impacts that this change will have on various user management workflows? (Maybe this feature originated from talking with programs and is exactly what they need to improve their user management, but I don't want to just assume that...)

Hopefully this has all been previously discussed in threads that I have just missed. If the answer is "yeah, we took all of this into consideration already and decided the current approach is best", then great! I will be happy to move forwards with this, as is.

Another design question that has come up on the PR is how we should handle basic auth requests from a user that has "password_change_required": true.

The current implementation has added an extra lookup for the _user doc of the user in context to check the password_change_required property on every request to the server. This is needed because a simple _session check will succeed when you use the new password (the one the admin set) and is not sufficient to force you to change your password.

I am wondering if we could be content with not forcing a password reset for basic-auth requests like this. Instead, we only trigger the password-reset flow from the actual login flow. For normal users with a session cookie, when the admin resets their password, they will be forced to login again (and so will be funneled to the password-reset flow). I am just not sure it is worth adding an extra round-trip for every request just to address this basic-auth edge case....

You raise very pertinent issues Josh. I was concerned about the Programs disruptions as well, but I proceeded with the implementation believing prior discussions had taken place with all stakeholders about how it would work in terms of requiring password reset whenever the password is changed.

Given the situation we are in, time constraints, and this being an MVP that (to the best of my knowledge) none of the partners is particularly waiting for it, how can we create a functional MVP that is not too disruptive? I see two paths here.

Option 1: Put the PR on hold / Close it to resume it next year after further discussions.

Option 2:

• Change the solution to be permissions based, but make it opt in.
• Only require password reset on first time login, not when password is changed by admin every time
• Only enforce the password reset flow in the webapp login without enforcing it in the basic auth for now.

I agree with Josh on opting-in vs opting-out for the MVP. Especially because we don't have a password reset mechanism put in place.

As for the 2nd point of Basic Auth requests, making this opt-in means that users intentionally created to be used with integrations can be kept opt-out. I'm not super happy with what is happening now though, getting that message "password change required" doesn't really give an indication of what should be done. If I didn't know how this worked, I would just edit the password through the admin console just to get the message again. That's a horrible user experience. I think we really need to come up with something else if we wish to keep this.

Additionally, for the concern that we make an additional request to get the user, for most requests we already need the full user doc, and we get it in subsequent middleware: https://github.com/medic/cht-core/blob/master/api/src/middleware/authorization.js#L66 through getUserSettings.
If we could coalesce these so that we never end up getting _user doc twice, that would involve no performance concerns.

This feature came up after an unfortunate event where a project got a document with user passwords leaked. It was designed as an opt-out feature because CHT should be secure-first and already have these features by default. It should not disrupt existing users; only new users or those getting a new password from the system admin will go through the process of changing passwords. Like other stuff (old UI design to new design), the opt-out capability is temporary, then removed, and that feature becomes "native".

The token login has been an option but not popular (I don't remember of any project using it right now). This feature remains, and no changes are planned there.

We understand the struggle to learn setting up a password, and that this will require user training. As a second phase to this feature, we thought of added a password suggestion mechanism.

Programs has been in contact with one MoH to start using this feature as soon as it's available. I think it's best to follow up with them to get the latest details. I understand that Programs was very engaged in conversations with this partner about implementing this additional security mechanism, and avoid password leaks.

About the basic auth question -
I agree with Diana about avoiding getting the doc twice by using that function.
It's okay to keep this Change Password flow to the login page flow as MVP, then straighten the basic auth later. The main intention is to protect CHWs. The basic auth is not less essential but another scope of work since we need to think of the best way to avoid disrupting tools / integrations using the basic auth.

Okay, so after discussing this more with @latin-panda I now better understand the motivations for making this functionality "opt-out" via a permission instead of "opt-in". This would follow the same pattern we have used for feature flagging other functionality that we intend to eventually be the default experience in the CHT (e.g. the FAB button). This "opt-out" approach will simplify the code maintenance going forward (making it easier to eventually remove the permission) while still allowing deployments the flexibility to avoid taking this behavior immediately if they need to update their operating procedures to work with the new approach. With that in mind, I think we should keep the can_skip_password_change permission in the PR with the understanding that we intend to remove it in the future.

However, I do also think that our base create/update user functionality (e.g. via the REST apis) needs to accept a password_change_required: false property (or something similar) so that it is possible to avoid this functionality for a particular user (regardless of the can_skip_password_change permission. Let the default be password_change_required: true when nothing is set. I am also okay if we do not immediately support any way from the admin app to actually set this flag to false, but from a platform perspective, this feels like an important thing to be able to control (e.g. the cht-user-management tool might need more complex/custom logic to determine who should have to reset their passwords....).

I also want to second Jenni's proposal of pushing the basic auth flows into a new ticket. I think Diana is correct that we might not actually need an additional round-trip to the DB to make this work, but the details on how we want to handle erroring/redirecting a basic-auth request are things that we can sort out in a future ticket and do not need to be in the MVP PR.

The documentation in cht-docs for this feature is here: medic/cht-docs#1711

@Benmuiruri Unfortunately, I have not seen any communication from MoH Kenya. (Mr Wanyungu) approving this.
@katanu @PhilipNgari @andrablaj Perhaps it needs a meeting with the MoH stakeholders first to explain the rationale for their sign-off before implementation considering the possibility of the fear of programme disruptions concerns by MoH.

This was discussed during Digital Health week and we asked Dickson to seek an audience with John Wanyungu on the same as well as the ICT heads in both Moh departments. I will follow up since I am yet to hear an update. Its a key one since it touches on the password management requirements under cybersecurity enhancements.

@PhilipNgari during implementation, will it mean the CHPs will be automatically logged out and prompted to create personal individual new passwords?

@christinawere Existing users will not be affected by this change (unless their password is reset by an admin). Users will be required to create new passwords when logging in for these cases:

• Newly created users - Upon first login, they will be prompted to set a new password. This applies to the initial provisioning of users for a new CHT instance as well as any users that are subsequently added to an existing instance.
• Existing users whose passwords are reset by an administrator - The admin can reset their password to an interim value and provide that value to the user. When the user logs in with that interim value, they will be prompted to set a new password.

This applies to all users except:

• The hard-coded CouchDB admin users.
• Users configured to have the can_skip_password_change role

@jkuester thanks follow-up question. Are we recommending it to be mandatory for existing users?

If yes, @PhilipNgari @katanu , what might the implementation look like in terms of minimal level of effort and UX disruptions for both admins and CHPs (with lessons drawn from utilization of the user management tool)

Are we recommending it to be mandatory for existing users?

@christinawere the short answer is yes, this setting is recommended for all users and the long-term plan is to eventually remove the can_skip_password_change permission from the CHT. This is an important security best-practice intended to help avoid/mitigate future password leaks. However, we absolutely recognize it has the potential to be disruptive to current admin workflows. The purpose the can_skip_password_change permission is to provide an escape-hatch for projects that find this feature to be unrealistically disruptive.

The hope is that we can have an ongoing conversation about additional functionality that admins need in order to avoid using can_skip_password_change. For example, @kennsippell already mentioned being able to impersonate users. The more information/feedback we can collect on these kinds of needs and their priority, the better!

@jkuester, thanks. It makes sense.

Perhaps in addition to the rationale above, it might be beneficial to list in the simplest terms pros vs. cons of implementing the best practice now vs. later vs. never. And sharing this with MoH so that they can quickly make the decision and plan around supporting MoH admins and CHPs during this activity.

@christinawere - please let us know how we can support your program! I'd like to start by publishing the docs on this feature (see this screenshot of what they'll look like) and go from there. I'll report back when this is live!

Please let me know what other documentation or videos would be helpful. I'd be happy to do a forum post comparing before and after in a video for example.

@mrjones-plip Nice.
For now, what I can think of that might help accelerate discussions on the MoH Ke side, to get implementation approvals is just what I have mentioned in the comment above, in addition to 'what it will look like' .
(unless the push from the community committee is to proceed anyway).

@christinawere - I've opened a ticket in the eCHIS config repo to track this conversation further.

Hey folks,

Recognizing we need to help administrators understand the implications of this feature, I added a hint that will inform admins when updating the password will require a password reset from the user. i.e

• If user has can_skip_password_change permission we don't show the hint since password reset won't be enforced
• If user does not have can_skip_password_change permission show the hint in the form because it means the user will need to reset their password once the password is updated