Download & Extend
Issues

Privacy issue with 'Request new password' form: anonymous can check if someone is registered

Posted by no2e on April 8, 2012 at 3:47pm
Project:Drupal core
Version:8.x-dev
Component:other
Category:bug report
Priority:normal
Assigned:Unassigned
Status:needs review
Issue tags:Privacy improvements, refactor account workflow

Issue Summary

(coming from #1359718: Password reset fails when a user has a username that matches another user's email address)

On 'Request new password' form (/user/password), you get the following message if you enter a unused mail address or username:

Sorry, john.doe@example.com is not recognized as a user name or an e-mail address.

If you enter a used mail address or username, you get:

Further instructions have been sent to your e-mail address.

So, an anonymous user can easily check whether there is a user registered with a certain e-mail-address or not.

I think this can be a privacy issue. Think of the following scenario:
Alice wants to check if her fiancé Bob is registered at "adult-dating.example.com", a well known Internet dating site run by Drupal. She visits adult-dating.example.com/user/password and enters his mail address bob@doe-family.example. If she gets the message "Further instructions have been sent to your e-mail address.", she'll know that there is a user registered with Bobs mail address (= Bob himself) or with a username matching his mail address (unlikely that it would be someone else).

Possible solution:
never print "Sorry, XYZ is not recognized as a user name or an e-mail address.",
always print "Further instructions have been sent to your e-mail address.".

Maybe we should change the wording of this message then (adding something like "if matched any account").

Remaining tasks

Login or register to post comments

Comments

#1

Posted by Leeteq on July 17, 2012 at 9:10pm
Priority:normal» major

Good and important suggestion. :-)

#2

Posted by pdrake on November 4, 2012 at 5:48am

How about if it says "Further instructions have been sent to emailhere@emaildomain.com." in both cases (the email does exist and the email does not exist). If emailhere@emaildomain.com contains a typo, this gives the user the opportunity to realize that they have mis-typed their email address and need to try again. If this was an attempt to obtain membership information, no such information has been exposed.

#3

Posted by Carsten Müller on November 4, 2012 at 11:16am

+1 for this issue

i made a patch for it, containing the following changes:

  • Validation if no value is entered in the name field
  • Removed validation message if a wrong or none existing name or e-mail adress was entered
  • The message form #3 by pdrake, regardless if the name or e-mail adress is known by the system
  • A watchdog entry (warning) if the name or e-mail adress is not known in the system
AttachmentSizeStatusTest resultOperations
user_reset_password_privacy-1521996-3.patch3.11 KBIdleFAILED: [[SimpleTest]]: [MySQL] 47,563 pass(es), 1 fail(s), and 0 exception(s).View details | Re-test

#4

Posted by Carsten Müller on November 4, 2012 at 11:16am
Status:active» needs review

#5

Posted by System Message on November 4, 2012 at 11:52am
Status:needs review» needs work

The last submitted patch, user_reset_password_privacy-1521996-3.patch, failed testing.

#6

Posted by C_Logemann on November 4, 2012 at 12:37pm

I agree with the privacy issue.
I can imagine a lot of strategies how to handle the password reset in different ways.
The default handling of the core should be very save (like the strategy above) and a more complex or more open strategy can be realized with contrib modules.

#7

Posted by Carsten Müller on November 4, 2012 at 1:39pm

fixed the test and fixed the patch

AttachmentSizeStatusTest resultOperations
user_reset_password_privacy-1521996-7.patch4.64 KBIdlePASSED: [[SimpleTest]]: [MySQL] 47,589 pass(es).View details | Re-test

#8

Posted by Carsten Müller on November 4, 2012 at 1:39pm
Status:needs work» needs review

#9

Posted by C_Logemann on November 4, 2012 at 2:08pm

About patch of #7
Test with existing user OK.
Test with not existing gives the following error:

Notice: Undefined index: account in user_pass_submit() (line 102 of core/modules/user/user.pages.inc).

#10

Posted by Carsten Müller on November 4, 2012 at 3:30pm

fixed the warning from #9
fixed whitespaces

AttachmentSizeStatusTest resultOperations
user_reset_password_privacy-1521996-10.patch4.7 KBIdlePASSED: [[SimpleTest]]: [MySQL] 47,599 pass(es).View details | Re-test

#11

Posted by Rob C on November 11, 2012 at 10:32am

Great stuff! but i do have 1 question:

Is it an idea to make this a configurable option? E.g. "B.S. mode" enabled? I had the same problem with a module i was working on to resend a user's name via e-email via a similiar way pass reset works. I ended up creating a config option that is enabled by default, so the admin has the choice. (because sometimes you just want to get the real info.)

Can (obviously) also start a new feature request / bug ones this issue is fixed. (I'll add it to my list of wanna-haves anyway, for when i have some time left. Thinking about making this a site wide option, used by multiple functions, registration / contact form can also make use use of it, if only for pranksters / bots.) And added it to the list of related on #1837054: [META] Refactor account workflow (and config)

#12

Posted by YesCT on November 14, 2012 at 7:04am

updating issue summary

#13

Posted by webchick on November 14, 2012 at 9:00am
Category:feature request» bug report
Priority:major» normal

This seems like something we could do at any time and not something that would be subject to feature freeze, so moving to a bug. However, since it's simply a security hardening thing, I'm making it a normal bug.

#14

Posted by Dave Reid on February 6, 2013 at 7:02am
Issue tags:+Privacy improvements

#15

Posted by YesCT on February 12, 2013 at 2:56am

making it configurable could be in the scope of this issue. I dont think we need a new feature request right away. lets see what we can do here.