Identification impossible

Réduire
X
 
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • Identification impossible

    Bonjour,

    La discussion ayant due être supprimée en raison de liens malveillants placés a posteriori par son auteur, j'en mets une copie des messages, pour info
    daneel
    20/11/2020, 11h13
    Hello,

    Les mots de passe sont cryptés en bcrypt depuis la version 3.3 de joomla et non en md5... Je l'ai déjà évoqué sur ce forum :
    RobertG
    20/11/2020, 11h31
    Bonjour,

    Pourtant, le crypter en MD5 fonctionne toujours, à ma connaissance.
    Ceci dit, il est bizarre que le transfert ait rendu la connexion impossible (sans message d'erreur), sauf après modification du mot de passe dans l'administration.
    Quelle méthode a-t-elle été utilisée pour le changement d'hébergement ?
    RobertG

    11/01/2021, 07h58
    Bonjour,

    Pour avoir eu ce matin un problème d'accès à l'administration d'un site de test Joomla! 4, je confirme que le codage en MD5 du mot de passe depuis la base de données fonctionne.
    D'ailleurs, la page explicative, ici en français, accessible depuis le lien "Forgot your login details" de la page d'identification parle bien de cryptage MD5 : https://docs.joomla.org/Special:MyLa...in_password%3F
    Je ne comprends pas l'utilisation du fichier de configuration pour récupérer un mot de passe : si on connaît l'identifiant et le mot de passe d'un super administrateur, pourquoi passer par le fichier de configuration ? Quelque chose m'échappe !

    PS : la tentative d'utilisation du script de Christophe, fonctionnelle avec J! 3 m'a renvoyé une erreur 500.
    Et pour info complémentaire, l'utilisation de bcrypt n'est pas disponible dans phpMyAdmin.
    "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
    MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

  • #2
    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...
    Christophe (cavo789)
    Mon blog, on y parle Docker, PHP, WSL, Markdown et plein d'autres choses : https://www.avonture.be
    Logiciel gratuit de scan antivirus : https://github.com/cavo789/aesecure_quickscan (plus de 45.000 virus détectés, 700.000 fichiers sur liste blanche)​

    Commentaire


    • #3
      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
      Dernière édition par RobertG à 11/01/2021, 10h03
      cavo789 aime ceci.
      "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
      MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

      Commentaire


      • #4
        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 !







        Dernière édition par daneel à 11/01/2021, 16h03
        Eddy.vh et woluweb aiment ceci.
        Joomla User Group (JUG) Lille : https://www.facebook.com/groups/JUGLille/

        Commentaire


        • #5
          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.
          "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
          MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

          Commentaire


          • #6
            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.
            woluweb et RobertG aiment ceci.
            Christophe (cavo789)
            Mon blog, on y parle Docker, PHP, WSL, Markdown et plein d'autres choses : https://www.avonture.be
            Logiciel gratuit de scan antivirus : https://github.com/cavo789/aesecure_quickscan (plus de 45.000 virus détectés, 700.000 fichiers sur liste blanche)​

            Commentaire


            • #7
              Merci Christophe d'avoir essayé !
              woluweb aime ceci.
              "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
              MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

              Commentaire


              • #8
                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.
                Dernière édition par roland_d_alsace à 12/01/2021, 09h34
                A tous les utilisateurs de Joomla du très Grand Est de la France et du Jura suisse
                Rejoignez le Joomla Users Groupe Alsace...
                roland_d_alsace va-t-il devenir roland_du_grand_est ?

                Commentaire

                Annonce

                Réduire
                Aucune annonce pour le moment.

                Partenaire de l'association

                Réduire

                Hébergeur Web PlanetHoster
                Travaille ...
                X