Tyler Romeo wrote:
Wait a second. Concerning the password reset,
currently it uses the
user_newpassword field, which means the user is required to reset their
password upon login. How is this any different than using a reset token,
where the user supplies the reset token and changes their password?
Thanks Tyler, I was wondering the same.
Tyler Romeo wrote:
The password length is whatever
$wgMinimalPasswordLength is set to, and
according to DefaultSettings.php it's 1 :P. Maybe we should increase the
length of passwords from User::randomPassword.
But we never generate random passwords shorter than 10 characters.
(includes/User.php line 859) We can increase that hardcoded value as
much as we want.
Derric wrote:
The other thing though that can be done with tokens
that can't be done with
passwords (at least without violating user expectations) is making the token
expire. Having the randomly generated token/password expire after a day or so
greatly reduces the amount of time available for an attack.
Our temporary passwords do expire.
Daniel Friesen wrote:
- Usability: Forcing the user to manually enter the
token is a very bad
user experience. We have good email confirmation tokens but don't bother
to do password resets the same way.
- Security: Because the temporary password is being entered by the user
it ends up being much shorter than it should be. The temporary passwords
have really low entropy
It's using MWCryptRand, 46 bits. It could be improved,
but it's not that
bad.
and if we expired them any later than we do now
it would theoretically be possible to brute force a password reset.
Frankly right now if someone was persistent enough to brute force
randomly and make a second reset after the first expires they may
actually have a sane enough chance at brute forcing into an account.