471844 - A tool for resetting the passwords of people still using crypt() to store their passwords

Status: RESOLVED WONTFIX

(Bugzilla :: Administration, task)

Description

[Max Kanat-Alexander]

Attachment: v1

Now that bug 211006 is fixed, administrators may want some way to globally have people reset their passwords (though logging in is enough, too, so maybe they don't have to reset them). In any case, attached is a tool that will allow them to do this.

It also allows you to (optionally) set the users' passwords to "*" so that they can't log in until they do the password reset.

Eventually we could also expose some of this functionality in the admin UI, so that admins could reset users' passwords with an appropriate email (which is a feature that has been requested).

Comment 1

[Frédéric Buclin]

Comment on attachment 355088 [details] [diff] [review]
v1

>Index: Bugzilla/Token.pm

>-    my $vars = {};
>+    my %vars;

That's the single place within all the Bugzilla code that we use %vars and then pass \%vars to TT. Everywhere else, we use $vars and pass it to TT. Please be consistent and revert your changes.


>+    $user->set_password('*') if $force;

It's better to group this line with $user->update in a single |if ($force) {...}| block as this call alone will have no effect at all (even if the user logs in meanwhile).


>+    $vars{'max_token_age'} = MAX_TOKEN_AGE;

While working on timezones, I fixed this code, making your patch to bitrot. We no longer pass MAX_TOKEN_AGE explicitly as templates can already access it via [% constants.MAX_TOKEN_AGE %]. You should look at other places to see how I changed this.



>Index: contrib/reset-crypt-passwords.pl

>+my $from_username = $ARGV[0] || pod2usage({ verbose => 0 });

I don't see a lot of sense to define $from_username. It should be the maintainer IMO, even if this user doesn't exist in the DB.


>+my $user_ids = $dbh->selectcol_arrayref(
>+    "SELECT userid FROM profiles WHERE cryptpassword NOT LIKE '%}'");

In bug 211006, we fixed Bugzilla/Auth/Verify/DB.pm to detect if the password is using an old encryption method, not only crypt(). For consistency, we should do the same here, to make this contrib script reusable in the future (else it's a one-time script which has no reason to live in contrib/ IMO).


>+    print $user->login . "\n";

Shouldn't you define the 'verbose' argument before displaying thousands of lines by default in large installations?


>+ Sends a "password reset" mail to all users who are still using crypt()

s/crypt()/old encryption method/, else I don't want this script in contrib/.


>+  --force     If you specify this option, users *must* reset their
>+              passwords or they will be unable to log in. Please be very
>+              careful when using this--users will only have three days
>+              to do the password reset.

This is unclear for two reasons: first, you don't explain what happens if a user doesn't change his password in the next three days. Secondly, we don't care as the user is free to reset his password himself, even after this deadline.


>+  from-admin  When the users get the email, who should the email say
>+              is doing the password resetting? This should be the

As I said, I don't consider this parameter as useful.



>Index: template/en/default/account/password/admin-reset-password.txt.tmpl

>+[% expiration_ts = token_ts + (max_token_age * 86400) %]

As said above about timezones, the way we define times in emails has changed since I fixed timezone problems. Look at other existing email templates.


>+USING THE ABOVE LINK. (You can verify this fact by going directly to
>+[%+ terms.Bugzilla %] at [% urlbase %] and trying to log in.)

I don't understand the usefulness of the "if you don't believe me, just try yourself" sentence. Drop it, we don't care if the user doesn't belive us.


>+password. If you do not reset your password by that time, you will have
>+to contact [% Param('maintainer') %] in order to be able to log in.

That's wrong. The user simply has to request a new token using the "forgot my password" link in the login page. That's what we should say.

Comment 2

[Frédéric Buclin]

Bugzilla 3.4 is now restricted to security bugs. We will retarget this bug (to 3.6 or later) when it's fixed.

Comment 3

[Max Kanat-Alexander]

I don't think that I'm actually going to do this--we just need those people to *log in*, we don't need them to reset their passwords.