Livetable results allow reconstructing password hashes using 768 requests

Steps to Reproduce:

Open <server>/xwiki/bin/get/XWiki/LiveTableResults?outputSyntax=plain&classname=XWiki.XWikiUsers&collist=password&password=hash:SHA-512: with one of the characters 0-9 and a-f appended until the user you're interested in is displayed in the result. Repeat this until you have the full password salt and password hash in the URL, after the first 64 characters insert ":". Replace <server> by the URL of the XWiki installation.

Expected result:

Either an error is displayed or all users are always displayed regardless of the input.

Actual result:

The users for which the password query matches are displayed.

This issue doesn't apply to users provided by an external authentication system but with this issue it is also easy to identify users that aren't provided by an external authentication system.

Password hashes in XWiki consist of a 64-character long salt separated by ":" from a 128-character long hash. On average, 8 attempts should be enough to discover a character, meaning that (128 + 64) * 8 = 1536 requests will be required on average to discover a password hash. However, dictionary attacks against the password hash are probably also feasible using, e.g., only the first half of the hash so already 1024 requests might suffice to extract enough information for an offline attack against the password hash.

Update: It turns out that you can use multiple filter conditions that are combined with "OR". This allows, e.g., checking if the hash starts with 0, 1, 2, 3, 4, 5, 6, 7, or not, and thereby basically discovering 1 bit of the password hash with each request. This reduces the attack from on average 1536 requests to just 768 requests to discover the full salt and password hash. After the first 256 requests, the salt is known and just 128 further requests would reveal the first 128 bits of the hash, which should be enough to do a successful offline attack - the probability of finding a password that matches the first 128 bits of the hash but not the remaining ones should be extremely small. Therefore, around 384 requests should be enough for a successful attack on a user's password if the password is weak.

Filtering on password properties shouldn't be possible.