Username Enumeration Prevention

Thanks for the input greggles. So what is it that you want me to do? Provide documentation once the module has been enabled about the 3 issues? Is there some way we could prevent the callbacks from being displayed when they are not called from the correct place or is it something that is called from too many places to protect?

I new about the "submitted by" being in posts but I just thought it would be best for sites that do not display any usernames to at least have some protection by not having the password reset form potentially display users. My thoughts were also that the admin user could not be guessed using the password reset form.

I did not know about the callbacks which is an even easier way of getting the users than the password reset form :( Typing in http://drupal.org/admin/views/ajax/autocomplete/user/admin gives an attacker a good start but then maybe trying to prevent every username from being found out is over the top? Especially with the brute force prevention in Drupal 7 but it still makes attacking a Drupal 6 installation easier.

I would still feel safer knowing usernames on the system could not easily be found out. What's your thoughts on this?

I have been doing some testing and I have found the callback you mentioned in point 1 is only an issue with Drupal 7. Running tests on the latest Drupal 6 show access denied messages for all users apart from admin. As for the views callback mentioned in point 2, the following code put in this module should prevent that:

function username_enumeration_prevention_init($destination = NULL) {
  $path = $_GET['q'];
  if (strlen(strstr($path, 'admin/views/ajax/autocomplete/user')) > 0) {
    global $user;
    $account = user_load($user->uid);
    if (!user_access('administer views', $account)) {
      drupal_access_denied();
      exit();
    }	
  }
}

The code only allows the callback to be run when the user has permission to administer the views. Although, I assume this should be checked with views team to make sure it has no issues. I think, I just need to find out why the first callback does not have the same behaviour in Drupal 7 as it does in Drupal 6 and then like you say display warnings for the remaining issues.

Cheers

Ok, I don't think there is anything that can be done for the views callback then. Maybe an issue could be submitted to views and they could do something to prevent the callback being called directly? I will add the documentation to the README and project page and also make the module check for realname and a username override.

I will add the issues you have mentioned to the documentation and add some checks with warnings into the module. I will make the module check the following on enable:

1. If the "access user profiles" has been granted to anonymous users. Display warning.
2. If views is enabled. Display warning and information about the views callback.
3. Recommend realname to obfuscate usernames from submitted content.

There is already an issue http://drupal.org/node/1069326 and they have come up with a patch. Only problem is if I do the same thing in this module, it could potentialy cause issues for certain users of views.

I have made the changes asked for and also added the hook_menu_alter for the views callback.

bump, its been over a week now and would like some feedback on getting full access. I also have another module pending review at http://drupal.org/node/1157628

Thanks

Bump.

Would like some feedback on getting full access.
I have this and another project that I would like to change from Sandbox to release http://drupal.org/sandbox/ToneUK/1180974

Thanks