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 :
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 :
auth-mgr.cookie.server-seed
pour les cookies auth-mgr.authkey-server-seed
pour les clés d'authentification