spring-io/cve-2022-22976-bcrypt-skips-saltOutil CLI pour détecter et mettre à jour les hachages de mots de passe BCrypt avec un facteur de travail vulnérable de 31, s'intégrant aux bases de données Spring Security pour la remédiation de CVE-2022-xxxx.
Pour vous aider dans les étapes d'atténuation du CVE-2022-xxxx, vous pouvez utiliser cet outil pour vérifier dans votre base de données les hachages qui doivent être mis à jour.
Après avoir intégré l'application avec votre base de données, l'outil fonctionne en deux étapes.
Pour illustrer cela, une application exemple en mémoire est utilisée.
Sur cette application exemple, vous pouvez exécuter l'étape check, comme ceci :
./mvnw spring-boot:run@check
Cela vérifiera dans la base de données exemple tout hachage BCrypt qui doit être mis à jour.
Ensuite, vous pouvez exécuter l'étape update, comme ceci :
./mvnw spring-boot:run@update
Cela tentera de mettre à jour tout hachage vulnérable détecté dans la base de données exemple.
L'application exemple utilise la classe VulnerabilityCheck fournie pour vérifier et mettre à jour chaque hachage de mot de passe.
AVERTISSEMENT : Ne poursuivez ces étapes qu'après avoir mis à jour votre application pour utiliser un nombre de tours inférieur à 31. L'OWASP recommande actuellement une valeur de 10, bien que sur certains systèmes très puissants, des valeurs aussi élevées que 16 soient utilisées.
L'outil est fourni avec un exemple en mémoire à des fins de test. Vous devrez le remplacer par vos propres classes qui s'intègrent à vos données.
Pour ce faire, commencez par cloner ce dépôt.
Ensuite, remplacez le code du package sample par du code capable d'accéder aux données de mots de passe de votre application.
Vous souhaiterez peut-être écrire du code qui vérifie les mots de passe existants pour voir s'ils sont vulnérables.
Vous voudrez du code qui met à jour les hachages affectés.
Dans les deux cas, vous pouvez utiliser VulnerabilityCheck pour vérifier et mettre à jour un hachage donné.
CONSEIL : Lors de l'écriture du code ci-dessus, tenez compte du nombre de mots de passe que vous devez mettre à jour. N'oubliez pas que la connexion à la base de données peut échouer, que les ordinateurs peuvent planter, que la mémoire peut s'épuiser, etc. Il n'est pas conseillé, par exemple, de charger des millions d'enregistrements d'un coup en mémoire.
Après avoir mis à jour les hachages de mots de passe, vous pouvez maintenant passer à la dernière version de Spring Security. Si vous utilisez la fonctionnalité de mise à jour des mots de passe de Spring Security, lorsque les utilisateurs se connecteront, leur mot de passe sera automatiquement re-haché avec la nouvelle valeur de tours que vous avez configurée.
Q : Comment savoir si mes hachages sont vulnérables ?
R : Ils sont vulnérables s'ils ont été hachés avec la classe BCrypt de Spring Security avec un facteur de travail de 31.
Vous pouvez le confirmer en vérifiant les hachages de mots de passe de votre système gérés par Spring Security.
S'ils commencent par '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31' ou '$2$31', alors ce mot de passe est vulnérable et doit être mis à jour.
Q : Comment modifier mon application ?
R : L'OWASP recommande un facteur de travail de 10 pour BCrypt. Certains systèmes plus puissants utiliseront une valeur aussi élevée que 16. Chaque système est différent et BCrypt est conçu pour pouvoir augmenter le facteur de travail au fil du temps selon les besoins.
Q : Où modifier mon application ?
R : Vous définissez probablement le facteur de travail en construisant un BCryptPasswordEncoder comme ceci :
new BCryptPasswordEncoder(31)
Il peut apparaître dans une définition de bean comme ceci :
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder(31);
}
Vous pouvez chercher cette chaîne et la modifier. Notez que le facteur de travail peut être piloté dans votre application par une propriété externe, ce qui signifie que vous voudrez alors le modifier dans votre configuration externe.
Q : Je viens de mettre à jour Spring Security et maintenant certaines ou toutes les connexions et inscriptions d'utilisateurs restent bloquées. Que s'est-il passé ?
R : Depuis Spring Security 5.5.7+, 5.6.4+, 5.7.0+, les hachages de mots de passe indiquant un facteur de travail de 31 -- par exemple, commençant par '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31' ou '$2$31' -- prendront 2 à 3 jours pour terminer chaque calcul de hachage. Pour remédier à cela, vous devrez configurer Spring Security pour utiliser un nombre de tours inférieur. Ensuite, utilisez cet outil pour mettre à jour les hachages de mots de passe vulnérables.
Q : J'ai effectué les trois étapes recommandées (modifier la configuration de BCryptPasswordEncoder, mettre à jour les hachages de mots de passe et mettre à jour Spring Security).
Les hachages de mots de passe modifiés ne passent pas à mon nouveau facteur de travail configuré.
Que dois-je faire ?
Assurez-vous qu'un bean de type UserDetailsPasswordService est publié.
Ce bean est ce qui est utilisé pour mettre à jour les mots de passe vers une nouvelle valeur de log rounds BCrypt.
Q : Pourquoi Spring Security ne peut-il pas simplement mettre à jour les mots de passe vulnérables au moment de la mise à niveau sans avoir besoin de cet outil ?
R : D'abord, parce qu'avec la dernière version de Spring Security, les hachages de mots de passe avec un facteur de travail de 31 sont correctement calculés et prennent donc 2 à 3 jours chacun. Il est irréaliste de supposer que ce coût est raisonnable pour des applications.
Deuxièmement, Spring Security ne prend en charge que l'augmentation du facteur de travail (par exemple de 10 à 12), pas sa diminution (par exemple de 31 à 10).