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é
0 vote