On Wed, 26 Oct 2011 04:55:11 -0700, William Allen Simpson william.allen.simpson@gmail.com wrote:
I've been around a long time (2003) and have old accounts that I never use, usually explicitly setup to prevent folks from creating accounts with different capitalization for misleading user names in comments.
After SUL, that case variance problem should be handled correctly. But those existing variants could still be re-activated.
Many of these accounts have expired email, so I don't see any notices. Recently, one that has a current email sent me a notice that reads in relevant part:
# Temporary password: YH2MnDD # # This temporary password will expire in 7 days. # You should log in and choose a new password now. If someone else made this # request, or if you have remembered your original password, and you no longer # wish to change it, you may ignore this message and continue using your old # password. # I use fairly long passwords with special characters (a 96 character set including space). This replacement password is much more easily guessed. The account could have been stolen within minutes or hours.
https://secure.wikimedia.org/wikipedia/en/wiki/Password_strength
(Merely 7 case insensitive alphanumeric characters is equivalent to only 40-bits of strength.)
Please update the password generator to use at least 17 characters, with at least some punctuation! (Users reading the text might have trouble noticing blanks, so don't use the space character.)
Of course, I know that various studies show that 12 to 15 characters using a 95 character set are probably enough. And that's fine for the user's choose. But this is an automatically generated replacement, emailed out in the clear. It should be something stronger!
Assuming a scenario where a brute force attacker were able to make 1000 password guesses a second this 7-char [a-zA-Z0-9] password would take 1.14 centuries to crack. And it expires in 7 days. Not to mention, if memcached is being used, we should be rate limiting password guesses.
Admittedly if someone managed to crack into the database and see the contents of the user table within 7 days of submitting the password reset, done on the local system this temp password could take <1s to crack. However that's not really something we should care about. Our user table contains a user_token whichcan be used to fake a login as a user. It's easier to use than it is to crack a temp password. If a site accidentally leaks it's user table it has to reset the user_token column for every user to make the site secure, and with your note likewise they should also reset user_newpassword when they reset user_token. The ONLY advantage they gain from cracking the temp password is the ability to change the e-mail and hold onto the account after the password is reset or the system administrator resets the database's user table.
Maybe we should make a maintenance script to reset these columns.
Admittedly I don't really like the idea of a new 'password'. What I do like the idea of a long cryptorandom reset token on link like we have for e-mail confirmation.