Identification impossible

**cavo789** · 11/01/2021, 09h52

Est-ce qu'il faut comprendre que le script Log_admin ne fonctionne pas avec J4 et a retourné une erreur 500 ? Il faudrait que j'y regarde un de ces jours...

**RobertG** · 11/01/2021, 10h00

Oui, Christophe, c'est ce que j'ai constaté après ne pas avoir réussi à me connecter (nouveau site recréé hier suite à une erreur de mise à jour de beta4 à beta5 si je me souviens bien).
La ligne en cause est la ligne 36

Code PHP:


require_once JPATH_BASE.'/includes/helper.php';

L'erreur :

Fatal error: require_once(): Failed opening required '/home/robetunp/Tests/4beta/administrator/includes/helper.php' (include_path='.:/opt/alt/php74/usr/share/pear') in /home/***********/Tests/4beta/administrator/login_admin.php on line 36

helper et toolbar.php ont disparu du dossier includes

**daneel** · 11/01/2021, 16h00

Bonjour,

L'encryptage a évolué depuis la version 3.2 de Joomla pour Bcrypt (cela remonte à plusieurs année!) ou un meilleur encryptage disponible mais les anciens mot de passe en md5 fonctionnent encore...

Juste après le changement, on pouvait même revenir au md5 pour des raisons de compatibilité avec les anciennes versions de php ( https://docs.joomla.org/How_to_disab...swords_feature ). Les pre-requis de Joomla ayant évolué (php 5 étant obsolète), l'option n'est plus disponible mais la compatibilité existe malheureusement.

Pour expliquer concrètement, quand tu examine sous phpmyadmin et que tu vois que le mot de passe commençant par $2y$, c'est bien le signe de l'identifiant de bcrypt suivi du "cost" (le facteur cout qui détermine la complexité algorithmique) ici à 10. En récupérant l'accès à la base de données et les mots de passe encryptés en bcrypt, il est difficile pour un hacker de retrouver le mot de passe en clair contrairement au hashage md5 dont il existe bon nombre de "casseurs de code"...

Si tu as réécrit le mot de passe en md5, je te conseille de t'identifier rapidement et de réinitialiser le mot de passe avec joomla (Joomla écrasera avec un mot de passe encrypté plus efficacement avec bcrypt ou plus si disponible). La description sur la réinitialisation du mot de passe dans la page https://docs.joomla.org/Resetting_a_user_password/fr devrait être réécrite afin d'expliquer que le md5 est obsolète. On devrait même oublier cette procédure de réinitialisation. C'est d’ailleurs ce qui m'a motivé initialement pour le script repris depuis par Christophe (log_admin) : https://github.com/cavo789/joomla_log_admin ... mais tu as raison, il faudrait que l'on voit pour la compatibilité avec Joomla 4.

Pour info, j'ai également réécrit une nouvelle solution en module pour panel de serveur (cpanel) mais également en script php pour administrateur qui a perdu tout accès. La différence, c'est que je lance l'authentification sous le compte utilisateur de leur choix mais on réécris le mot de passe avec bcrypt avec notification mail (par sécurité). Je n'ai pas encore testé avec J4 mais je compte bien le faire et l'adapter rapidement. Je partagerai le code si je trouve le temps de le faire...

Concrètement, toute faille qu'elle soit potentielle ou avéré nous oblige à avertir les utilisateurs, y compris la CNIL dans les 48h comme l'indique le RGPD. Mais je ne vais pas rentrer dans ces détails. Pour ma part, on ne devrait pas faire de compromis sur la sécurité que l'on soit seul ou avec une centaine d'utilisateurs.

Sur le plan général de la Sécurité avec un grand S... Quand vous avez un site, établissez une checklist de sécurité avant de passer en production... par exemple :

Protéger l'accès au backend (à l'administration).
Quand l'admin est accessible publiquement, cela permet aux hackers de tester le formulaire qui permet de s'identifier. Vous pouvez limiter en ajoutant un code dans l'url pour éviter le lien direct, protéger l'accès par l'ip en utilisant des extensions tiers. Il est possible de protéger par un htpasswd (identifiant et mot de passe supplémentaire) à la racine du repertoire administrator.
Anonymiser les pages front de Joomla
En examinant le code source des pages, on retrouve l'entête joomla ainsi que l'indication "template" ou le nom d'extensions. Certains développeurs osent également ajouter des commentaires ce qui rend l'identification plus facile depuis les moteurs de recherche. Il faut utiliser des outils d'optimisation afin de filtrer les informations et rendre le site plus rapide. Il est nécessaire de rendre l'identification plus complexe, sans cela un hacker aura vite fait de trouver la version de joomla non protégé via le fichier xml du fichier de langue en-GB.xml du repertoire language/en-GB... exemple : https://www.joomla.fr/language/en-GB/en-GB.xml
Ajouter la double authentification aux administrateurs
A défaut d'adopter d'autres solutions, les administrateurs doivent protéger leur accès car c'est la cible privilégié... Ils existent d'autres solutions que google authenticator comme le propose Nicholas d'akeeba avec LoginGuard
Détecter les changements de mot de passe.
On peut notifier de l'action de modification du mot de passe et en particulier quand il s'agit du groupe superadmin ou admin, il existe des plugins pour avertir par mail. Toutefois, il faudrait également lancer un cronjob pour scanner les changement par mot de passe md5 et inviter à modifier les rapidement les comptes. On le fait également pour les fichiers modifiés (eyesite) afin de restaurer en cas d'intrusion donc pourquoi pas inclure la base de données.
Faire des audits et les mises à jour.
Le principe, c'est de vérifier que vous avez pris connaissance des dernières infos sur la sécurité, de vérifier que le php est à jour, que joomla et ses extensions soit à jour et compatible. Les extensions datant de plusieurs mois, années sont susceptibles d'être obsolète donc posez la question sur le forum, vous avez aussi la base de données "VEL" sous Joomla qui référence les extensions ayant eu des failles, celles qui sont corrigés et celles qui ont été écarté de la liste pour l'abandon par l'auteur. Une extension peut faire l'objet d'une reprise par d'autres développeurs... Des sites comme sucuri proposent des tests assez simple ( https://sitecheck.sucuri.net/ ) mais d'autres peuvent vous réaliser des audits plus complets.
Autrement dit, rester informé et à jour !
Uniquement des mots de passe forts !
Le principal défaut vient souvent des choix d'utilisateurs, n'hésitez pas à modifier le paramètrage pour augmenter le niveau de sécurité. Si le site est lié à un intranet, accepter uniquement les adresses du domaine comme c'est possible nativement. Vous pouvez associer à des bases antispam via des extensions tierces pour éviter les comptes bidons (et interdire les adresses mails jetables ).

La sécurité se gère sur plusieurs niveaux mais qu'il s'agit des dns, du serveur, du fichier htaccess, du cms, cela doit rester cohérent et ne pas monopoliser les ressources ou bloquer les fonctionnalités.

Dans Joomla 4, vous avez également un plugin pour mettre en place une stratégie de sécurité du contenu sous joomla ( CSP ). Ce plugin natif fonctionne également sous joomla 3 donc applicable sur vos sites en production (et traduit en français). On aura l'occasion de revenir sur le sujet mais si vous avez envie d'aller plus loin, il existe plusieurs générateurs comme csper generator : https://csper.io/generator ... assez sympa comme présentation et j'aime bien l'idée de l'extension pour navigateur !

En résumé... oublions md5, on va adapter le script pour joomla 4 afin d'avoir une solution plus simple. On ne manquera d'apporter également des solutions pour vérifier et contrôler la sécurité mais n'hésitez pas à adopter une véritable stratégie, y compris pour vos mots de passe et des vérifications régulières.

Si vous avez besoin d'aide ou de compréhension de ces sujets, n'hésitez pas à poser vos questions, indiquer votre intérêt pour une conférence au jday ou en session visio...
Peu importe le niveau, on s'adapte très bien !

**RobertG** · 11/01/2021, 16h31

Merci Yann,

Ce que je ne comprends pas, c'est que la page d'explication dont j'ai donné l'adresse, mise à jour en septembre dernier, continue à parler de MD5 au lieu de donner la bonne méthode.

Par ailleurs, si j'ai eu ce problème ce matin avec un site J! 4 beta5, avant mise à jour en beta6, c'est que lors de l'installation, le mot de passe exigeait 12 caractères au moins. Si pour un administrateur ça peut se justifier, je vois déjà les futurs clients ou futurs membres fuir allégrement si ces administrateurs exigent des mots de passe très complexes et aussi long.

**cavo789** · 11/01/2021, 23h16

Bon, je viens de passer trois heures à chipoter mais sans succès. J'abandonne ici. Je reprendrais peut-être un jour lorsque j'aurais un peu plus de documentation sur la migration J3 vers J4 et la possibilité d'avoir un même script où le code J3 peut cohabiter avec le code J4.

**RobertG** · 12/01/2021, 07h58

Merci Christophe d'avoir essayé !

**roland_d_alsace** · 12/01/2021, 09h16

Hello.

Petite info (un peu hors sujet), mais en complément de la réponse de Yann( concernant le mot de passe supplémentaire par .htaccess dans le dossier /administrator :

Certaines extensions ont la mauvaise manie d'importer des fichiers js et css figurant dans un sous dossier de /administrator lors des affichages (dans le html généré).

Du coup l'internaute se retrouve avec la fameuse boite de login d'apache sur la partie frontale du site, ce qui 'est vraiment pas cool!

Si l'on veut utiliser un tel contrôle de l'accès à l'admin, pour éviter un tel désagrement il faut donc rajouter dans le .htaccess de /administrator le code que j'indique ici...

Code:

<FilesMatch "\.(css|js)$">
Order allow,deny
Allow from all
Satisfy any
</FilesMatch>

Ce code dispense de l'affichage de la boite de login lors l'accès par un navigateur aux fichiers terminant en .js et .css du dossier contenant le .htaccess en question ainsi que de ses sous dossiers.

Concernant le MD5, j'avoue que moi aussi je m'en sers quand je dois migrer ou upgrader des sites pour récupérer l'accès à l'admin.

Sa suppression nécessiterait comme c'est expliqué par les intervenants précédents à forcer le changement de mot de passe de chaque membre avec contrôle par email.

Quand je vois le nombre de membres de mes sites les plus anciens, où l'email n'est plus correct (retour en erreur : boite mail pleine ou inexistante) ceci parait difficilement réalisable, car cela provoquerait inévitablement soit la création de nombreux nouveaux comptes, soit l'intervention du webmaster pour changer les adresses mails erronées.

Il faudrait donc dans une première étape, imposer la vérification de l'email du membre et s'assurer que la grande majorité l'ai fait.

Ce n'est pas évident.

Identification impossible

Identification impossible

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Annonce

Partenaire de l'association