Last updated 27 February 2012. Created on 21 December 2010.
Edited by greggles, scor, Andrew Schulman, Josh The Geek. Log in to edit this page.

The Drupal Security Team does not consider it a vulnerability that there are ways to determine a registered members username and/or user id value (i.e. the numeric uid).

Justification for considering username/uid to be sensitive information

This information may be useful to help an attacker gain access to a site. Once an attacker knows the username they have half of the information necessary to break into a site. Many security researchers and experts consider it to be a security weakness for a system to disclose the usernames available on a site.

Drupal's philosophy

Usernames are an important part of online identity. Having a public username helps other users of a site to know the identity of the person they are interacting with in a forum or a blog. 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.

Potential mitigation

Administrators of sites that are concerned about this form of attack should look to increase the strength of their login process. For example, use the Yubikey or Swekey or similar modules. It is also possible to obfuscate the name used for login by displaying the real name of users with the RealName module and reduce the likelihood of username enumeration with the username enumeration prevention module.

Those interested in making usernames a more private piece of information should work on #849602: Update 'username' theme template to use 'view label' operation..

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

escoles’s picture

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.

This is a very weak defense. Drupal is also being sold and is very widely used for applications where the username should definitely be kept private.

I (and I'm sure most other site builders) can understand that some problems are difficult to address, but that doesn't make them not problems. This seems to imply that the security team's standards don't allow it to acknowledge vulnerabilities: they have to either fix it, or decide it doesn't exist. That's a fundamental flaw in business process.

greggles’s picture

Let's discuss this in https://groups.drupal.org/security

That discussion will likely lead to updating the book page, but comments on a book page aren't a great place for discussion like this since they get little visibility.

--
CARD.com :)

dbranco’s picture

Having a public username helps other users of a site to know the identity of the person they are interacting with in a forum or a blog.

I would say more! I think passwords of the users should also be made public, so the users can know more about the person they are interacting with by digging into their accounts. :D

Now seriously, justifying such a security weakness this way is nonsense. If you want your users to know who are they interacting with, then you have a separated Public User Name from your Login User Name...

Right now there is a serious threat with drupal revealing all logins for the sites and of course the admin login name. Many well known sites are having this problem so I reported the problem to the drupal security team and they sent me to this post. I wonder if those sites knew this if they would still be in the drupal hall of fame...

Do you imagine why people use admin login names like adminQuojOc2AF_3 ? Because they want their users to know who are they interacting with? NO!! Because they try to hide their admin logins name because, like everybody else, consider this a security must.

Please, drupal security team, revise this policiy and make us see that you care about security.

greggles’s picture

Drupal is used for a lot of different purposes. On some sites it makes sense to try to hide the username, on others it makes more sense to make it public. If your site needs to keep it private you should use the advice above to achieve that now. If you find the above advice is insufficient, you should edit it to make it more complete.

As I said above in a comment a year ago, it's better to discuss changing a policy in a forum for discussion like groups.drupal.org/security - the policy for ahndbook page comments is to delete them periodically.

--
CARD.com :)