Require password for certain admin actions

Created on 27 January 2025, 2 months ago

Problem/Motivation

Project browser allows installing new functionality to a site. This could be used by a malicious person who has taken over someone’s account, either by social engineering, or exploiting an XSS or other vulnerability which allows account takeover. The new functionality could chain to widen the initial vulnerability scope. For example, installing PHP module or adding backup & migrate to exfiltrate data.

This isn’t unique to project browser installing a module, there are other important actions which could be used by attackers to escalate security problem. For example, maybe setting an admin user’s password. These places could use an extra confirmation that the person is indeed who they say they are.

Examples from other systems:

  • MacOS system settings requires unlocking some settings
  • GitHub requires 2-factor-authentication for setting up webhooks

Proposed resolution

A common way to confirm a person would be good to have in core.

Asking for someone’s password to confirm would be a good first step. There might be a way to disable this in settings.php for development and environments where Drupal isn’t doing password authentication. A system to extend/override the confirmation would be ideal, but might be able to wait for a followup issue.

To avoid password fatigue, unlocking should persist for some time period, like an hour or two.

Remaining tasks

  • Figure out some details
  • Implement
  • Keep track of followups that aren’t needed for the initial feature

User interface changes

Yes, there is new UI for this.

Introduced terminology

Something along the lines of “unlock to make changes”

API changes

Should be usable by modules

Data model changes

Release notes snippet

Feature request
Status

Active

Version

11.1 🔥

Component

user system

Created by

🇺🇸United States drumm NY, US

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

Production build 0.71.5 2024