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.