1

I'm currently hardening the security layer of my web appliocation, and I have some questions about the implementation of a login brute force protection :

  • What storage should I use to store the counter of failed login per user / IP ? Should a simple APC/Memcache entry be enough, or would it require a more stable and persistant storage method, also implying an extra SQL query or file write on every login ? Or even storing them in a session entry (my sessions are handled by Memcache, so it's quite the same).

  • The same question about the system-wide counter (in order to trigger a login lockdown or restriction in case of distributed brute force attemp... )? I think that the persistence here is more critical, but it also imply query/write on every login.

  • What would be the appropriate return response on a detected login brute force attemp ? Should I return an 404 error, an 503 Service unavailable ? Or even going deeper by DROPing or even TARPITing the attacker IP(s) through IPTables/Netfilter ? I'm talking about a real detected brute force attemp, not the case of a user failing some logins because he can't recall his pass.

I originally thought that a cache storage (APC/Memcache) would be enough to store the counter, but I'm fearing that the cache could fail for what reason, making this defense layer ineffective.

For every other considerations, I have already read some nice posts like What-is-the-best-distributed-brute-force-countermeasure and Number-of-attempts-to-brute-force-an-average-password, but feel free to throw any advice, it will be greatly appreciated.

Community
  • 1
  • 1
Claaker
  • 257
  • 2
  • 9

1 Answers1

0

First, you have to identify the correct scope of the data and then be bothered with the speed and the optimization.

As you said, the cache storage might fail. This is a clear indication that your data have a broader scope than the cache. Therefore, you should not store them there. The database is a good alternative.

Now, if you are concerned about the speed (and you should be), it is time to optimize the process. You already have a cache layer, so use it to cache this extra read query. On the other hand, you should not be bothered about the extra update query, as this is the exceptional case that does not affect the overall user experience.

As for your third question, the type of the response to a detected brute force attempt does not matter. What matters is the time: respond with a delay of 20 seconds for example. This should be enough to make brute forcing impossible in this lifetime.

linepogl
  • 9,147
  • 4
  • 34
  • 45
  • The scope point of view helped, I think I'll just get the best of both, and make a cache + mysql storage. If the cache fails, the counters will still be available in the DB, but it will prevent systematic the SELECT read query on every logging if the cache is up. – Claaker Apr 11 '12 at 09:13