En attendant la version 4.6 LTS d'Ibexa DXP, examinons une fonctionnalité utile qui a été introduite dans la version 4.5 en mai.

Fuites de mots de passe

Des fuites de mots de passe ont lieu en permanence. Parfois, les attaquants s'en prennent à des utilisateurs spécifiques, mais le plus souvent, une vulnérabilité dans un logiciel ou un service est exploitée pour s'emparer de vastes ensembles de données d'utilisateurs, y compris parfois des hackages de mots de passe. Dans les systèmes mal conçus, même les mots de passe en clair peuvent être divulgués. Ces "dumps" sont vendus à des fins lucratives et achetés par ceux qui souhaitent tirer profit des données des utilisateurs, par exemple par le biais de rançongiciels, de l'hameçonnage ou d'autres délits. Ces exploits sont facilités par le fait que les utilisateurs utilisent souvent le même mot de passe pour plusieurs services différents. Que pouvons-nous donc faire pour protéger nos utilisateurs ?

Lorsque une fuite de mot de passe arrive, les propriétaires de services doivent bien sûr informer leurs propres utilisateurs qu'une violation s'est produite. Le règlement GDPR de l'UE impose de lourdes amendes aux entreprises qui ne le font pas. Mais même lorsque les utilisateurs sont informés, feront-ils ce qu'il faut et changeront-ils leurs mots de passe sur tous les services où ils ont utilisé le même mot de passe ? Pas toujours, ce qui les expose à d'autres attaques.

Les chapeaux blancs à la rescousse

L'avantage de ces brèches, c'est qu'elles finissent par se retrouver sur des forums publics où des personnes bienveillantes peuvent également s'emparer des données. L'un d'entre eux est Troy Hunt, de Microsoft, qui a mis en place le service https://haveibeenpwned.com, lequel met les noms d'utilisateur et les mots de passe fuités à la disposition de tous, avec possibilité de recherche, gratuitement. En quoi est-ce une bonne chose, me direz-vous ? Tout d'abord, vous pouvez effectuer une recherche à partir de votre propre adresse électronique pour savoir si vos données ont fait l'objet d'une fuite et à partir de quel endroit. C'est certainement utile pour ceux qui savent que c'est possible, mais l'API permet d'aller plus loin, en aidant à sécuriser même ceux qui ne connaissent rien à la sécurité des mots de passe.

Grâce à l'API, les propriétaires de sites web peuvent vérifier si le mot de passe a été divulgué chaque fois qu'un utilisateur crée un nouveau compte sur leur site ou modifie son mot de passe. Nous ne pouvons pas vérifier les mots de passe existants puisque nous ne les avons pas, nous n'avons que les hachages. Nous pourrions vérifier le mot de passe à chaque fois que les utilisateurs se connectent, mais cela se traduirait par un grand nombre de requêtes API inutiles pour les mêmes mots de passe, de manière répétée. Nous devons à Troy Hunt d'utiliser son service de manière efficace.

Vérification des mots de passe dans Ibexa DXP

Symfony a implémenté l'API haveibeenpwned en tant que contrainte NotCompromisedPassword, qui peut être utilisée comme n'importe quelle autre contrainte dans un validateur. Nous avons utilisé cette contrainte comme règle de validation de mot de passe configurable dans Ibexa DXP. Depuis la v4.5, elle est prête à être utilisée.

Pour éviter les surprises lors de la mise à jour, cette nouvelle règle de mot de passe n'est pas activée par défaut. Mais il est facile de commencer à l'utiliser : Dans le backend DXP, modifiez le type de contenu Utilisateur. Développez les détails de la définition du champ Compte d'utilisateur. Cochez la case "Le mot de passe ne doit pas être contenu dans une brèche publique" et enregistrez le type de contenu. Et le tour est joué !

Pendant que vous êtes ici, vous pouvez considérer les autres paramètres de la règle du mot de passe. J'ai déjà écrit un peu à ce sujet, voir la section "Informations de connexion et d'utilisateur" dans l'article de blog sur la liste de contrôle de sécurité.

Mais est-il sûr d'envoyer des mots de passe à une API externe ?

Non ! C'est donc une bonne chose que nous ne fassions pas cela. Prenons le temps d'apprécier l'intelligence de son fonctionnement. À première vue, on pourrait penser qu'il n'y a que deux façons d'effectuer cette vérification : Soit nous envoyons le mot de passe (ou un hachage de celui-ci) à l'API, qui vérifie si le même mot de passe existe dans sa base de données et renvoie une réponse oui/non. Même si Troy Hunt semble être un homme honnête, nous ne devrions pas lui faire confiance, ni à son service, à ce point.

Nous pourrions aussi télécharger la base de données entière de ses serveurs, l'installer sur notre serveur et la parcourir chaque fois que nous voulons vérifier un mot de passe. Cela serait lent et prendrait beaucoup d'espace, et bien sûr nous devrions la mettre à jour fréquemment. Nous sommes en fait autorisés à le télécharger, mais nous ne le voudrions pas. Quelle autre solution pourrait donc exister ?

La solution : le k-anonymat

La solution intelligente se situe à mi-chemin entre les deux options ci-dessus. Nous créons un hachage du mot de passe que nous sommes sur le point de vérifier, en utilisant le même algorithme que celui utilisé par l'API. Nous prenons ensuite les cinq premiers caractères du hachage (une petite fraction) et les utilisons comme entrée dans une requête de plage adressée à l'API. L'API consulte sa base de données et renvoie une liste de tous les hachages commençant par les mêmes cinq caractères, soit environ 800 à 1 000 entrées.

Nous effectuons ensuite une recherche locale dans cette courte liste, ce qui ne prend pas beaucoup de temps. Soit le hachage de notre mot de passe se trouve dans cette liste, ce qui signifie que le mot de passe doit être rejeté comme invalide et que l'utilisateur doit être informé qu'il a fait l'objet d'une fuite. Soit il ne figure pas sur la liste, et tout va bien. Il est important de noter que l'API ne connaît jamais le résultat. Elle sait seulement que notre mot de passe figure soit dans la liste des 1 000 entrées renvoyées (auquel cas nous le rejetterons), soit qu'il ne figure pas du tout dans la base de données. Elle connaît également les cinq premiers caractères du hachage, ce qui, compte tenu de la longueur et des propriétés du hachage, n'est pas utile à des fins malveillantes.

Cet algorithme est dérivé du concept mathématique de k-anonymat. Il est utilisé, par exemple, dans la recherche médicale sur les dossiers anonymes des patients. L'ensemble de données est k-anonyme si, pour chaque enregistrement, il existe k - 1 autres enregistrements identiques. Dans notre cas, il s'agit d'environ 800 à 1 000 entrées, et nous sommes les seuls à savoir si notre mot de passe est l'un d'entre eux. Pour plus de détails, veuillez consulter cet excellent article sur le blog de Cloudflare : Validating Leaked Passwords with k-Anonymity, par Junade Ali.

En conclusion, nous espérons que vous activerez cette fonctionnalité. Vous n'avez rien à perdre et vos utilisateurs en bénéficieront grandement.