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!
William Allen Simpson wrote:
This replacement password is much more easily guessed. The account could have been stolen within minutes or hours.
Is this true? (Yes, I know that a fast machine can try zillions of passwords per hour in theory, but for a reasonably designed system, certainly not in practice.)
Please update the password generator to use at least 17 characters,
That seems like far too many.
On 26/10/11 13:03, Steve Summit wrote:
William Allen Simpson wrote:
This replacement password is much more easily guessed. The account could have been stolen within minutes or hours.
Is this true? (Yes, I know that a fast machine can try zillions of passwords per hour in theory, but for a reasonably designed system, certainly not in practice.)
Please update the password generator to use at least 17 characters,
That seems like far too many.
In practice, that password is probably much stronger than most users' real passwords.
It might perhaps be worth adding one more character, but the simplest way to increase security on this would be to just put a limit on the number of reactivation attempts for that particular password.
Assuming the seven-character password given, "YH2MnDD", uses the character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible such passwords.
Automatically expiring that temporary password after say, 10 failed reactivation attempts, would reduce the probability of successfully guessing that particular password to around 3 x 10^-12 -- probably safe enough for wiki purposes.
Based on this, I don't think it's likely to be nearly as much of a problem as brute-force attacks on ordinary login passwords that go for the "low-hanging fruit" of users with passwords like "1234" or "password1".
Even these can be substantially mitigated by a mixture of per-account and per-client-IP-address throttling, and CAPTCHAs.
If there's one measure I'd like to see that isn't (as far as I know) yet implemented, it would be to require admins and other privileged users to set strong passwords, perhaps initially by Javascript-based warnings, and later by locking out those accounts completely, after a warning period of perhaps one year.
- Neil
On Wed, Oct 26, 2011 at 11:13, Neil Harris neil@tonal.clara.co.uk wrote:
If there's one measure I'd like to see that isn't (as far as I know) yet implemented, it would be to require admins and other privileged users to set strong passwords, perhaps initially by Javascript-based warnings, and later by locking out those accounts completely, after a warning period of perhaps one year.
+1
Admins should be required (At least at wmf) to use an authenticator, no?
On Wed, Oct 26, 2011 at 9:24 AM, Helder helder.wiki@gmail.com wrote:
On Wed, Oct 26, 2011 at 11:13, Neil Harris neil@tonal.clara.co.uk wrote:
If there's one measure I'd like to see that isn't (as far as I know) yet implemented, it would be to require admins and other privileged users to set strong passwords, perhaps initially by Javascript-based warnings, and later by locking out those accounts completely, after a warning period of perhaps one year.
+1 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
No, maybe stewards but not admins.
On Oct 26, 2011 9:40 AM, "Olivier Beaton" olivier.beaton@gmail.com wrote:
Admins should be required (At least at wmf) to use an authenticator, no?
On Wed, Oct 26, 2011 at 9:24 AM, Helder helder.wiki@gmail.com wrote:
On Wed, Oct 26, 2011 at 11:13, Neil Harris neil@tonal.clara.co.uk
wrote:
If there's one measure I'd like to see that isn't (as far as I know) yet implemented, it would be to require admins and other privileged users to
set
strong passwords, perhaps initially by Javascript-based warnings, and
later
by locking out those accounts completely, after a warning period of
perhaps
one year.
+1 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 26/10/11 14:24, Helder wrote:
On Wed, Oct 26, 2011 at 11:13, Neil Harrisneil@tonal.clara.co.uk wrote:
If there's one measure I'd like to see that isn't (as far as I know) yet implemented, it would be to require admins and other privileged users to set strong passwords, perhaps initially by Javascript-based warnings, and later by locking out those accounts completely, after a warning period of perhaps one year.
+1
Thanks.
Proper password-strength-checking is sufficiently compute- and dictionary-intensive that it should probably be done server-side, during the period when the password is still temporarily available in plaintext during the login operation, and always done after the user logs in successfully, even when the user doesn't have Javascript enabled.
Ideally, it could be also done interactively keystroke-by-keystroke on the password change dialogue, using AJAX callbacks to the server.
All this should, of course, be forced to be done over HTTPS -- as, eventually, should all logged-in or password-related activity of any sort.
- N.
On 27/10/11 00:13, Neil Harris wrote:
Automatically expiring that temporary password after say, 10 failed reactivation attempts, would reduce the probability of successfully guessing that particular password to around 3 x 10^-12 -- probably safe enough for wiki purposes.
The problem with this approach is that it introduces a DoS vulnerability. Unless the username is secret as well as the password, a limit on the number of "guesses" makes it easy to prevent someone from resetting their password, by flooding the system with fake guesses for the target username.
Rate limiting per IP does not suffer from this problem, which is why we use it. Fixing rate limiting so that it doesn't require memcached and is enabled by default would be useful.
As others in this thread have noted, 40 bits of entropy is plenty for this particular application. Guessing of user-supplied passwords is a much more significant threat, and one that is not properly addressed in a default MediaWiki installation.
-- Tim Starling
On 26/10/11 23:30, Tim Starling wrote:
On 27/10/11 00:13, Neil Harris wrote:
Automatically expiring that temporary password after say, 10 failed reactivation attempts, would reduce the probability of successfully guessing that particular password to around 3 x 10^-12 -- probably safe enough for wiki purposes.
The problem with this approach is that it introduces a DoS vulnerability. Unless the username is secret as well as the password, a limit on the number of "guesses" makes it easy to prevent someone from resetting their password, by flooding the system with fake guesses for the target username.
I was working on the assumption that the attackers were unlikely to know that any particular given user is attempting to reactivate their account, so they would have to spam their DDoS across the whole range of valid usernames.
If an outsider knows that one particular account is trying to be reactivated, you are of course completely right, and the above wouldn't work.
Rate limiting per IP does not suffer from this problem, which is why we use it. Fixing rate limiting so that it doesn't require memcached and is enabled by default would be useful.
As others in this thread have noted, 40 bits of entropy is plenty for this particular application. Guessing of user-supplied passwords is a much more significant threat, and one that is not properly addressed in a default MediaWiki installation.
-- Tim Starling
As was said by another commenter, the ultimate solution for this is sending a one-time reactivation link in the body of the email, with a sufficiently long randomly-generated cryptographic token (eg 40 hex digits) embedded in it that entropy issues are no longer relevant, and typeability is also irrelevant, because the user either clicks on the link in their mail client, or cuts and pastes it into their browser.
-- Neil
I'm going to pick on Neil a little, because I know he can take it, but it applies to just about everybody else in this thread.
For shame.
On 10/26/11 9:13 AM, Neil Harris wrote:
On 26/10/11 13:03, Steve Summit wrote:
William Allen Simpson wrote:
This replacement password is much more easily guessed. The account could have been stolen within minutes or hours.
Is this true? (Yes, I know that a fast machine can try zillions of passwords per hour in theory, but for a reasonably designed system, certainly not in practice.)
Please update the password generator to use at least 17 characters,
That seems like far too many.
In practice, that password is probably much stronger than most users' real passwords.
Please don't conflate user choices with our choices. Since the password is generated on demand, the adversary *knows* something was generated and sent.
That's quite different than attacking a random user.
It is our choice to send a weak password in email -- a bad choice.
It might perhaps be worth adding one more character,
Really, how *hard* is it to generate a longer string?
, but the simplestway to increase security on this would be to just put a limit on the number of reactivation attempts for that particular password.
Why would this be simpler? Seems like a lot more code to me.
Assuming the seven-character password given, "YH2MnDD", uses the character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible such passwords.
I really wish folks would at least read a Wikipedia article before making such calculations. :-(
No, you've listed the number of combinations, not the entropy.
No, 40-bits of strength means 2**20 attempts on average. Same order of magnitude as WEP. You remember WEP, the security designed to be easily crackable?
https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy
In 2005, a group from the U.S. Federal Bureau of Investigation gave a demonstration where they cracked a WEP-protected network in 3 minutes using publicly available tools.
Or, maybe, perhaps, you might trust that a well-known long-time security professional is telling you the generated password is too weak. ;-)
Automatically expiring that temporary password after say, 10 failed reactivation attempts, would reduce the probability of successfully guessing that particular password to around 3 x 10^-12 -- probably safe enough for wiki purposes.
No, that's not correct math.
Worse, that would generate a denial of service attack all on its own. All the adversary has to do is send periodic attempts to lock somebody out of their own account.
Moreover, what problem does that solve?
Based on this, I don't think it's likely to be nearly as much of a problem as brute-force attacks on ordinary login passwords that go for the "low-hanging fruit" of users with passwords like "1234" or "password1".
This is the lowest *possible* hanging fruit. We're generating it!
Even these can be substantially mitigated by a mixture of per-account and per-client-IP-address throttling, and CAPTCHAs.
While it would be nice to have better user password checking, and require all login sessions to be over HTTPS, and not use cookies to identify sessions, and many other desirable improvements -- this is the simplest and easiest thing I can imagine!
If there's one measure I'd like to see that isn't (as far as I know) yet implemented, it would be to require admins and other privileged users to set strong passwords, perhaps initially by Javascript-based warnings, and later by locking out those accounts completely, after a warning period of perhaps one year.
Now, that seems much too long a time. I'd make it a prerequisite for being an administrator at all!
On Oct 30, 2011 11:29 AM, "William Allen Simpson" < william.allen.simpson@gmail.com> wrote:
On 10/26/11 9:13 AM, Neil Harris wrote:
Assuming the seven-character password given, "YH2MnDD", uses the
character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible such passwords.
I really wish folks would at least read a Wikipedia article before making such calculations. :-(
No, you've listed the number of combinations, not the entropy.
No, 40-bits of strength means 2**20 attempts on average. Same order of magnitude as WEP. You remember WEP, the security designed to be easily crackable?
https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy
In 2005, a group from the U.S. Federal Bureau of Investigation gave a demonstration where they cracked a WEP-protected network in 3 minutes using publicly available tools.
Or, maybe, perhaps, you might trust that a well-known long-time security professional is telling you the generated password is too weak. ;-)
If you are going to be so insulting, please at least try and be right... You could start by reading the articles you are telling other people to read.
For a random sequence of characters, the entropy is just the base-2 log of the number of combinations, so there is nothing wrong with just calculating the number of combinations. Converting to entropy just makes it easier to compare two passwords drawn from different character sets.
WEP is flawed because it encrypts different parts of the message using related keys, not because it is susceptible to a brute force attack on the password. It is completely irrelevant to our discussion.
To get the average number of attempts, you half the number of combination, you don't square root it. With 40 bits, the average is 2^39 attempts, not 2^20.
On Sun, 30 Oct 2011 05:34:02 -0700, Thomas Dalton thomas.dalton@gmail.com wrote:
On Oct 30, 2011 11:29 AM, "William Allen Simpson" < william.allen.simpson@gmail.com> wrote:
On 10/26/11 9:13 AM, Neil Harris wrote:
Assuming the seven-character password given, "YH2MnDD", uses the
character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible such passwords.
I really wish folks would at least read a Wikipedia article before making such calculations. :-(
No, you've listed the number of combinations, not the entropy.
No, 40-bits of strength means 2**20 attempts on average. Same order of magnitude as WEP. You remember WEP, the security designed to be easily crackable?
https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy
In 2005, a group from the U.S. Federal Bureau of Investigation gave a demonstration where they cracked a WEP-protected network in 3 minutes using publicly available tools.
Or, maybe, perhaps, you might trust that a well-known long-time security professional is telling you the generated password is too weak. ;-)
If you are going to be so insulting, please at least try and be right... You could start by reading the articles you are telling other people to read.
For a random sequence of characters, the entropy is just the base-2 log of the number of combinations, so there is nothing wrong with just calculating the number of combinations. Converting to entropy just makes it easier to compare two passwords drawn from different character sets.
WEP is flawed because it encrypts different parts of the message using related keys, not because it is susceptible to a brute force attack on the password. It is completely irrelevant to our discussion.
To get the average number of attempts, you half the number of combination, you don't square root it. With 40 bits, the average is 2^39 attempts, not 2^20.
And to top it off WEP is a local attack, one where you can brute force at a much higher rate than you can over the latent Internet hitting servers as fast as they can handle your requests.
I do take back my estimate of it taking 1.14 centuries at 1000 guesses/second to brute force the entire password space. That was calculated on the basis of normal passwords which are length-variant as well, but the one we generate is fixed-length so that doesn't apply.
Looking at our code we generate a fixed-length random password: - length 7 or the minimum password length, whichever is larger (minimum password default seams to be 1 so it's usually 7) - one character is always a digit, which character is a digit is random - All other characters are [a-zA-Z]
A digit has 10 possibilities, the alphabet has 26 characters which combined with an upper-lower set is (26*2) = 52 possibilities.
So for one digit placement (ie: #XXXXXX) the number of possible passwords is (10 * 52^6) (ie: [10, 52, 52, 52, 52, 52, 52]), for all 7 digit placements that is multiplied by 7.
(10 * 52^6) * 7 = 1383942676480
So there are 1383942676480 (~1.38 x 10^12) possible passwords to generate.
Going back to the estimate of a theoretical brute force attack able to guess 1000 passwords/second without any rate limiting, that will take 8.95 years to go through the entire password space. If I understand Thomas Dalton's note about halving the number of combinations then that would be an average of 4.5 years.
Given that we expire a temporary password within 7 days after generating it at 1000 passwords/second an attacker will be able to go through (7 * 24 * 60 * 60 * 1000) = 604800000 potential passwords, which when divided by the number of possible passwords is ((7 * 24 * 60 * 60 * 1000) / (10 * 52^6)) = 0.3% of the possible passwords.
And of course, we rate limit password guesses when a cache is available. Though making that a 'we always rate limit password guesses' would be a good idea.
Since the strength of that is already good enough I'd still opt to instead work on the less simple task of replacing our randomized 'passwords' with a generated token embedded in a link.
On 30/10/11 12:28, William Allen Simpson wrote:
It might perhaps be worth adding one more character,
Really, how*hard* is it to generate a longer string?
Have a look at the method User::randomPassword() in the file includes/User.php :
Password is at least 7 characters long and can be made longer with the global $wgMinimalPasswordLength (which will require longer password for everyone).
So we could just change that 7 to 10 and we will get longer temporary passwords.
On Sun, Oct 30, 2011 at 2:20 PM, Antoine Musso hashar+wmf@free.fr wrote:
On 30/10/11 12:28, William Allen Simpson wrote:
It might perhaps be worth adding one more character,
Really, how*hard* is it to generate a longer string?
Have a look at the method User::randomPassword() in the file includes/User.php :
Password is at least 7 characters long and can be made longer with the global $wgMinimalPasswordLength (which will require longer password for everyone).
So we could just change that 7 to 10 and we will get longer temporary passwords.
We could, but why would we? As has been shown by me and others in this thread, any brute force attempt that has a reasonable chance to crack the current passwords would already include an amount of traffic to the Wikimedia servers amounting ot a Denial of Service attack.
On 30/10/11 11:28, William Allen Simpson wrote:
I'm going to pick on Neil a little, because I know he can take it,
Yes, I can ;-)
but it applies to just about everybody else in this thread.
For shame.
My main point here is that (given some simple assumptions about how the site is administered) this is largely a theoretical problem, not a practical one, and there are far bigger problems that need fixing more urgently.
This is not to say that a few more characters in the password, or a long term move to a more secure mechanism using much longer tokens, wouldn't be a good idea, but I don't think it's nearly as big a deal as you currently think, and we have more serious problems than this (see below) which need fixing first.
[snip]
I really wish folks would at least read a Wikipedia article before making such calculations. :-(
No, you've listed the number of combinations, not the entropy.
No, 40-bits of strength means 2**20 attempts on average. Same order of magnitude as WEP. You remember WEP, the security designed to be easily crackable?
https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy
No, you're thinking of a birthday attack, which does indeed takes ~ sqrt(n) guesses on average. A simple brute-force guessing attack, which this would be, takes n/2 guesses on average. In this case, 62^7 ~= 2^41, so you're looking at roughly 2^40 guesses to hit a collision, not 2^20.
A bit of rate-limiting on the password recovery mechanism should be enough to limit this to a reasonable level of security: even with the current 7-character temporary passwords, if the mechanism has a site-wide limit to (say) one forced password reset attempt per second, one account will end up being successfully brute-forced roughly every 30,000 years.
Of course, this would mean that the mechanism could easily be DDoS'd, but that's really no big deal either -- the password reset mechanism is hardly core infrastructure, and, could trivially be tweaked to be more secure -- and yes, adding a few more characters to the password wouldn't hurt.
However, this is way, way, way lower risk than the current risk of brute-forcing low-hanging-fruit user passwords: for every user with a password generated by base64-encoding the output of /dev/random, there will be _thousands_ with passwords like "secret99" and "trustno1".
-- Neil
On 30 October 2011 15:38, Neil Harris neil@tonal.clara.co.uk wrote:
However, this is way, way, way lower risk than the current risk of brute-forcing low-hanging-fruit user passwords: for every user with a password generated by base64-encoding the output of /dev/random, there will be _thousands_ with passwords like "secret99" and "trustno1".
A password from /dev/random is extremely insecure. It is highly susceptible to the "find where they wrote it down because it's far too difficult to remember" attack.
Obligatory xkcd link: http://xkcd.com/936/
On 30 October 2011 15:46, Thomas Dalton thomas.dalton@gmail.com wrote:
On 30 October 2011 15:38, Neil Harris neil@tonal.clara.co.uk wrote:
However, this is way, way, way lower risk than the current risk of brute-forcing low-hanging-fruit user passwords...
A password from /dev/random is extremely insecure.
I don't believe these two statements are in any way mutually exclusive. There are degrees of "extremely insecure" in which "password1" ranks significantly higher than "the password I keep on the post-it in my desk drawer". One is very weak in the face of anyone connected to the internet, one is very weak in the face of anyone who has access to your office. Significantly more people have access to the internet than have access to your office/home/phone/filesystem. Neither threat is negligible, both are worth taking sensible measures to counter. But the point where the conversation loses all sense of perspective is when it loses all level of utility.
--HM
On 30/10/11 15:46, Thomas Dalton wrote:
On 30 October 2011 15:38, Neil Harrisneil@tonal.clara.co.uk wrote:
However, this is way, way, way lower risk than the current risk of brute-forcing low-hanging-fruit user passwords: for every user with a password generated by base64-encoding the output of /dev/random, there will be _thousands_ with passwords like "secret99" and "trustno1".
A password from /dev/random is extremely insecure. It is highly susceptible to the "find where they wrote it down because it's far too difficult to remember" attack.
Obligatory xkcd link: http://xkcd.com/936/
If you keep it in the password cache of your browser, on a password-protected home directory on a laptop, that's probably secure enough for most people -- with a good enough password, that roughly the same level of security associated with an SSH key (long bit-pattern on disk + physical possession of the object with the bit pattern on + passphrase). [regarding passphrase strength -- obligatory XKCD link: http://xkcd.com/538/ ]
Again, we're concentrating too much on the moderately-secure part of the problem -- long-enough passwords used by security-conscious users -- and not paying enough attention to the weaker parts of the system such as the vast number of users (probably including many admins) with weak passwords, and the general failure to force a secure connection between the user and the site for login pages and logged-on sessions.
It's like having a thin cardboard box with a relatively weak wooden lid -- upgrading the strength of the cardboard box is a more urgent task than replacing the lid with a steel safe door.
Once those are fixed, by all means let's then turn our attention to things like temporary password lengths.
-- N.
The reality is that _most_ people use the same username and password everywhere. So an attacker compromises phpBB or Wordpress (or name your favorite vunerable software here) somewhere and just uses those same credentials at other sites. If the user, by chance, didn't use the same password for another site - they probably DID use it for their email. The attacker has the users email address compromised and can simply request a password reset.
Or the attacker could simply use firesheep since SSL logins aren't forced (yet).
Or. Or. Or.
Can we please stop arguing about this now? We've established there is a hundred and one ways to break into someones account. Temp password length seems like a low hanging fruit, but really changing that makes no different (as we've established). Like find something else to argue about that would actually increase security, like attempting to break Ryan's shiny new HTTPS cluster.
On Sun, Oct 30, 2011 at 10:47, Neil Harris neil@tonal.clara.co.uk wrote:
On 30/10/11 15:46, Thomas Dalton wrote:
On 30 October 2011 15:38, Neil Harrisneil@tonal.clara.co.uk wrote:
However, this is way, way, way lower risk than the current risk of brute-forcing low-hanging-fruit user passwords: for every user with a password generated by base64-encoding the output of /dev/random, there will be _thousands_ with passwords like "secret99" and "trustno1".
A password from /dev/random is extremely insecure. It is highly susceptible to the "find where they wrote it down because it's far too difficult to remember" attack.
Obligatory xkcd link: http://xkcd.com/936/
If you keep it in the password cache of your browser, on a password-protected home directory on a laptop, that's probably secure enough for most people -- with a good enough password, that roughly the same level of security associated with an SSH key (long bit-pattern on disk + physical possession of the object with the bit pattern on + passphrase). [regarding passphrase strength -- obligatory XKCD link: http://xkcd.com/538/ ]
Again, we're concentrating too much on the moderately-secure part of the problem -- long-enough passwords used by security-conscious users -- and not paying enough attention to the weaker parts of the system such as the vast number of users (probably including many admins) with weak passwords, and the general failure to force a secure connection between the user and the site for login pages and logged-on sessions.
It's like having a thin cardboard box with a relatively weak wooden lid -- upgrading the strength of the cardboard box is a more urgent task than replacing the lid with a steel safe door.
Once those are fixed, by all means let's then turn our attention to things like temporary password lengths.
-- N.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Oct 26, 2011 at 1:55 PM, William Allen Simpson < william.allen.simpson@gmail.com> wrote:
# 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.)
I do seriously wonder whether it is possible to steal such a password 'within minutes or hours'. My calculation says that to do it within 24 hours, one needs to test 40 million passwords per second. And remember that 'testing' in this case means sending a message to the Wikimedia servers and waiting for an answer. Surely getting over 1000 times the normal number of requests per second (I have no number for the total number of requests, but the number of page requests seems to be around 6000 per second) is something that would not remain unnoticed at the Wikimedia servers for 24 hours.
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.)
The more sensitive way of working, in my opinion, would be to invalidate the temporary password after a certain, low, number of tries, and allow a temporary password only a restricted number of times within a certain period. For example, if the password is expired after 5 failed login attempts, and a new temporary password is only sent once a minute, an attacker is effectively reduced to one attempt per 12 seconds, making cracking a 62-alphabet, 7-character key such as this one a task which takes in the order of one million years.
On Wed, Oct 26, 2011 at 7:59 AM, Andre Engels andreengels@gmail.com wrote:
I do seriously wonder whether it is possible to steal such a password 'within minutes or hours'. My calculation says that to do it within 24 hours, one needs to test 40 million passwords per second. And remember that 'testing' in this case means sending a message to the Wikimedia servers and waiting for an answer. Surely getting over 1000 times the normal number of requests per second (I have no number for the total number of requests, but the number of page requests seems to be around 6000 per second) is something that would not remain unnoticed at the Wikimedia servers for 24 hours.
Ignoring the fact that most wiki's are throttled to 5 login attempts in 5 minutes per IP.
So you can really only check 60 an hour or 1440 a day per IP. So with 114 Billion/hr rate needed and limited to 60/hr you'd need about 2.4 Billion IP addresses.
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.
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.
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.
wikitech-l@lists.wikimedia.org