Protection against brute force login

Features go against latest development version. Sounds like a good idea.

While this sounds good, it has one caveat: it makes a denial of service against an account (eg uid 1) fairly easy. Introducing a delay of several seconds, perhaps increasing slightly after multiple attempts, before displaying an error message might be a better idea.

To add: with delays, one needs to take into account that an attacker can use multiple clients / connections at the same time:
allowing 100 simultaneous, instantenous attemps and a 20 sec delay would limit an attacker to trying 432,000 passwords a day.

I agree tho DOS issue needs to be considered. Perhaps this could be mitigated by banning the individual IP (instead of the entire user account) after the flood limit is exceeded? A large botnet could still overcome this limit... but an attacker with just a small number of machines / IPs would have a harder time.

432 000 seems like too many attempts to allow. A dictionary-based attack would be pretty likely to succeed with that many attempts.

Glad to see that this is considered as a needful feature :)
For small sites with just about 20 users it would be sufficient to set that the individual IP can try for example 5 or 10 times per hour. If the user doesn't remember the password in 5 trys, it's already starting to feel like abnormal usage to me. Well, I hope you Drupal gurus get this thing rolling and implemented in the near future :)

Discussing something does not indicate endorsement.

For small sites with just about 20 users it would be sufficient to set that the individual IP can try for example 5 or 10 times per hour.

No really, I'm not interested in trading one weak spot for another weak spot (blocking AOL proxies is generally not acceptable).

Therefore you need to keep the delay against user account, not remote IP.

15 seconds (seems reasonable, 20 seconds is too close to PHP max execution time) delay after every 3 wrong attempts means 5760 attempts a day which is reasonable and something you will likely notice and do another action.

FYI, this could easily be done as a contrib module so unless there is a great implementation idea and support, it may be better left for contrib.

How about a feature request in akismet module or take the bits from there for new module? It already implementing lots of stuff similar to this one.

This is a tough question.

I like the general idea: after X failed attempts in Y minutes, all login attempts will fail for Z minutes. This is not affected by the fact that an attacker can run simultaneous connections whereas pretty much any "slow down the login process" technique will either have no effect or will tie up extra resources on the server.

However, any such approach also necessarily leaves open a denial of service attack. Of course, just hammering Drupal with requests is a denial attack of its own, and there is nothing Drupal can do to protect itself from botnets, so it isn't clear that adding this additional denial vector is a real change.

One option would be not to enforce the max-failed-attempt rule against uid 1 on the assumption that the admin can be trusted to choose a good password (unlike most users who can't be).

Hm. Does it have to be either an IP or a username lockout? Could it not be a mixture of both?

Example:

I am 3vilh4x0r going through proxy.aol.com 1.2.3.4 and attempt to login as the "root" account 4 times in an hour.
I am 1nn0c3nt4ng3l going through proxy.aol.com 1.2.3.4 and attempt to login to the "angel" account.

Drupal blocks 1.2.3.4 from trying to login to the "root" account for an hour.
Drupal does NOT block 1.2.3.4 from trying to login to the "angel" account.

3vilh4x0r could still brute-force accounts, but it would become much more tedious. And innocent users of proxies don't get snagged.

The one snafu is if the real owner for "root" and 3vilh4x0r are on the same IP (which I guess could happen if you have an enemy at school or something), but that seems like a fairly minor problem to be concerned with.

I realize that my previous message was unclear.

When I said, "after X failed attempts in Y minutes, all login attempts will fail for Z minutes," I meant that as applying all to a single account. X failed attempts to login as user foo in Y minutes will disable all logins for user foo for Z minutes. User bar is unaffected.

I think doing anything with IP addresses will be useless or worse. If we get X failed attempts for user foo in rapid succession, do we really care which IP address it is coming from?

OTOH, imagine a world in which brute-force login attempts are as common as Windows vulnerability scans (i.e. constant for every host on the net). In this case, do we really want to disable logins at all? I'm sure this situation is coming. Maybe we just have to accept password guessing as a fact of life and ignore it.

Why not implement a secondary question / answer after a password has been successfully guessed? Im sure this would discourage many of these douche bags. Also, it would help to lobby and support laws that execute offenders. :)

What is the current status of this? Has a patch been installed or is there any plan for Drupal 6?

Thanks.

Bump.