Problem/Motivation

There are a number of issues in the queue that are struggling with this permission in one way or another. Multiple issues propose the removal of this permission, other issues propose a new permission that is similar but not exactly the same. This plan is for laying out the various issues, discussing the pros and cons of various proposals, and hopefully coming to a decision about how to proceed.

Remove the permission:

Add a new permission to bypass "other users" password policies:

There are also various issues in the queue where errors were misreported due to this permission being automatically applied to administrators.

Summary of the discussion so-far on other issues

  1. With bypass password policies it is impossible to force any user with the "Administrator" role (including User 1) to have password policies because they are automatically granted every permission.
  2. This permission is unnecessary when roles are planned out well. You could just not assign roles with password policies to users, rather than assign password policies and then another role which can "bypass password policies".
  3. Fundamentally this permission means "ignore this modules effects entirely for the given user", which seems like the bad approach.

I think it's also worth noting that if this permission is confusing people, that is a UX concern. If the permission is confusing people Significantly, that would be a security concern.

Proposed resolution

TBD. This issue is seeking an agreed upon proposed resolution.

Remaining tasks

  1. Discuss use-cases for this permission.
  2. Discuss the pros and cons of removing this permission.
  3. Discuss the pros and cons of other (new) permissions which solve the use-cases.

User interface changes

None yet.

API changes

None yet, but permissions may change.

Data model changes

TBD.

Comments

daggerhart created an issue. See original summary.

daggerhart’s picture

daggerhart commented
Issue summary: View changes
cgmonroe’s picture

cgmonroe commented

In my case, our GDPR security requirements need to include secure password management, especially for admin users. My vote would be for the policies to apply to all users regardless of role. I believe this mean dropping the permission.

While it might be nice to let admins reset another user's password without regard to the policy, this practice will probably not pass a GDPR security audit. A policy should be universal.

That said, I think even without this permission, there is a backdoor to bypassing the policies, the Drush upwd command. Since this would require access to the server, that seems like a good compromise to allow non-policy passwords to be used.

If there are enough use cases to require this permission, then I would hope that a way to enable / disable it would be included. Preferably with a way to turn it on or off based on a secure method. Maybe only allow it to be set by UID 1?

Anyway, my take on this.

cosmicdreams’s picture

cosmicdreams commented

My issue is that I don't want admins to bypass the security constrains, but D8's admin_role-like behavior means that if a permission exists, then it's applied to the administrator automatically. So there's no way to prevent an administrator from having the ability to bypass security constraints.

aohrvetpv’s picture

aohrvetpv commented

Even without the "bypass password policies" permission, couldn't an administrator circumvent password policies by simply (temporarily) disabling the module?

I think conceptually if you want to constrain the actions of a user (e.g., subject them to a password policy), they can't be an administrator. If needed, make a pseudo-administrator role with a subset of administrative permissions, apply a password policy to that role, and don't use the uid=1 administrator.

I haven't read all the comments on the linked issues, but at present I'm in favor of removing the permission. (Unnecessary complexity, can accomplish the same thing other ways.)

tatarbj’s picture

tatarbj
Primary language Hungarian
Location Brussels
commented

Hi folks,

It gets another +1 by me.

Also because as we discussed it on slack, if there will be a real feature request to develop this bypass functionality, then we can do it with a much smarter way instead of as currently is done with a global permission but even from a configuration form or any other way that fits better the need.

So let's get rid of it, we are very close to an agreement :) It could unblock some other issues to move forward, I believe.

Bests,
Balazs.

aohrvetpv’s picture

aohrvetpv commented

If a purpose of the "bypass password policies" permission was to allow exempting administrators from password policies: That just seems to like bad security practice that should not be facilitated by the module.

daggerhart’s picture

daggerhart commented

It's been over a month and everyone seems to think to remove it, that sounds like consensus to me. If someone comes along with a good use-case for needing this (or similar) permission, they can open a new issue. I'm always open to perspective.

I've marked #2862906: Remove "bypass password policies" permission ready for review. It very simply removes this permission and its single use. Thanks everyone!

nerdstein’s picture

nerdstein
he/him
Primary language English
Location United States
commented
Status: Active » Fixed

We have now merged #2862906 in large part thanks to the discussion here. I'm giving everyone credit for participating in this, because it helped inform the work. The Slack conversations were also great.

Thank you, all, for giving your thoughts. I'm marking this as fixed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.