johanee

Interesting. Yes there should be a log, I’ll take a look at it.

Kind of, but not really. ?? It’s an interesting idea though.

0 lockout time will not work. You can use a very large value for a similar effect.

The max values are probably 35791394 minutes and 596523 hours (68 years or so). I think. I can’t check right now.

Also note that you can only clear all lockouts, not one at a time. I’ll probably fix this in a future release.

Make sure you know what to do if you lock yourself out.

Only new lockouts are logged (not failed attempts). Unless there are new lockouts nothing will be shown.

Have the lockout statistics increased since you turned on the logging?

No, they cannot use a false IP address to make login attempts.

As for an attempt using a large number of IP addresses (many computers): it doesn’t really help the attacker much as long as you have a good password (12+ truly random characters). We’re talking age of the universe time-frames here.

Once they get the longer lockout it is for 24 hours.

Attempts (a mistake or three?) gets reset after 12 hours as long as it is few enough it does not result in a lockout.

The reasoning is:
1. some people reported confusion/irritation that the warning remained “the next day”.
2. the security is still strong with 12h for retries to reset.

(above post is from me; got confused by different accounts)

I cannot comment on your legal situation.

If you are under active attack I would recommend:
1. Make sure you use strong passwords (12+ truly random characters). Personally I use a password manager and 15-20 character passwords because, why not?
2. Most bot-style attacks go for the “admin” user. You might want to avoid this username if possible.
3. Perhaps strengthen the plugin options somewhat: 2-3 allowed attempts, 24h for retries to reset.

If you have a strong password it is almost impossible to brute force it when login attempts are limited. We’re talking age of the universe timespans here.

If they truly hammer your site it is still annoying of course, and possibly a performance/DDOS issue if they go all out. In that case you might want to look into blocking the IP in htaccess.

Thank you. I’ve gotten a new version, and will include it with the next release.

Ok,

I’ll put it on the todo list, though it might have to wait for me to finaly get version 2.0 out the doors.

One thing to consider is if this new behavior should always happen when the plugin is network activated, or if it should still be possible to use in the current “one site at a time” mode.

Hi,

Thanks for taking the time to test things: more eyes makes less bugs!

I won’t be able to really test this until this evening, but I thought I’ll mention how it is currently supposed to work and give a potential explanation for the observed behavior:

“Retries valid” duration is set at the time of the last attempt — we store when they will time-out rather than when they happen — and any new failure will reset this value using the currently configured duration.

(This means if you made the failed attempt before changing the duration it would still use the old value.)

I’ll test it and check the code in question later today.

Re: confusing wording. I’ll take a look at improving the text.

Thank you,
Johan

I don’t generally use multisite unfortunately. What functionality would you need from the plugin?

Interesting! The translation is from: https://www.ads-software.com/support/topic/plugin-limit-login-attempts-dutch-translation

I guess he used the wrong .po file. I “fixed” the filename without checking the content. The compiled .mo files looks like it might be correct though, so it still should work though. Possibly.

I’ll send him a mail and check if he still has the .po file.

Thanks for noticing!

It should use the same language as WordPress itself does.

( More details about localized WordPress can be found here: https://codex.www.ads-software.com/WordPress_in_Your_Language )

The language files for the dutch language are: limit-login-attempts-nl_NL.[po|mo]

… and thank you for considering it an excellent plugin! ??

No, this is very much by design.

Otherwise it would be possible to try “admin” for allowed retries – 1, and then log in to a normal account to reset count. Repeat until password broken.

To make that work we would have to keep track of number of retries for every user for every IP, but that would allow a single IP to fill up the DB — not good.

Nor can we keep track only per user as that would allow denial of service attacks against other users.

When you make mistakes you’ll get an ugly warning until the retries are reset. I don’t think that is too much trouble really.

I can recommend using a password manager. ??

Also, as this is the fifth time I’m answering this question I’ll put it in the FAQ.

Of course there’s the ‘remember me’ function.

Yes, right. So really no need for a whitelist — good!