johanee

The problem appears to be that Absolute Privacy replaces the pluggable function wp_authenticate with a non compatible version.

If it instead used one of the available filters the plugins could probably coexist peacefully.

Can you give more details?

I’ll be working on this tomorrow — a few changes to the login handling 2.7.1->2.8 — but during my 3 minutes check I was at least able to log in.

Sorry, fails in same way:

wp_cache_ob_callback, wp_cache_get_ob, current_time, get_option, wp_load_alloptions, wp_cache_get

Installed files from zipped development version, will report back tomorrow.

Ok, I can report that just changing current_time() to gmdate solves (or hides anyway) the problem for me. Before I got an error every hour or so. Now 24 hours without trouble.

So the rest of the objects seems to survive long enough.

It is an inelegant hack and doesn’t solve whatever the root of the problem is.

What I did was changing current_time() in wp-cache-phase2.php : wp_cache_ob_callback() to gmdate(‘Y-m-d H:i:s’).

If you care that the time is printed correctly in the html comment it should be: gmdate(‘Y-m-d H:i:s’, (time() + (<your gmt offset> * 3600)))

Huh, weird.. ??

The server does use php 5 (5.2.4).

I’ll replace current_time() with a plain gmdate() and see if I’ll get new errors from something else.

Ok, that wasn’t altogether easy.

Backtrace is:
wp_cache_ob_callback, current_time, get_option, wp_cache_get

The problem here is that it is executed before the $wpdb object is set up.

Meaning it has to be from the early include of advanced-cache.php.

Not knowing the cache code a wild guess might be it somehow gets called early through the cron code?

We have also started to get this exact error in the log since enabling the plugin. I haven’t been able to trigger it myself. I’ll see if I can get a backtrace to see what it happening.

Just to clarify regarding stored globally. Everything: retries count, lockouts, is stored for each Internet address.

Problems with this is:
– Admin wanting to test that it works! ?? (fortunately first few lockout for IP is only 20 minutes by default..)
– If you are extremely, extremely unlucky with a dynamic IP

We do not really care about the case of IP legitimately locked out because they failed way too many times (4*4 times in default before the long lockout) and then unable to log in to their own account.

Adding an additional element (an user name, chosen by attacker) to store doesn’t really help much and adds storage space and complexity.

Regarding reseting lockouts I think the available options should be enough — any way around an enforcement mechanism is a potential weakness — though I’m certainly open to be persuaded otherwise.

Yes this is by design, see the separate topic:
https://www.ads-software.com/support/topic/235909

Perhaps, though, it might be interesting to include a button to do a reset of retries, in the admin panel to use while testing things?

This is very much by design.

Otherwise it would be possible to attack admin for allowed retries – 1, and then log in to a normal account to reset count.

It would be possible to keep track ofretry count for each user tried (for each IP), but that seems rather unnecessary.

Ok, so having actually read what the message said instead of what I thought it said:

Yes, strictly speaking this is an information leak in WordPress and it would be better to give the same error message for any bad user/password combination.

It seems to be possible to keep track of and filter most of the time, and I’ll probably add it to a future version.

Thank you,
Johan

Yeah, I locked myself out a few times during development — good thing to have direct access to the db…

Re: error messages, I agree. This is fixed in version 1.1 — during lockdown all other messages (empty password, …) are filtered out.

Thank you for the comment,
Johan