Roundup Tracker - Issues

Message6005

Author rouilj
Recipients ThomasAH, ber, ezio.melotti, luke, rouilj
Date 2017-08-26.23:59:56
Message-id <1503791997.9.0.324520258767.issue2550716@psf.upfronthosting.co.za>
In-reply-to
I am working on a simple change that I think handles the worst part of
this issue.

There are two code paths though the PasswordResetAction.

Path one is triggered if the URL invoking the password reset includes
a matching one time key (OTK). If the OTK matches an outstanding
password reset request, the password reset email is sent to the user
at their preferred address. The preferred address is the address that
received the email with the OTK. So displaying the email address here
doesn't matter as the viewer already knows about this address.

Path two is triggered by starting the password reset by entering a
username or any email associated with the account (either the primary
email or any alternate email).

If the user triggered the reset using the account name, displaying the
email is not desired. So I have changed the displayed message to:

  Email sent to primary notification address for <account name>.

If the user triggered a password reset using an associated email
address, showing the email address probably doesn't matter as the user
entered an address that matches a user. In this case I display:

  Email sent to <email address that was entered>.

Note that the existence of a username is kind of obvious since it is
displayed in every place where there is a link to the user. This change
just stops the email address from being exposed.

If the schema access rights are set to hide all of the usernames the
reset mechanism allows probing for usernames and email addresses. If
the probe guesses wrong, an error is raised rather than an "email has
been sent" message.

In this case I would suggest disabling the reset mechanism entirely
(although I am not quite sure how this would be done). Alternatively
implement a captcha, limit reset attempts or use another mechanism
to prevent trying to brute force accounts. See issue2550949 for ideas.

-- rouilj
History
Date User Action Args
2017-08-26 23:59:57rouiljsetmessageid: <1503791997.9.0.324520258767.issue2550716@psf.upfronthosting.co.za>
2017-08-26 23:59:57rouiljsetrecipients: + rouilj, ber, ThomasAH, ezio.melotti, luke
2017-08-26 23:59:57rouiljlinkissue2550716 messages
2017-08-26 23:59:56rouiljcreate