[policy] Consider username enumerations as security bugs that require Security Advisories

Changing queues as this is more a DST policy discussion impacting the entire D.O. ecosystem than it is a core issue.

It would have to be the formatter for usernames

Yes, \Drupal\user\Plugin\Field\FieldFormatter\UserNameFormatter() should be used everywhere and the getDisplayName() should be deprecated on the user entity.

The entire view's access could also include a check for that permission, right?

Yes, the user entity's access handler could make a decision based on any condition, like a site-wide permission or a state of a checkbox on the user entity that indicates whether the user gave consent for exposings its username on the site or not.

I would also add that one obvious location on every Drupal site for exposing usernames is the Author field on nodes that does not check whether the user gave consent for exposing their names or not (must be relying in an "explicit consent" which either given or not.)

Yes, \Drupal\user\Plugin\Field\FieldFormatter\UserNameFormatter() should be used everywhere and the getDisplayName() should be deprecated on the user entity.

Took a look at UserNameFormatter and template_preprocess_username() again and it just feels odd, misplaced and very much a D7-heritage that a template preprocess function tries to ensure proper access checking before rendering. Getting rid of this and moving things around could be tricky, but IMO the field formatter (and other username field formatters) should be responsible for checking access to the data before they pass that to the rendering layer. See 🐛 The entity link label formatter should check URL access RTBC and 🐛 StringFormatter always displays links to entity even if the user in context does not have access Needs work .

This worth a new child issue that can be tackled as a dedicated effort, am I correct?

@mxr576 yes any issues to improve core's username rendering/access should be separate core issues in the queue and can be worked on completely independently of this policy issue. I'd probably recommend a core meta issue (if there's not already one) related to this issue, then sub-issues under that.

One place usernames get rendered in a non-standard way is in the node 'submitted' template variable which should be moved to an extra field per ✨ [META] Expose Title and other base fields in Manage Display Active .

The steps laid out in the issue summary indicate the security team would get involved very late in this process. It's not a policy for the security team to decide separately from the core process.

@greggles Perhaps you meant this needed an IS update instead?

This is regarding DST policy, and would cover ALL modules on Drupal.Org not just core. Core does not set the D.O. security policy, the DST does.

It might need one, but I still feel it belongs in the core queue until/unless it finishes with steps like the product manager review.

What about user selection widgets with autocomplete? They use to show the username

What about user selection widgets with autocomplete? They use to show the username

Those are tricky ones indeed. Most likely they can only list usernames of users that the given user (current user) has view access to their usernames. For stored values, when the given user (current) user does not have access to view the other user's username it must display a placeholder (or just the user id, this is what we have in our solution).

Thank you to everyone following this issue and to those who join the conversation in the future!

We’ve just published a blog post that explains why we believe this topic is critically important. The post also serves as a release announcement for two contributed modules we developed in-house to address this challenge:

• View Usernames →
• View Usernames Node Author →

These modules do not require any API changes in Drupal core but aim to provide immediate, practical solutions. Ideally, a comprehensive solution would involve robust new APIs for managing personally identifiable information (PII), including but not limited to usernames.

We hope these contributed modules can help move the discussion forward and pave the way for the necessary enhancements in core.

... and now these modules are also available in Recipes.

https://www.drupal.org/project/user_privacy_core →
https://www.drupal.org/project/user_privacy_cms →

@claudiu.cristea #43 Those are behind a secret based on the salt. See \Drupal\Core\Entity\Element\EntityAutocomplete::processEntityAutocomplete and \Drupal\system\Controller\EntityAutocompleteController::handleAutocomplete $selection_settings_key argument.

Hm, reminder to me to check if there is missing entity access check
in \Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection::getReferenceableEntities() - because it seems it only relies on query level access checking... - and that could be a reason why the "Author" autocomplete works interesting in node edit form when View Usernames and friends are enabled.

@penyaskito but it's still username enumeration, right?

if there is missing entity access check
in \Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection::getReferenceableEntities() - because it seems it only relies on query level access checking...

Indeed, that is the reason.

Change the policy to be the opposite in an upcoming release: username enumeration is a privacy breach in core and contrib.

Where is the current policy documented?

Current security team policy on this is here:
https://www.drupal.org/drupal-security-team/security-team-procedures/dis... →

I think that eventually changing the policy would still overall be a security team decision (or some kind of joint core committer/security team decision), but it's impossible (or at least useless) to treat username enumeration as an issue to be handled in public until all known public issues are fixed, hence the change of project in #39.

Where is the current policy documented?

As already stated in the motivation section of the IS, this is currently documented at https://www.drupal.org/drupal-security-team/security-team-procedures/dis... →

I think that eventually changing the policy would still overall be a security team decision (or some kind of joint core committer/security team decision), but it's impossible (or at least useless) to treat username enumeration as an issue to be handled in public until all known public issues are fixed, hence the change of project in #39.

I would suggest the core team think of the DST policy as a 'minimum standard' that they will be held to by the DST and that they can be stricter if they desire.

I also suggest the Drupal Core team (and the Drupal Security Team) take into account the points made in 💬 Publication of CVE-2024-45440 by MITRE Active regarding how their policies really do not matter as much as what the global security industry opinion on the situation is. Note: I do believe since that incident the DST starting to better align with normal industry practices, I've had less tension with them regarding publications and they appear to be more accepting and understanding of the industry as a whole.

There is potential here that should the Drupal Core team fail to adopt the policy proposed in this issue that going forward they may find themselves in the same situation as 🐛 Maintenance pages leak sensitive environment information. Needs review where the vulnerability was publicly disclosed per the DST/Core Team request, a CVE was acquired, and the Drupal Core Team had to 'scramble' to release a fix in order to allow site owners to deploy Drupal Core.

Once Drupal Core is on GitLab issues, even if the DST does not work with the Core team there should be the ability to flag issues as Confidential allowing them to be 'worked in private' and the Core team can invoke CNA Rules v4.1.0 section 4.1.1 (Supplier determination) for publication of a CVE record.

The above applies to all the existing publicly available Username Enumerations, they could potentially be assigned a CVE ID at any time. The core team may wish to consider adjusting its target priorities to resolve the underlying concerns sooner rather than later.