[wp-hackers] Changeset 11804
otto at ottodestruct.com
Tue Aug 11 19:22:36 UTC 2009
Ahhh. Well, in that case it makes more sense to simply disallow blank
activation keys to be passed into the function then. Validate your
if empty($key) die "don't hack me you bastard"; // or similar ;)
Yes, you can force user confirmation as well, but that's not really
solving the problem at hand, just adding another uniqueness test to
find the correct user to reset the password for.
Sent from Memphis, TN, United States
On Tue, Aug 11, 2009 at 2:14 PM, Chris Jean<gaarai at gaarai.com> wrote:
> The problem is that the user_activation_key field is empty unless a
> reset password request has already been sent for the user. If the link
> in the reset password email is clicked, the key is returned to blank
> when the new password is added.
> The only way to have a non-blank key is to request a password reset and
> not click on the password reset link in the email.
> Thus, if you request http://domain/wp-login.php?action=rp&key=, then
> the key validity check is bypassed, a non-user-specific query is
> executed, and the first user that is pulled up by the query will have
> the password reset.
> Chris Jean
> Otto wrote:
>> Not sure what the point of this is, exactly.
>> It basically eliminates an issue where identical activation keys (luck
>> o' the draw) could cause somebody to reset the wrong users password.
>> But that seems pretty low probability to me, given the key randomness.
>> On Tue, Aug 11, 2009 at 3:26 AM, Andrew Ozz<admin at laptoptips.ca> wrote:
>>> Could we get some testing and more "eyes" on
>>> https://core.trac.wordpress.org/changeset/11804 (for the 2.8 branch) or
>>> ,  and  for trunk. They fix an annoyance in
>>> wp-login.php where the password could be reset without the user realizing
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers