On Sun, 30 Oct 2011 10:21:42 -0700, Svip svippy@gmail.com wrote:
On 26 October 2011 13:55, William Allen Simpson william.allen.simpson@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.