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é