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