Last modified by Vincent Massol on 2024/02/26 17:54

Show last authors
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.

Get Connected