hi

just a thought. a user makes a uid on a drupal site, gets a random password (combination of two words of of population of n words, resulting in n^2 possible passwd's)

now all the user has to do is reset his [m/f] passwd often to make up all possible passwords. then he request to reset the password of the uid=1 user and tries to log in with all possible combinations. this shouldnt take more than a couple of minutes, depending script, bandwith, etc. basically he "own3s" the site.

the old 3.x [?] drupal code, used to send a mail for confirmation of the passwd change by letting the users surf to a random created url before sending out the new password. maybe this code should be optionally activated [option in admin section] again?

other options
* maximize the nummber of failed logins (resulting in a possible DoS)
* maximize the number of password resets
* rewrite new passwd resets to True Psuedo Random [tm] generation (optionally, vowel, consonant, vowel,...)

btw: not to sure if security at drupal dot org exists. if not, maybe we should create this, forward it to a select number of people and put up a notice on the drupal site for these kind of security related issues.

as far as my security alert is concerned, it it possible, theoretical or real?

Comments

al’s picture

+1 for security@drupal.org suggestion.

There are some things that shouldn't go public until they've been fixed, and people on bugtraq these days expect a security@ address.

Regarding password confirmation e-mails, this is a good idea for another reason - if the user leaves their machine unattended, another user could come along and change their password (esp. when Drupal's "remember me" cookie option is checked).

al’s picture

> as far as my security alert is concerned, it it possible, theoretical or real?

It's quite real. If Drupal were to only accept e-mail addresses (which are publicly hidden) then this would be a lot more difficult to accomplish. As it is, it's not terribly hard to work out who the admin user for many sites is.

It might be a good idea to include a check for the password reset function to make sure it doesn't work for the admin UID=1 user.

If the site admin loses their password, they're a muppet. What's more, they can manually reset it anyway.

marco’s picture

I'm +1 for the confirmation email for another reason too. It happens that new users DON'T understand that a username is already taken, and request a new password, so the real user receives the new password and, what's worse, emails me to ask why I keep on changing his password Only local images are allowed.
Seriously, with popular sites this happens frequently, especially with common names.

Kobus’s picture

I'm +1 for the confirmation email for another reason too. It happens that new users DON'T understand that a username is already taken, and request a new password, so the real user receives the new password and, what's worse, emails me to ask why I keep on changing his password Only local images are allowed.

If you ask me, if this is the case, then there might be a problem in how Drupal present the information to clueless users. I believe many of these type of problems can be taken care of by the site owner, however, some are left for Drupal.

tbecker’s picture

Would it make sense to modify the new-password system such that when this happens, instead of changing the password immediately and sending a new one out, Drupal:

  • Creates some kind of a secure hash for the request that it will remember for (e.g.) 12 hours
  • Sends out a message to the e-mail of that account holder
  • If password reset request is legitimate, account holder calls the site back, at which point they can really reset the password. This message also contains an expanded version of "if you didn't request a password reset, don't worry, nobody got this message but you." That way, the account holder isn't getting his/her password reset at random, and admins aren't getting bothered by silly questions.
killes@www.drop.org’s picture

I like your proposal. Are you going to send a patch?

moshe weitzman’s picture

Category: bug » feature
moshe weitzman’s picture

Anonymous’s picture

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