Daniel Convissor
Forum Replies Created
-
This problem has been addressed in release 0.18.0. Thanks for the report. Please let me know how it goes.
Hi Pete:
Can you please try again and tell me what happens?
–Dan
I see there are a couple Catch 22’s in the code. I’ll work on them.
Hi Beholder:
The plugin does not change passwords just because an attack is taking place. It only changes a user’s password if, upon the specific user logging in, the user name, passsword and/or network component of the IP address match those used by the attacker during the past “Match Time” minutes. The attacker was probably coming in with your user name. What’s your user name?
You mentioned having to change your password twice. Were both times right after logging in? That would mean the attack is ongoing.
IP addresses can’t be relied on for much. Attackers can forge or change IPs. Users come in from different places. I’ll think about remembering existing user’s IP’s.
Thanks,
–Dan
Sir Dean:
The Plugins Trac instance isn’t sending emails. I mentioned it on #wordpress-dev and opened a ticket for it the other day: http://core.trac.wordpress.org/ticket/21166
I’ve been monitoring it manually in the mean time. Saw and replied to your visibility ticket a moment ago.
Thanks,
–Dan
Dean:
Food for thought. Thanks for the researching that, Want to make a patch against a Subversion checkout?
And thanks for paying attention to this plugin’s support threads.
–Dan
Dean:
That seems like it would add significant overhead. Such a filter would be executed each time
gettextis called, which is a LOT.–Dan
Oh, yeah, after saving, make sure the “Settings saved.” message appears at the top.
Works for me. You hit the Save Settings button at the bottom, right? 🙂 Was there an error message at the top of the screen when saving?
Yeah, this is a pain. Sadly, WordPress has their password policy text hard coded in four different places. Plus, that means there’s no filter for overriding it. Very silly. Opening a WP core ticket for this problem is on my to do list.
The only thing I can do at this moment is make my error message specify the needed length and say something like “Ignore what WordPress says.”
Forum: Plugins
In reply to: [Limit Login Attempts] SCARY! Limit Login Attempts lockout bypassed?Hi Johan:
I see the existing code is handling the
auth_cookie_bad_hashaction, but is not set up for theauth_cookie_bad_usernameaction. So users are not protected against horizontal attacks, where the miscreant uses the same hash but changes user names. This is probably why your users are still having problems.That aside, it seems like you’re doing way too much work with cookies in general. It’s not necessary to clear out the cookie. If the person is an attacker, they’re coming back with a different cookie anyway. If it’s a legit user with a corrupted cookie (unlikely), WP won’t let them, force them to log in again, at which point they get a new cookie.
–Dan
Yeah, it is interesting / funny to watch.
Forum: Plugins
In reply to: [Login Security Solution] [Plugin: Login Security Solution] Feature QuestionI don’t want to use lockouts. The FAQ explains why.
While CAPTCHAs can help with some attackers, automated procedures exist for outsourcing people to fill them in if the attacker so desires. My plugin only handles login errors for invalid user names or password, since that’s what the core of WP provides information about. It’d be impractical to support other plugins in this process, sorry.
This change will not be added to the plugin since it can open a vector of attack against legitimate users. Let alone, the email would include only the password being used in the most recent login attempt.
Forum: Plugins
In reply to: [Login Security Solution] [Plugin: Login Security Solution] Manual UninstallFix included in Release 0.14.0. Thanks Dean!