Wiki source code of Limit number of login attempts until user gets blocked
Last modified by Vincent Massol on 2024/02/26 17:54
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | The main goal of the feature is to prevent a bot to bruteforce a password by trying login on XWiki. | ||
2 | |||
3 | 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. | ||
4 | |||
5 | == Parameters == | ||
6 | |||
7 | |||
8 | |||
9 | At least three parameters should be taken into account for this feature: | ||
10 | |||
11 | * the number of trials | ||
12 | * the time window for this number of trials | ||
13 | * the action to perform in case the limit is reached | ||
14 | |||
15 | == Blocking strategies == | ||
16 | |||
17 | |||
18 | |||
19 | We can imagine several strategies that might prevent a bot to try login several times. | ||
20 | The strategies are ordered by priority: | ||
21 | 1. **Use a captcha** ((( | ||
22 | Display a captcha when the limit is reached, the login can be performed only if the captcha is answered. | ||
23 | ))) | ||
24 | 1. **Block the user until manual activation** ((( | ||
25 | 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. | ||
26 | 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. | ||
27 | ))) | ||
28 | 1. **Block the user for a given amount of time** ((( | ||
29 | 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. | ||
30 | ))) | ||
31 | |||
32 | == Implementation questions == | ||
33 | |||
34 | === Threshold computation mechanism === | ||
35 | |||
36 | What info do we need to keep in order to perform the threshold computation? | ||
37 | 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. | ||
38 | |||
39 | === Information storage strategy === | ||
40 | |||
41 | Footprint of the information to store. | ||
42 | Based on wiki of 1000 users and a strategy of 3 trials. | ||
43 | |||
44 | 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. | ||
45 | 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. |