Gregory, thanks for the warning. The toolserver will not work for
this - its using MySQL 5, which optimizes everything very differently.
Plus it is using views instead of tables - again, there are some
optimization bugs associated with that. This really has to be on the
main wiki - this way we could even compare a large wiki vs a small
wiki query optimizations.
One solution would be to disable regex - most queries don't need that.
From my experience, most of the time I need to run
simple join and
lookup queries with various filters. "LIKE" has been used
a few times,
but more often it is simply <,=,>. I guess we can make a list of
On 8/27/07, Gregory Maxwell <gmaxwell(a)gmail.com> wrote:
On 8/27/07, Yuri Astrakhan
Ouch, thanks Simetrical. I guess
"user_password" should not be allowed
in any "explain" queries. Any other risky ones out there?
On the other hand - this only introduces another possibility of a
login - same as going through the regular login page. I can't think
how it would be a security risk - automated running through a list of
md5 hashes. We could implement a memcached solution so that no more
than 10 queries would run per minute.
EXPLAIN SELECT * FROM user WHERE user_name='Simetrical' AND
user_password REGEXP '^[0-7].*'; ... It should only take a maximum of
128 queries to read the entire MD5 one bit at a time starting with no
starting info. This isn't the same as a bruteforce shortcut. You
can't solve this with a delay or a captcha.
There are a bunch of fields that need to be protected (rc_ip, for
example.. user prefs.. watchlist table...). To really make the tool
useful is has to be very flexible in what it accepts. I looked at
building something like this for toolserver users a while back and
decided it would be too much work to get it right.
Wikitech-l mailing list