On Sun, 30 Oct 2011 10:21:42 -0700, Svip <svippy(a)gmail.com> wrote:
On 26 October 2011 13:55, William Allen Simpson
<william.allen.simpson(a)gmail.com> wrote:
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.)
You do not seem to understand how they get access to your password
these days. Far fewer people try to get through the front door. Most
systems have methods against brute-forcing (e.g. waiting for 5 seconds
on every third wrong guess, etc.). So brute-forcing is not desirable
against the system you are trying to hack (unless you wish to deny it
service).
The most likely scenario is an attempt to obtain either the database
through SQL injections (probably tricky on a MediaWiki set up) or
through your cookie. Most systems use a system where the hashed
salted (I hope) password is saved in the cookie. Somehow getting your
cookie will allow them to bruteforce the hashed sum. Although,
depending on your system this can take from a few hours to a couple of
years.
Few systems are going to walk up to the front door and try to knock
itself in. Your system will discover the behaviour if it is clever
enough.
No good system EVER stores the user's password in a cookie, no matter
how
much it's hashed, salted, or fried...
There is no good rationale for it (besides the exception like say
phpMyAdmin where the password is not being used for auth but is actually a
piece of data passed on to another system). A good system will only use
either a session token or another type of randomly generated token like
the user_token we use for 'remember me' logins.
Session tokens aside since those expire and are php generated iirc. Our
setToken code that creates a user_token is an md5 of the wiki's secret
key, an mt_rand from 0-2147483647, wiki id, and the user's id.
Now since what matters in a general brute force here is the number of
possible guesses, the relevant number is how many possible keys can md5
output. Now doing this the lazy way md5() outputs a 32 char hexadecimal
string. So that's (16^32) = 3.4 x 10^38 possible keys to brute force.
Admittedly you have as long as it takes for the user to decide they feel
like changing their password, and there is no rate limiting for basic web
requests, but the search space of md5 output looks to be so large I can't
really calculate how many centuries it would take to search.
So given that md5 is so large (and if you have a problem with that, then
convince domas it's worth a schema update to switch to a larger hash
algorithm) a more productive attack attempt would be to instead brute
force based on known information. If an attacker is able to get a wiki to
expose their secret key, know the wiki id used when the user last had a
password change, and get the user's id. Then they only have 2147483647
possible tokens they need to brute force which would probably take just a
few days to brute force.
That said a wiki's secret is... well, supposed to stay secret. And it's a
very long randomized string so even if you tried to build a rainbow table
of every possible secret key + mt_rand result with your own wiki id and
user id using a local machine where you can hardware accelerate things and
say generate 100 trillion of these entries a second and compare that with
the user_token you are served personally. I don't believe even then you
could brute force a wiki's secret key in any reasonable amount of time.
Even though I say that, the worst thing would probably be a small wiki
being loose with their secret key and not bothering to randomize it. Given
that, it would probably be a good idea to try and mix in some sort of
crypto-random source into the data to be hashed if we have any available.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]