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