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

This kinda reminds me of concerns I had about RDF in core back in 2010. While I was being blatantly provocative back then, I do wonder about similar things for JSON:API (and whatever the next big thing will be) and in what we expose publicly, by default, in general on the web.

The work of the security team is great, but I wonder if we could/should be putting more emphasis on privacy in addition to security.

Indeed, I like the idea of reframing this as a breach of privacy. When looked at through a lens of trust/privacy/safety, perhaps the contours of this issue become clearer? Maybe revisiting some of the Core Privacy Initiative ideas from 2018 could be a good way to organize and act upon issues like this?

This type of work reminds me of this Nov 2011 piece from Vint Cert.

In it, he suggested that:

These notions take us to the conclusion that Internet actors (those who make and operate the Internet and its applications) have an ethical responsibility to take steps to improve the ability of Internet-related technology to protect users from harm, to warn them when they are at risk and to advocate domestic and international regimes to provide recourse when harms peculiar to the Internet environment occur.

FWIW, to help mitigate some of these risks in JSON:API, I added a route subscriber and set a new access requirement. This prevents that type of disclosure to any old bot, I guess, but it doesn't handled the broader scope of what is being described in this issue (which I think is very worthy of consideration).

Duplicate
500 error on D.O. lead to a duplicate post.

Deciding whether this should be policy is the first step and to a degree is version agnostic.

https://www.drupal.org/drupal-security-team/security-team-procedures/dis... Links to a different issue but should probably link to this one.

I think we should separate whether it's considered a security issue vs. a bug - i.e. we can decide to not show usernames in various situations in core that would allow renumeration, without them having to go through the private security issue process, get CVEs, SAs etc. Also even if we were to decide it was a security issue, I think we should still fix the existing, public, known issues in the public queue first anyway - there's no point fixing issues that have been public domain for 15 years in private due to a policy change.

I think we should still fix the existing, public, known issues in the public queue first anyway

Yes, definitely. Thanks for clarifying. That was a little ambiguous in the issue summary so I made it more definite the goal is to declare the policy for a future release, fix the issues in public, then make the core release with that change of policy, and treat issues found after that as private advisory-worthy security bugs.

Adding another issue that can be a path to discover a username (and email).

We support the proposal. According to the GDPR we understand the displayname as personal data. Without user's consent no site visitor should be able to get the displayname. The user's consent could be given in several ways, so the site owner should decide where the displayname is shown and who can see it.

We see following possibilities:

1) Introduce a permission to see displaynames and check in Drupal\user\UserAccessControlHandler (like suggested in #3240913)
2) Adding a policy / term of use field in /admin/config/people/accounts for the user register page and add an optional consent checkbox to user register form.
3) Option in user's interface to show own username to others (maybe not a task for core but for custom modules).

On web sites for special interests (like chronic diseases or sexual orientation) the displayname can become a special category of personal data ("sensitive data") and the site owner has the responsibility for increased protection.

We know that the main part of this issue is to be done be sitebuilders (e.g. templating, adding a consent for subscription, or correct path aliases for users) - but core should give the tools for this.

If I understand correctly this issue is waiting on a product manager to review (comment #8)

It has been brought to my attention that a PM should review an issue within 1 week of the needs-review tag being added otherwise the issue should be escalated to "the next step"
https://www.drupal.org/contribute/core/maintainers#faq-timeframe

In the case of this issue since it is policy not a commit what would the next step be? Would this be escalate to core committers in general?

I don't think it's the case at all that the issue is waiting on product manager review, I've just changed the order of the 'proposed resolution' in the issue summary. Not untagging yet, but also not sure whether it actually needs product manager review at all, if anything seems more of a decision for the security team and release managers.

From my perspective at least:

1. Public issues can be filed at any time to fix username and/or email address enumeration. #2828724: Username enumeration via one time login route got committed just recently.

2. Once all known public issues are fixed, it's then a case of deciding whether to fix further issues in public or private, and from which release that begins. But there can't be a commitment made to any particular release until all the known issues are fixed anyway.

Personally I would prefer that we treat username enumeration as bugs to be fixed in the public queue, because (in general), it is easier and faster to fix bugs in the public issue queue rather than going through the private workflow. If you look at the existing username enumeration/email enumeration issues in core, they are extremely obvious, like via requesting a password reset. It's not a secret that you might be able to find out whether a username or e-mail address is in use on a site via requesting a password reset, so a private issue would benefit no-one except people already doing it who would like it to be fixed as slowly as possible.

If there are proposals to add user interfaces for people to set various options for how and whether their username is displayed, then those might need UX and product manager review, but that would be on the specific issues, which I don't think are even open yet, not on this overall policy one about what's considered a privacy breach/security issue or not.

But there can't be a commitment made to any particular release until all the known issues are fixed anyway.

I would disagree, if we have a set version we have a timeline to work against and the known public issues become release blockers, not much different than PHP8.1 support, Symfony 6 support, etc.

We can't force anyone to work on an issue, but we can at a project level inform what issues will prevent a release from occurring which will draw resources that direction.

it is easier and faster to fix bugs in the public issue queue rather than going through the private workflow.

True it can be much easier with more help, however this issue started from a server that discovered a vulnerability, that if were made public and exploited would require the site owner to publish a breach disclosure.

I don't know about you, but for me if I'm at a conference with developers and I'm told "The Drupal Security Team told a vulnerability reporter to go public with XYZ as the DST did not consider it a vulnerability, and that public disclosure lead to active exploit against our site which created a need to notify regulators and pay damages" its going to be very hard to recommend Drupal to clients.

so a private issue would benefit no-one except people already doing it who would like it to be fixed as slowly as possible.

I believe the the opposite, the fact they are not considered security issues allows these issues to be de-prioritized and remain open longer, effort is put into the release goals and taken away from these 'feature requests'. While I find the security team tends to be very slow I consider this more related to policy being discussed in other open issues.

#2828724: Username enumeration via one time login route had been open since 2016 and #2346389: Prevent registered e-mail address enumeration via user registration form has been open since 2014 as an example of the concern indicating this may need policy backing.

In #17 there's a proposal:

Personally I would prefer that we treat username enumeration as bugs to be fixed in the public queue

And I think that's an interesting one. The motivation I can think of making the policy that username disclosure a security bug is that any contrib with that bug can be forced to make the change or get unsupported and maintainership lost. I think it could be advantageous to make username disclosure a policy with similar seriousness/enforcement without requiring the bugs to be private.

I would disagree, if we have a set version we have a timeline to work against and the known public issues become release blockers, not much different than PHP8.1 support, Symfony 6 support, etc.

That doesnt really work. The only reason those things are release blockers are due to dependencies going out of support, if the dependencies weren't going out of support, they wouldn't be, Doctrine annotations and jQuery UI are both examples of where we'd love to remove that dependency but ended up not making it a release blocker because they haven't actually dropped support yet. And once it wasn't a release blocker effort fell off those issues. If we have multiple dependencies (like Symfony 4 or CKEditor 4) going out of support in 6-12 months, and the only issues blocking a release are due to a policy like this, that policy would end up getting pushed out a year or three vs not having a release with new versions of those dependencies and being unable to EOL the old major.

I think it could be advantageous to make username disclosure a policy with similar seriousness/enforcement without requiring the bugs to be private.

This is interesting. But I wonder about things like shipping views that show the username on a comment to anonymous users, on some sites that is fine and it's 100% configuration, so are we going to treat that as a privacy breach? But that's something to figure out regardless of where the issues are fixed.

But I wonder about things like shipping views that show the username on a comment to anonymous users, on some sites that is fine and it's 100% configuration, so are we going to treat that as a privacy breach?

This is a great question. I was trying to think of an example and I think a community distribution profile is a good one. My opinion is that we should agree on which permissions control the ability to see the username and a view that shows usernames to anonymous by default should respect the permission. If a site admin installs the distribution and then turns off permissions on the anonymous role to see usernames the view should adjust itself. That's my take.

Another sticky point is the registration page: I believe a registration process always has to disclose username and email addresses that are registered (i.e. this email is already registered form error, this username is taken please choose another form error). I guess the policy will need to take into account that enumeration via the registration form (and perhaps other paths) is possible though has flood protection to prevent doing it in bulk.

If a site admin installs the distribution and then turns off permissions on the anonymous role to see usernames the view should adjust itself.

It would have to be the formatter for usernames (whether on a field display or entity display) in that case, since the view can't really update itself. So I guess in that case a bug would happen would be a formatter or something in preprocess like comment submitted, that doesn't respect the permission.

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

I'll note that #3240913: Make username access configurable and not implicit allowed appears to have something in it that protects views (at least at some level) as applying that patch and a view that previous lists usernames no longer does unless the user has the appropriate permission. It might just be the template_preprocess_username() code which is a 'fallback' protection.

Another sticky point is the registration page: I believe a registration process always has to disclose username and email addresses that are registered

I think it's a bit more nuanced than that in this case.

Coming at this from a suability perspective.

Generally, we want form errors to be specific and actionable, an error simply saying "this form has an error" is the least helpful, whereas an error saying "this username is already in use" is very helpful because it's specific and actionable. In other words, the user knows exactly what the problem is when they get that error so that they can take appropriate steps to not encounter it next time they submit the form.

The challenge comes when we want to balance that with not disclosing that the username or email address is already in use, but I think we could also find a more creative solution to the problem than simply coming up with an (arguably) less helpful error message.

This is definitely something we could discuss at a usability meeting. But, #2346389: Prevent registered e-mail address enumeration via user registration form already has quite a good approach in my opinion with branching logic. We may be able to further refine that, for example by splitting the registration form into multiple steps to better support that branching logic. For example: first page of registration form contains only the email field, user submits form, email is sent, which either takes them to the second step of the form with all other fields (set username, password, etc), or informs them of an account already existing and gives them some actionable next steps. Obviously, there's more scenarios depending on the site configuration, but that's just one examples.

My point is that, I think there is a way forward which supports such a policy without having a negative impact on the user experience. Coincidentally this might actually have a positive impact, because user research shows that multi-step forms are more usable then one large form, so these changes might actually enable positive UX importements, which I see as a win.

In context of current (developing) events:

The news circling about the "200 million" Twitter datasets (originally announced in December as ~400 million records, current reports indicating it is likely closer to ~130million records once duplicates are removed) was likely obtained from the vulnerability announced in August combined with data scrapping based on the returned username.

if someone submitted an email address or phone number to Twitter’s systems, Twitter's systems would tell the person what Twitter account the submitted email addresses or phone number was associated with, if any.

https://privacy.twitter.com/en/blog/2022/an-issue-affecting-some-anonymo...

It is also interesting there are reports that one of the adversarial parties has reportedly even attempted to blackmail Twitter into buy the data to avoid a GDPR violation.

At least one announcement that an investigation is underway for potential GDPR violations has been made:
https://www.dataprotection.ie/en/news-media/data-protection-commission-l...

While little can be done for the scrapping portion of the attack, the initial portion of username enumeration by email address appears to fit in a scenario where the Drupal Security Team would not consider it a vulnerability necessary due to the blanket exclusion on username and user id's being considered a weakness.

Drupal is primarily intended to be used for sites where identity and interaction are key elements so it is reasonable for that information to be public.

I read that and find myself thinking about how that largely matches key elements of Twitter.

Note: This is a developing situation and the above information is subject to change as more information becomes available

@greggles wrote:

> Another sticky point is the registration page: I believe a registration process always has to disclose username and email addresses that are registered (i.e. this email is already registered form error, this username is taken please choose another form error). I guess the policy will need to take into account that enumeration via the registration form (and perhaps other paths) is possible though has flood protection to prevent doing it in bulk.

I dont think so! A very clean and slim registration process is just ask for your mail address and "Thank you for registration. We sent you a mail to proceed the next steps."

If the account exists the user would get a mail with the information someone tried to register and the link to the password reminder page.

For the 2nd step you can define which fields are required and which not. If you decide that users can define their own usernames then this could be a disclosure. But this is a decision of the site's owner. You can just use mail address for login and generate the username automatically.

https://www.amnesty.de/user/register is working this way, just have a look.

Drupal is an important CMS for NGOs and they have to work transparent and conform to the GDPR. Some states of the USA did apply similar laws like the GDPR and the USA plans to enact a privacy policy law in general. Many other countries did or plan to apply privacy policy laws. So this is not only a "nive to have" issue.

Yes, +100 for giving GDPR the same weight as we did for accessibility: Any non-conformance is considered a major bug, and we proudly delay releases until we reach conformance.

I feel with each and everyone that feel resistance to that change, maybe is farther away from that topic, as of their country or their area of expertise. But it won't help, whether we deem this foolishness or important, we have to face the current reality and regulations, and better fast go through it.

There are ~7 linked issues. IMO Fixing those in ways that respect usability is more valuable toward this policy than new comments here in favor if the idea.

Yes, +100 for giving GDPR the same weight as we did for accessibility: Any non-conformance is considered a major bug, and we proudly delay releases until we reach conformance.

Treating it as a bug isn't the same as treating it as a security issue. Accessibility issues aren't fixed in private by the security team.

IMO Fixing those in ways that respect usability is more valuable toward this policy than new comments here in favor if the idea.

+1.