On Wed, 26 Oct 2011 04:55:11 -0700, William Allen Simpson
<william.allen.simpson(a)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.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]