Auto IP Whitelist

[Richard-UK]

Hi

I would like to suggest some form of auto whitelist. As often customers have dynamic IP address on their ADSL connections so setting a static IP address is not a long term solution and anyway requires management.

My suggestion is that after 1 or maybe x successful logins of the selected user(s) from a specific IP address that IP address is auto whitelisted for x days or increase it's allow amount of retries before blocking.

Richard

[codeling]

Something like that has already been proposed, and also written, see here: #24
I do however have security concerns against such an automatic whitelist - see my second comment in the linked issue. So I won't implement this in the "official" version (unless someone comes up with compelling arguments against my concerns).

[Richard-UK]

Well as it has already been proposed there must be demand!

I was thinking per user, mainly admin’s (as they often the customer) complain allot when blocked.
Or the whitelist is only valid for users who had already successfully logged on 1 or x times from that IP address.
Or at least automatically increase the number of retries for them.

[codeling]

Making such a whitelist configurable, maybe even by user, would quite overcomplicate things in my opinion. And I'm still wondering about the benefits - how many users do you have complaining about failed logins?

To sum up: Automatic whitelisting would, in addition to the security concerns mentioned in #24, to be useful it probably would have a complicated implementation (which inevitably also means it would be complex to configure), and have questionable benefits (how often would it really help is hard to determine, depends on the update interval of providers, how well you have configured it, etc.). However, I do want bfstop to be as secure and as easy to configure as possible. So I still don't see a benefit in implementing it.

Another point against it in my opinion is that the usual reason for a legitimate user to have multiple failed logins is if he doesn't remember his password anymore. And there are much simpler procedures in place already for this case than a complicated automatic whitelisting procedure - namely the username/password reset functionality. In my opinion it would be more beneficial to promote that more prominently.
One other thing that could be done to maybe mitigate users complaining because of a block would be to show the "remaining attempts" message (can be enabled under Advanced options). That warning also could include hints to use the password reset functionality, I have added an issue for that for the next version (#69).

That said, I can see benefit in adapting the number of retries however. I'm just not sure if basing that only on single IP's having logged in successfully is a good idea. My current thinking goes more into the direction of coming up with some kind of heuristic of how likely the IP address currently having a failed login is an attacker, and adapting the number of allowed retries to that somehow.

For me for example, running a website for a local association, this could probably be determined by the location of the attacker (however accurate those GeoIP services might be...) - the attackers on my sites usually are from far-away countries and my "real" users more from locations close to me. So I could give e.g. users trying to login from [fill-in-your-favorite-rogue-hacker-state-here] only 3 tries, while I give local users 10 tries.

However, since the ideal strategy for that heuristic will probably also vary wildly with the kind of site (e.g. global vs. local audience) the plugin is installed, I'm not sure if any generally applicable heuristic can be invented.
In any case, I guess I'm rambling on about an entirely different possible future feature here...

[Richard-UK]

Anyway thank you for considering it and of course thank you for what is a very useful (necessary) plugin.

.

-----Original Message-----
From: codeling [notifications@github.com]
Received: Thursday, 23 Jan 2014, 10:44pm
To: codeling/bfstop [bfstop@noreply.github.com]
CC: Richard Jones [RichardJ@nci.co.uk]
Subject: Re: [bfstop] Auto IP Whitelist (#68)

Making such a whitelist configurable, maybe even by user, would quite overcomplicate things in my opinion. And I'm still wondering about the benefits - how many users do you have complaining about failed logins?

To sum up: Automatic whitelisting would, in addition to the security concerns mentioned in #24#24 have a complicated implementation (which inevitably also means it would be complex to configure, therefore error-prone). However, I do want bfstop to be as secure and as easy to configure as possible. So I don't see a benefit in implementing it.

Another point against it in my opinion is that the usual reason for a legitimate user to have multiple failed logins is if he doesn't remember his password correctly anymore. And there are much simpler procedures in place already than a complicated automatic whitelisting procedure - namely the username/password reset functionality. In my opinion it would be more beneficial to promote that more prominently.
One other thing that could be done against users complaining because of a block would be to show the "remaining attempts" message (can be enabled under Advanced options). That warning also could include hints to use the password reset functionality, I have added an issue for that for the next version (#69#69).

That said, I can see benefit in adapting the number of retries however. I'm just not sure if basing that only on single IP's having logged in successfully is a good idea. My current thinking goes more into the direction of coming up with some kind of heuristic of how likely the IP address currently having a failed login is an attacker, and adapting the number of allowed retries to that somehow.

For me for example, running a website for a local association, this could probably be determined by the location of the attacker (however accurate those GeoIP services might be...) - the attackers on my sites usually are from far-away countries and my "real" users more from locations close to me. So I could give e.g. users trying to login from only 3 tries, while I give local users 10 tries.

However, since the ideal strategy for that heuristic will probably also vary wildly with the kind of site (e.g. global vs. local audience) the plugin is installed, I'm not sure if any generally applicable heuristic can be invented.
In any case, I guess I'm rambling on about an entirely different possible future feature here...

Reply to this email directly or view it on GitHubhttps://github.com//issues/68#issuecomment-33177773.

[codeling]

So for the moment I will implement an improved notification feature, so that legitimate users get better informed about how many tries they have left, so that they get a chance to use the "password reminder" functionality before they're locked out (see issue #69).