Username enumeration vulnerability via login & password reset screens

[Aaron Wells]

A user enumeration vulnerability means that an attacker can get a list of legal usernames and/or email addresses from the site. A "bruteforce" user enumeration vulnerability means that if they have a list of potential usernames and/or email addresses, they can verify whether or not each of them is registered with an account in the site.

The Mahara password reset page is vulnerable to this. You can simply go in to https://mahara.org/forgotpass.php and enter username or email after username or email, and get a friendly response indicating whether each one is registered with a user in the site or not.

[Aaron Wells (u-aaronw)]

I'm considering this one a relatively low priority because:

1. It's bruteforce user enumeration, which means you already have to have some idea of which ones are present.
2. There's already a much more direct user enumeration attack available in Mahara: https://bugs.launchpad.net/mahara/+bug/1158625
3. Because Mahara is a social network, usernames are not particularly secret to begin with.

[Aaron Wells (u-aaronw)]

As for solutions, here are a few possible ones:

A. Add a limit to the number of password reset attempts (or at least unsuccessful password reset attempts) that can come from a particular IP address every 5 minutes. (Much like the limit on login attempts per 5 minutes)

B. Add a Captcha mechanism to the password reset page. This can't be the only solution, however, because it's not acceptable for some institutions' accessability standards.

C. Provide exactly the same message to the user on a successful or unsuccessful password reset attempt. Something like "If you entered your username or password correctly, we will send you a password reset email." I don't like this approach because it's not very user friendly, however.

I'm in favor of option A. I'm willing to accept patches for options B and C, but they'd have to be optional, able to be disabled by a config setting.

[Aaron Wells (u-aaronw)]

Leo is working on implementing scenario A, the limit on password reset attempts per IP address in a given span of time.

We also conclude in an IRC discussion that it would be useful to have a per-IP limit on *login* attempts as well. It's a slightly more subtle case:

1. Username enumeration is not a concern with the login screen because we print the same message whether you entered an invalid username or a valid username and invalid password

2. And we also have an existing system that limits the number of password attempts for each username within a short span of time.

3. HOWEVER, an attacker could do a dictionary attack: Try the five most common passwords, on a large list of likely usernames.

So, to prevent attack #3, it would be good to have the per-IP timeout on the login form as well as on the password reset form.

[Mahara Bot (dev-mahara)]

Patch for "master" branch: https://reviews.mahara.org/3032

[Aaron Wells (u-aaronw)]

Have abandoned patch 3032 because it was overkill for us.

[Aaron Wells (u-aaronw)]

It's worth noting, we still haven't fixed this in Mahara itself, because the best fix is some kind of rate-limiting, and that is probably better handled on the server/network level rather than the PHP application level.

[Robert Lyon (robertl-9)]

This is now being handled by Bug 1728473