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. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
