Flood Control?

Bumping this, hoping for some clarity.

After looking through the code for both, it appears the "Login Security" module uses its own table, "login_security_track" instead of the D7 "flood" table. Also, I don't find any mentions of "flood" in login_security.module or the admin inc file.

Can anyone confirm that Login Security takes precedence over (or otherwise extends) the D7 flood features, and/or that the settings of each won't interfere with the other?

Thanks!

Core flood control takes precedence over login security. It'd probably be good to figure how to get Login Security to leverage core flood control instead of attempting to implement its own thing that would be secondary anyway.

Great. Thanks for the timely update(s)!

FWIW - It seems like some future version of this module might-could also include Username Enumeration Prevention. (since it sounds like it already basically does this). In my mind:

Module - Login Security Basic Settings (core flood control settings)
Submodule (tab) - Login Security Advanced Settings (all the cool stuff in this module)
Submodule (tab) - Username Enumeration Prevention (that module)
etc.

Maybe in the near future I'll have more time to work on contrib features. Would be happy to help, time permitting.

Thanks again!

Why include Username Enumeration Prevention when it's already a stable, independent, working module?

On Username Enumeration Prevention, combining it was just a passing notion, I'm new to both modules. My impression was there was some overlapping and closely related functionality (login_security.module line 239). I understand your point.

Also, and please forgive me if this is already accounted for or discussed, but does revealing the number of remaining flood-controlled login attempts defeat the purpose of obfuscating login error messages? In other words, if a username only has 4 tries left, then that username must(?) have an account.

Thanks!

If that's a concern in your situation, then don't show the "x tries left" message. It's optional iirc.

Yes, it does appear it's optional, thanks.

I guess my underlying question was whether that concern might be already accounted for by the module. As an off-the-cuff example, the module might disregard whether the username actually exists as an account, and show the same counter even for usernames that do not exist on real user accounts, or something similar.

I do understand the practical concerns with storing unknown usernames, etc.

Anyway, thanks for the prompt feedback. It is appreciated.

Why worry about the username - focus on the IP address. Repeated attempts from a single IP to one or many user names should be blocked.

Because right or wrong, standards like PCI focus on username, not IP.

#8, I see your point, but I'd have to imagine that a reasonable percentage of attackers would use a proxy, or switch devices/locations/ISPs.