Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un quart des principaux CMS, dont WordPress, utilisent la fonction obsolète MD5
Comme schéma de hachage de mot de passe par défaut

Le , par Bill Fassinou

135PARTAGES

5  0 
Les systèmes de gestion de contenu (CMS) constituent aujourd’hui l'une des manières les plus rapides de construire et de déployer son site Web. Les CMS sont très utilisés, mais il existe de nombreuses questions qui touchent à la sécurité de ces derniers. Dernièrement, ScienceDirect a proposé une analyse des schémas de hachage des mots de passe sur les plateformes Web open source et a apporté plusieurs conclusions selon lesquelles de nombreux CMS utilisent des fonctions de hachage obsolètes, un nombre arbitraire d'itérations de hachage notamment WordPress qui utilise toujours MD5 avec un faible nombre d'itérations de hachage.

Aujourd’hui, indique l’étude menée par des chercheurs de l’université de Pirée en Grèce et publiée dans la revue ScienceDirect, la majorité des plateformes Web sur Internet proviennent des systèmes de gestion de contenu (CMS) pour déployer facilement des sites Web ou des infrastructures d'applications Web qui permettent aux développeurs de concevoir et de mettre en œuvre des applications Web. Compte tenu du fait que les CMS sont destinés à être des solutions plug-and-play et que leur objectif principal est de permettre même aux non-développeurs de déployer des sites Web, dans la plupart des cas, les schémas de hachage par défaut sont rarement modifiés avant le déploiement.

En creusant, l’étude a fait ressortir que plus d’un quart des principaux systèmes de gestion de contenu (CMS) utilisent le schéma de hachage MD5, ancien et obsolète, par défaut pour la sécurisation et le stockage des mots de passe des utilisateurs. Cela signifie que si les propriétaires de sites Web ne modifient pas ces paramètres par défaut en modifiant le code source du CMS, la plupart des sites Web construits sur ces CMS mettent les mots de passe de l'utilisateur en danger si un pirate informatique volait la base de données du site. Cette façon de faire augmente considérablement les risques que les sites utilisant ces solutions soient vulnérables aux attaques par devinette de mot de passe.

En effet, le hachage de mot de passe est l'opération consistant à convertir un texte en mot de passe fourni par l'utilisateur en un mélange de caractères apparemment aléatoires stockés dans une base de données, sans exposer le mot de passe réel de l'utilisateur. Les schémas de hachage de mot de passe impliquent généralement trois choses : une fonction de hachage de mot de passe, des itérations et une chaîne salt. Le paramètre fondamental d'un schéma de hachage est la fonction de hachage utilisée. Par exemple, les fonctions MD5, SHA1, SHA256, SHA512, PBKDF2, BCRYPT, SCRYPT ou Argon2 peuvent tous être utilisées dans la composition d’un mot de passe. Deuxièmement, le nombre d'itérations d’une fonction de hachage appliquée à un mot de passe en clair.


Retenons que plus les itérations sont grandes, plus il est difficile pour un attaquant d’inverser l’algorithme en faisant appel à une grande quantité de calcul. La chaîne salt quant à elle est un paramètre facultatif dans les schémas de hachage utilisés conjointement avec la fonction de hachage pour produire des résultats encore plus aléatoires. Si le développeur utilise une chaîne salt, dans le cas d’une attaque, l’attaquant doit connaître à la fois le mot de passe et la chaîne salt avant de tenter d'inverser un mot de passe haché. Cela protège les bases de données de sites contre les attaques aveugles qui supposent des mots de passe.

Cela suppose que les concepteurs de site Web, d’applications Web d’applications mobiles ou toute autre application doivent utiliser un système de mot de passe sécurisé pour protéger les données des leurs utilisateurs. L’étude souligne que les fonctions de hachage jugées faibles sont celles considérées comme des fonctions de hachage déjà rompues telles que MD5 et SHA1. Par opposition à ces dernières, les fonctions de hachages fortes sont des systèmes très complexes et plus récents tels que BCRYPT, SCRYPT et Argon2. Cependant, notifient les responsables de l’étude, le but premier des CMS et des frameworks n’est pas d’offrir une couche de sécurité digne du nom, mais de présenter à l’utilisateur un cadre de travail facile à utiliser et intuitif.

L’étude inclut des recherches sur environ 49 CMS parmi les plus utilisés sur le marché et 47 frameworks d’applications Web populaires ainsi que leur mécanisme de stockage de mot de passe par défaut, à savoir leurs schémas de hachage de mot de passe. Selon le rapport, certains des projets utilisant MD5 comme méthode de hachage de mots de passe des utilisateurs par défaut incluent WordPress, osCommerce, SuiteCRM, Simple Machines Forum, miniBB, MyBB, SugarCRM, Simple Made CMS, MantisBT, Phorum, Observium, X3cms et Composr. Dans un premier temps, indique le rapport, ils sont nombreux à faire usage des fonctions de hachage dites faibles pour définir leur couche de sécurité par défaut.

Environ 60 % des CMS pris en compte par l’étude utilisent une fonction de hachage faible telle que MD5 ou SHA1 ou des fonctions de hachage telles que SHA256, SHA512, PBKDF2 qui peuvent être hautement parallélisées avec le matériel GPU, ce qui permet à un attaquant de deviner le mot de passe plus facilement. Le reste, un peu plus de 40 % des CMS restants, utilisent une fonction MHF (fonction mémoire dure) notamment BCRYPT, il s'agit entre autres de Joomla, phpBB, Vanilla Forums, vBulletin et SilverStripe. D’après les universitaires, aucun des CMS cités dans l’étude n’a fait usage des fonctions telles que SCRYPT ou Argon2. Pourquoi ? Selon eux, la raison principale est qu’il n’existe pas de bibliothèques PHP natives qui prend en charge ces fonctions-là.

À part cela, ils ont fait allusion au fait qu’Argon2 n’a été ajouté que récemment dans la version 7.2 de PHP et il faudra peut-être attendre un certain temps avant qu'il soit généralisé, car de plus en plus de serveurs migrent de l'ancienne branche PHP 5.x vers la version plus récente 7.x. de plus, la dernière partie du schéma de hachage n’est pas toujours observé chez les CMS les plus courants. Les chercheurs ont indiqué qu’environ 14,29 % des CMS testés n'ont pas ajouté une chaîne salt à leur système de hachage, laissant ainsi les utilisateurs vulnérables aux attaques de type arc-en-ciel. Ils ont également observé que 36,73 % des CMS testés n’utilisaient pas les itérations pour la fonction de hachage.

Cela signifie que le coût de la rupture (fissuration) des mots de passe des utilisateurs serait probablement minime. En outre, 38,78 % des CMS pris en compte dans l’étude n’ont pas défini de stratégie de longueur minimale du mot de passe, ce qui fait en sorte que certains utilisateurs choisissent des mots de passe faibles. Dans la catégorie des frameworks d’application Web, 23,40 % d’entre eux ont utilisé des fonctions de hachage faibles et 12,77 % d'entre eux n'utilisent pas d'itérations. Ici également, aucun des frameworks pris en compte par l’étude n’a utilisé les fonctions de hachage SCRYPT et Argon2 sont absents des paramètres par défaut et 27,66 % utilisent la fonction de hachage BCRYPT par défaut.

« Nous avons constaté que 48,94 % des infrastructures d'applications Web étudiées ne proposent pas de système de hachage de mot de passe par défaut, ce qui pourrait conduire à la sélection d'un système de hachage de mot de passe faible dans les applications Web », ont fait remarquer les chercheurs de l’université de Pirée. Ils ont conclu que la plupart des systèmes de gestion de contenu et les frameworks d’application Web ne proposent pas de paramètres par défaut suffisamment sécurisés. En prenant les deux types de technologies séparément, il faut noter que tous les utilisateurs du CMS ne sont pas des programmeurs et donc, les sites Web stockant leurs mots de passe à l'aide de méthodes de hachage de mot de passe obsolètes risquent de compromettre les données de l'utilisateur.

Sur l’autre rive, la faible sécurité par défaut pourrait être expliquée par le fait que les frameworks sont des outils uniquement à l’endroit des développeurs, ce qui signifierait peut-être que le choix leur ait laissé pour définir par eux-mêmes le niveau de sécurité voulu. À la fin de leur rapport, les chercheurs de l’université de Pirée ont émis le souhait selon lequel lequel les CMS et les frameworks d’application Web devraient être en mesure d’offrir une couche de sécurité plus avancée en proposant un des paramètres solides pour le schéma de hachage de mots de passe.

Source : ScienceDirect

Et vous ?

Qu'en pensez-vous ?

Voir aussi

Parmi les sites CMS piratés en 2018, 90 % sont des sites WordPress et 97 % des sites PrestaShop piratés sont obsolètes, selon un rapport

WordPress : le nombre de vulnérabilités a triplé en 2018, une étude pointe du doigt les plugins comme la principale source des failles du CMS

Une vulnérabilité inhérente à PHP met à risque des millions de sites web WordPress et l'équipe du CMS ne l'a toujours pas corrigée depuis 2017

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de meziantou
Membre émérite https://www.developpez.com
Le 18/06/2019 à 18:58
Question de timing, j'ai écrit un article hier sur comment stocker correctement un mot de passe dans une base de données (et aussi comment ne pas le faire!): How to store a password in a web application?
0  0 
Avatar de floyer
Membre à l'essai https://www.developpez.com
Le 18/06/2019 à 22:46
Si le développeur utilise une chaîne salt, dans le cas d’une attaque, l’attaquant doit connaître à la fois le mot de passe et la chaîne salt avant de tenter d'inverser un mot de passe haché. Cela protège les bases de données de sites contre les attaques aveugles qui supposent des mots de passe.
Une attaque aveugle n’est pas gênée par le salage... le serveur répondra aux essais de la même manière, salage ou pas.

Cela change avec une attaque après divulgation de la base des empreintes de mot de passe (donc pas en aveugle). Sans salage, on peut tester un mot de passe disons AZERTY... et si un des quelconques mots de passe correspond, c’est gagné. Avec le salage, il faut tester AZERTY autant de fois qu’il y a des sels différents utilisés, ce qui ralenti.
0  0 

 
Contacter le responsable de la rubrique Sécurité

Partenaire : Hébergement Web