Page MenuHomePhabricator

Don't say whether user exists on incorrect login info, for wikis with no anonymous viewing
Closed, DuplicatePublic

Description

Author: MediaWiki

Description:
By default, the messages displayed to a user when failing a login specify what was wrong with the provided credentials. If there is no such user, it says so; if the user is correct but the password is wrong, it says so. This poses a serious security risk, as hackers can use this information to determine what usernames exist and then try to brute-force the password.


Version: unspecified
Severity: minor

Details

Reference
bz11757

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:59 PM
bzimport set Reference to bz11757.
bzimport added a subscriber: Unknown Object (MLST).

river wrote:

but you can already see which accounts exist, on [[Special:Listusers]].

MediaWiki wrote:

I won't reopen the bug myself, but Special:Listusers is not likely to be whitelisted on wikis with $wgGroupPermissions['*']['read'] = false, as mine has.

ayg wrote:

Possibly a reasonable request, but not really of major severity. MediaWiki is not optimized for secrecy of this level, and isn't intended to be, so there are quite possibly other ways to get this info anyway. I'll reopen, unless River or someone else still thinks this would be an unreasonable addition.

MediaWiki wrote:

It's not entirely a huge deal, as the messages can be changed by the wiki's sysops, but having such revealing messages as the default seems rather strange. Thanks, Simetrical!

Please note that even if Special:Listusers is not viewable, api.php is still accessible for anyone (unless it's disabled entirely), so anons will still be able to get a list of users through api.php?action=query&list=allusers

ayg wrote:

(In reply to comment #5)

Please note that even if Special:Listusers is not viewable, api.php is still
accessible for anyone (unless it's disabled entirely), so anons will still be
able to get a list of users through api.php?action=query&list=allusers

api.php should be checking read permissions when it's called. If it's not, that's a fairly serious issue.

(In reply to comment #6)

api.php should be checking read permissions when it's called. If it's not,
that's a fairly serious issue.

It does, on real pages. Not on lists (currently).

MediaWiki wrote:

(In reply to comment #7)

It does, on real pages. Not on lists (currently).

It looks like it's checking, to me. The API call action=query&list=allusers generates an error "Unrecognised value for parameter 'action'" if I don't log in. If I log in, it gives me an HTML pretty-print XML list.

This is a different issue, but I couldn't log in with the API using action=login&lgname=Daniel&lgpassword=mypass

(In reply to comment #8)

It looks like it's checking, to me. The API call action=query&list=allusers
generates an error "Unrecognised value for parameter 'action'" if I don't log
in. If I log in, it gives me an HTML pretty-print XML list.

That's very weird. Are you absolutely sure you spelled everything correctly in the first request?

MediaWiki wrote:

(In reply to comment #9)

That's very weird. Are you absolutely sure you spelled everything correctly in
the first request?

Um, I'm pretty sure, but I'll try it again to confirm. I'm using the URL http://localhost/w/api.php?action=query&list=allusers (the wiki I'm testing is on my computer), and it gives me a list when I log in, and <error code="unknown_action" ...> if I'm logged out. Sure enough, it's confirmed. I'd try on a different wiki to cross-check, but I don't know of another wiki that's access-controlled.

(In reply to comment #10)

Um, I'm pretty sure, but I'll try it again to confirm. I'm using the URL
http://localhost/w/api.php?action=query&list=allusers (the wiki I'm testing is
on my computer), and it gives me a list when I log in, and <error
code="unknown_action" ...> if I'm logged out. Sure enough, it's confirmed. I'd
try on a different wiki to cross-check, but I don't know of another wiki that's
access-controlled.

I've dug into this, and it turned out to be pretty complicated:

  • Who doesn't have read permission, can't do any queries, thus action=query in unavailable (see api.php?action=help when you're logged out).
  • This means ApiBase::extractRequestParams() fails for the main API module (invalid value for action).
  • This in turn means the format parameter can't be read.
  • Since we don't know which format the user wants, we give them a raw error message.

This also happens if you try action=bogus or format=bogus.

MediaWiki wrote:

(In reply to comment #11)

I've dug into this, and it turned out to be pretty complicated:

  • Who doesn't have read permission, can't do any queries, thus action=query in

unavailable (see api.php?action=help when you're logged out).

  • This means ApiBase::extractRequestParams() fails for the main API module

(invalid value for action).

  • This in turn means the format parameter can't be read.
  • Since we don't know which format the user wants, we give them a raw error

message.

This also happens if you try action=bogus or format=bogus.

Is that an unintentional feature? Looks reasonably secure. Doesn't look like the API is an issue for this particular bug.

(In reply to comment #12)

Is that an unintentional feature? Looks reasonably secure. Doesn't look like
the API is an issue for this particular bug.

No, that's intentional (judging by the comments). If you don't have read permission, the API acts like querying isn't even possible (the only options you get as an anon are action=help and action=login).

I added a note on
http://www.mediawiki.org/w/index.php?title=Manual%3APreventing_access&action=historysubmit&diff=324659&oldid=320372 about editing [[MediaWiki:wrongpassword]] and [[MediaWiki:nosuchusershort]] to contain the same text.

However, it can still be determined by:
a) Using the api
b) Asking on a different language.

  • Bug 27751 has been marked as a duplicate of this bug. ***

On private wikis, MediaWiki should use wrongpassword even if the user does not exist.

I'll note that even if the messages are fixed, it's fairly likely a timing attack could still reveal the difference between "user does not exist" and "invalid password".