Quelle protection existe-t-il contre les attaques brute-force sur le login ?
Nous limitons grandement l'efficacité des attaques de force brute par l'utilisation de la fonction de hachage BCrypt.
Nous avons choisi BCrypt car il est lent. En effet l’algorithme BCrypt applique la technique de key stretching qui consiste à se protéger des attaques par force brute en augmentant le temps nécessaire au traitement de chaque tentative de clé.
Cette "lenteur" est paramétrable dans JCMS via la propriété JCMS channel.bcrypt.log2rounds (par défaut 10). Il s'agit d'une valeur comprise en 4 et 30 inclus
4 : très rapide, peu sécurisé
30 : très (trop) lent, très sécurisé
channel.bcrypt.log2rounds: 10
A titre purement indicatif (et très approximatif), voici quelques estimations du temps de génération/validation d'un hash BCrypt avec l'implémentation JPlatform, et une extrapolation du nombre de tentative possibles d'attaque de type brute force.
Temps de hashage ou de vérification d'un mot de passe
Estimation du nombre de tentatives de vérification de mot de passe possibles en cas d'attaque de type brute force
log2 (rounds)
Observé
Estimé (ms) [1]
par seconde
par minute
par heure
par jour
4
1 ms
1,26
794
47662
2859752
68634065
5
3 ms
2,52
397
23831
1429876
34317032
6
6 ms
5,04
198
11915
714938
17158516
7
11 ms
10,07
99
5957
357469
8579258
8
20 ms
20,14
49
2978
178734
4289629
9
44 ms
40,28
24
1489
89367
2144814
10 [2]
84 ms
80,57
12
744
44683
1072407
11
162 ms
161,13
6
372
22341
536203
12
316 ms
322,27
3
186
11170
268101
13
627 ms
644,53
1
93
5585
134050
14
1 s
1289,06
0,8
46
2792
67025
15
2 s
2578,13
0,4
23
1396
33512
16
5 s
5156,25
0,2
11
698
16756
17
10 s
10312,5
0,1
5
349
8378
18
20 s
20625
0
2
174
4189
19
41 s
41250
0
1
87
2094
20
1 min 23 s
82500
0
0,7
43
1047
21
2 min 42 s
165000
0
0,4
21
523
22
5 min 29 s
330000
0
0,2
10
261
23
10 min 59 s
660000
0
0,1
5
130
24
22 min 21 s
1320000
0
0
2
65
25
44 min 24 s
2640000
0
0
1
32
26
- [3]
5280000
0
0
0,7
16
27
- [3]
10560000
0
0
0,3
8
28
- [3]
21120000
0
0
0,2
4
29
- [3]
42240000
0
0
0,1
2
30
- [3]
84480000
0
0
0
1
[1] extrapolation en sur base du plus grand loground2 testé : 44 minutes pour loground2=25 [2] valeur par défaut dans JPlatform [3] test interrompu avant obtention du résultat
Un cas particulier existe pour les AuthKey, qui doivent être traitées plus rapidement (car elles peuvent se trouver dans des liens contenus dans des mails ou des newsletters) :
auth-mgr.authkey-bcrypt-log2rounds: 4
A savoir :
quand on augmente d'1 la valeur du log2(rounds), le temps de calcul est multiplié par 2.
le temps qui a été mis pour générer un hash est le même temps nécessaire pour le vérifier (puisqu'il y a nouvelle génération pour comparaison avec les mêmes valeurs que le hash côté serveur).
La valeur par défaut du log2(rounds) dans l'implémentation que nous avons choisie est 10.
Un hash qui aura été généré avec un paramétrage faible sera toujours valide si on change le paramétrage (car le nouveau paramétrage n'est pas utilisé dans ce cas là), mais bien sûr la complexité de ce hash sera ancienne et pourra subir une attaque moins coûteuse. Après changement de la propriété, il faut donc impérativement modifier les mots de passe pour bénéficier du nouveau réglage.
Par ailleurs la fonction de hachage est également utilisée pour la génération des cookies, et des clés d'authentification. Ces derniers sont composés à partir d'une combinaison :
du résultat de la fonction de hachage sur le mot de passe de l'utilisateur
(optionnelle) d'une valeur connue uniquement du serveur, définie par la propriété auth-mgr.cookie.server-seed pour les cookies auth-mgr.authkey-server-seed pour les clés d'authentification
Il est recommandé d'affecter une valeur afin d'augmenter la sécurité de l'application
le changement de cette valeur invalide tous les cookies ou clés déjà émis
ces propriétés ont été introduite dans JCMS 8.0, et leur valeur par défaut est vide par soucis de compatibilité
