Limit number of login attempts until user gets blocked

Last modified by Ecaterina Moraru (Valica) on 2019/07/23 14:19



The main goal of the feature is to prevent a bot to bruteforce a password by trying login on XWiki.

Basically the idea is to perform an action to prevent the user trying to login again, when he failed to login several times in a given time window. 



At least three parameters should be taken into account for this feature:

  • the number of trials
  • the time window for this number of trials
  • the action to perform in case the limit is reached 

Blocking strategies


We can imagine several strategies that might prevent a bot to try login several times.
The strategies are ordered by priority: 

  1. Use a captcha

    Display a captcha when the limit is reached, the login can be performed only if the captcha is answered. 

  2. Block the user until manual activation

    The action would be to forbid user to log in in the future: an admin will have to activate it back to allow again the user to log in.
    We can imagine that the admin could either just validate back the user, but also reset his password when validating back the account if he has suspicion that the account is compromised.

  3. Block the user for a given amount of time

    The action would be to forbid user to log in for a given amount of time. When this amount of time expires the account is automatically activated back.

Implementation questions

Threshold computation mechanism

What info do we need to keep in order to perform the threshold computation?
The last N-1 failed attempts for each login and their dates, where N is the number of authorized failures looks like the least we need to keep. 

Information storage strategy


Footprint of the information to store.
Based on wiki of 1000 users and a strategy of 3 trials. 

If we store the dates as long (8 bytes) it would take to keep the information of dates only (not the 1000 associated logins): 24 Kb.
For a strategy of 5 trials, we scale to 40 Kb. It looks scalable to store it in memory, but it would mean that all info would be lost in case of DB restart. 


Created by Simon Urli on 2019/06/18 17:08

Get Connected