Recently I realized a security flaw with the design of the "forgot your password" system. Some user thought it'd be cute to try and get my password for my account. As an anonymous user, they clicked on the "forgot your password", then simply entered my username. This reset my password. Obviously, the new password was emailed to me, but this caused me significant worry.

Any anonymous user can simply enter any user account name into the "forgot your password" form, and reset users passwords. Now, take this to the next step. Simply setup a script with perl that simply loads this page, enters a username on the site, POSTs the page, over and over and over. Pretty simple to create a significant DoS attack on a Drupal system.

Something needs to be done to force the user to provide a personally identifiable piece of information (eg a question and answer setup during the user account creation phase), that will prevent anonymous users from resetting any user names.

Note that as an anonymous user, you can pretty much harvest usernames at will on any drupal site, unless all functions for the Anonymous user are disabled/turned off. Most drupal sites at least allow "view content" access for anonymous user.

v/r
Shane

Comments

cczona’s picture

cczona commented

Gathering additional personal identifying info raises a few concerns.

  • Security: If the user database is ever cracked, such info can be exploited for further theft including identity theft.
  • Privacy: Collecting personal identifying info subjects the webmaster to certain moral and legal responsibilities to disclose how the information is being used and stored.
  • Longevity: It's got to be info that remains both true and memorable for that person over a long period of time. I've seen too many systems that use info like pet name or hometown as the identifier--these things change over time (quite freqently for some) and it can become troublesome to figure out through trial-and-error which answer would have been the applicable one at the time of sign-up.

The security concern is important. Let's explore alternatives solutions for resolving it.

My initial thought was to simply not reset the password until the user had responded to a confirmation email, but that only saves the admin from having to restore all the passwords after a DoS, while still allowing someone to trigger an onslaught of email traffic quite easily. So that wouldn't resolve the matter, at least not by itself. What about imposing some sort of throttling? Like no more than X number of password reset requests (sitewide) allowed per minute, and/or no more than X number per minute from any given IP (though in any decent DoS that would probably be spoofed anyway...).

Another idea, that would reduce but not eliminate risk for this type of attack: make usernames less havestable by using a separate author name field for public attribution. So user John Doe would login as "jdoe@drupal.org" but post as "John Doe" or "neo" or whatever else he prefers to call himself. The only time username would be disclosed is at login.

Hopefully there's a more elegant way to resolve this. Personally, I hate having to constantly chip away at privacy in the name of Internet security. Surely there's a way to retain both...?

ax’s picture

ax commented

see also

[feature] passwd reset | http://drupal.org/node/view/1639 (changed from bug to feature on June 11, 2003)
[bug] user_password is predictable | http://drupal.org/node/view/1935#4 (closed on June 19, 2003)

has some good suggestions.

Anonymous’s picture

(not verified) commented

The strategy you mention of simply having a separate display name is a good one; however it leads to obvious follow-up requests like "can I turn the display names off and just use the login names like I used to?" and "can I have drupal do some checks when creating a user to make sure the login name isn't too similar to the display name?".

Anonymous’s picture

(not verified) commented

Stick the new password in a temporary field. Attach an expiration date. Don't save the new password as the real password until it's been used to log in. Don't send yet another new password as long as there is an unexpired new password pending. Explain in the new password letter that if the user didn't ask for the password they can just ignore it.

Kjartan’s picture

Kjartan commented

Latest version of Drupal generates completely random passwords.

Anonymous’s picture

(not verified) commented

Automatically closed due to inactivity (marked fixed for 14 days).