Un an après la mise à jour majeure du site, grand nettoyage dans les comptes utilisateur

Posté par  (site web personnel) . Édité par Florent Zara, baud123, Nÿco, Bruno Michel, Malicia et patrick_g. Modéré par Malicia. Licence CC By‑SA.
Étiquettes :
60
16
fév.
2012
LinuxFr.org

Il y a un an, le 20 février 2011 pour être précis, le site LinuxFr.org a migré vers une toute nouvelle version en Ruby On Rails (pour fuir Templeet). Les statistiques sur les utilisateurs du site nous apprennent qu'il y a environ 45 000 comptes qui ont été créés depuis la mise en place du site, qu'il en reste environ 42 000, dont 180 fermés et 3  900 valides et utilisés au cours des 3 derniers mois.

Les comptes créés avant la migration ont leur mot de passe stocké sous forme hachée DES 13 caractères (pas sous forme lisible, pas en clair pour résumer, mais un peu vieillot et peu sûr comme format). Les comptes créés ou utilisés après la migration ont leur mot de passe stocké sous forme hachée Blowfish 60 caractères (pas en clair et mieux protégé pour résumer).

35 000 comptes n'ont pas migré vers le nouveau format de stockage (et ont donc un mot de passe stocké dans l'ancien format). 600 comptes ont migré mais il existe encore une version de leur mot de passe de l'époque dans l'ancien format. Afin de supprimer de sa base de données les anciennes formes de mots de passe moins sûres, et parce qu'évidemment il ne nous est pas techniquement possible de convertir nous-même votre mot de passe vu que nous ne le connaissons pas, nous allons relancer par courriel tous les comptes ouverts et non utilisés depuis la migration :

  • pour les comptes qui n'auront pas été utilisés entre le 20 février 2011 et le 31 mars 2012, nous les fermerons et supprimerons le mot de passe et l'adresse de courriel associée (*). Leurs contenus et commentaires resteront en ligne ;
  • pour les autres comptes, l'ancienne forme du mot de passe sera supprimée de la base, tout le monde y gagnera en sécurité et cela simplifiera le schéma de notre base de données et le code de traitement des mots de passe.

(*) Nous n'avons pas à stocker ces données personnelles plus longtemps que nécessaire (et une bonne partie de ces adresses sont en fait obsolètes). Néanmoins pour laisser aux auteurs des commentaires et contenus la possibilité de corriger/changer la licence/demander leur suppression ou anonymisation, nous remplacerons les adresses de courriel électronique des comptes concernés par une version hachée inexploitable, mais fournissant un moyen de vérifier a posteriori si la demande provient bien de la bonne personne.

Aller plus loin

  • # merci

    Posté par  . Évalué à 10.

    Merci pour faire vivre ce super site qu'est linuxfr :-)

  • # Problème avec les identifiants

    Posté par  . Évalué à 4.

    Bah j'en profite pour faire remonter un problème, mon seul moyen de m'identifier, est de passer par le formulaire lorsqu'on a oublié le mot de passe, et de mettre à jour mon mot de passe, et à ce moment là j'arrive à avoir le cookie.
    Après avoir fait ça, je me déconnecte, puis je tente de me réidentifier, il me dit mot de passe incorrect…

  • # Pourquoi Blowfish?

    Posté par  (site web personnel) . Évalué à 8.

    Pourquoi utiliser Blowfish pour faire un hash, normalement on utilise md5 ou sha2?
    Pour moi c'est un algo de chiffrement, pas un algo de hash.

    • [^] # Re: Pourquoi Blowfish?

      Posté par  (site web personnel) . Évalué à 10.

      En fait, on utilise bcrypt, qui est un algorithme de hash dérivé de blowfish qui a spécialement été conçu pour hasher des mots de passe. Nous l'utilisons car c'est l'algorithme qui vient par défaut avec devise, la bibliothèque Ruby utilisée pour l'authentification et qu'il nous fournir les garanties suffisantes en termes de sécurité.

      Pour plus de détails, cf http://codahale.com/how-to-safely-store-a-password/

    • [^] # Re: Pourquoi Blowfish?

      Posté par  (site web personnel) . Évalué à 10.

      Une erreur habituelle lors de la gestion de mots de passes est de stocker les mots de passe sous forme hachée simple (hash = md5(password)). Cette forme n'est pas sûre du tout à cause de l'absence de salt (graine) qui rend la constitution de dictionnaires ou rainbow tables triviale. d'où l'utilisation de bcrypt.

      • [^] # Re: Pourquoi Blowfish?

        Posté par  . Évalué à 1.

        Pourquoi est-ce que ce commentaire est mal noté ? Je le trouve particulièrement intéressant puisqu'il évoque notamment le problème du "salage" des mots de passes, au moins aussi important que leur "hachage".

      • [^] # Re: Pourquoi Blowfish?

        Posté par  . Évalué à 2.

        Je crois qu'il y a des différences entre le « salage » (salt) et une « graine » (seed), mais je ne suis pas sûr.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Pourquoi Blowfish?

          Posté par  . Évalué à 7.

          La graine (seed) c'est le nombre que tu utilises pour initialiser ton générateur de nombres pseudo-aléatoires. Souvent on initialise avec time() pour avoir quelque chose qui a l'air réellement aléatoire, mais utiliser toujours la même graine peut servir à reproduire la même suite de nombres, par exemple pour la génération automatique de niveaux d'un jeu.

          Le salage (salt) c'est une valeur que tu introduis dans ton hashage pour faire en sorte que hasher deux fois la même valeur ne produise pas le même résultat. Comme ça si dix utilisateurs ont comme mot de passe "linuxfr", la base de données stockera des valeurs différentes. Craquer un mot de passe évite alors de craquer les autres en une fois.

          • [^] # Re: Pourquoi Blowfish?

            Posté par  . Évalué à 3.

            Souvent on initialise avec time() pour avoir quelque chose qui a l'air réellement aléatoire

            Ce n'est pas terrible d'avoir une graine prédictible.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Pourquoi Blowfish?

              Posté par  . Évalué à 2.

              Oui bon ça dépend du but poursuivi aussi.

            • [^] # Re: Pourquoi Blowfish?

              Posté par  . Évalué à 3.

              Ça dépend aussi de la résolution de ton time(). Si tu inclus des nanosecondes, ça devrait limiter la prédictibilité.

          • [^] # Re: Pourquoi Blowfish?

            Posté par  (site web personnel) . Évalué à 2.

            Mais du coup comment tu vérifies que le mot de passe qui vient d'être rentré est le bon?
            Il te faut la graine et/ou le salage?

            • [^] # Re: Pourquoi Blowfish?

              Posté par  . Évalué à 0.

              Ben suffit de faire comme sous UNIX (en tout cas Linux) : utiliser la date de création du compte comme grain de sel.

            • [^] # Re: Pourquoi Blowfish?

              Posté par  . Évalué à 4.

              Oui il faut la valeur utilisée pour le salage. Ca tombe bien elle est en clair dans le /etc/shadow, entre le 2eme et le 3eme dollar de la ligne concernée.

        • [^] # Re: Pourquoi Blowfish?

          Posté par  . Évalué à 6. Dernière modification le 16 février 2012 à 18:14.

          Je crois qu'il y a des différences entre le « salage » et une « graine », mais je ne suis pas sûr.

          Tu n'es pas sûr mais tu n'as pas pu t'empêcher de mettre ton grain de sel ;-)

      • [^] # Re: Pourquoi Blowfish?

        Posté par  (site web personnel) . Évalué à 5.

        Tu n'y connais vraisemblablement rien en sécurité. Le grain de sel n'a rien à voir avec l'algo de hashage utilisé. Ce qui importe surtout pour le choix de l'algo de hashage pour stocker des mots de passe c'est sa vitesse. Il vaut mieux utiliser (plusieurs passes d')un algo particulièrement lent que MD5 ou SHA qui sont conçus pour être rapides.

        C'est d'ailleurs expliqué dans le lien qui a été donné plus haut : http://codahale.com/how-to-safely-store-a-password/

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Pourquoi Blowfish?

          Posté par  . Évalué à 2.

          Il vaut mieux utiliser (plusieurs passes d')un algo particulièrement lent que MD5 ou SHA qui sont conçus pour être rapides.

          Oui, enfin il faut quand même un algo suffisamment robuste pour que la seule attaque possible soit la force brute.

        • [^] # Re: Pourquoi Blowfish?

          Posté par  . Évalué à 0.

          C'est un avis, mais visiblement pas partagé par debian :

          root:$1$ped0Q5Bz ...

          ni fedora (16) :

          root:$6$wl9of ...

          ni par la page de man crypt(3).

                        ID  | Method
          ─────────────────────────────────────────────────────────
          1   | MD5
          2a  | Blowfish (not in mainline glibc; added in some
              | Linux distributions)
          5   | SHA-256 (since glibc 2.7)
          6   | SHA-512 (since glibc 2.7)

  • # vieux comptes toujours en fonction ?

    Posté par  . Évalué à 4.

    pour les vieux comptes en fonction, il faut changer le mot de passe pour passer en bcrypt 60 bits ?

  • # Là aussi il y a une tâche

    Posté par  . Évalué à -2.

    Je profite de ce journal pour signaler que https://linuxfr.org/users/marotte c'est bien moi, ya qu'une seule Marotte (non elle ne travaille pas avec du papier d'aluminium). Donc bon, vu les trois journaux pourris que j'ai écrit dans ma jeunesse je pense que si vous voulez faire du ménage dans le contenu, ce compte là vous pouvez le virer...

    • [^] # Re: Là aussi il y a une tâche

      Posté par  . Évalué à 10.

      Moi pareil, mon autre compte c'est patrick_g, vous pouvez tout supprimer.

      • [^] # Re: Là aussi il y a une tâche

        Posté par  . Évalué à 2.

        Pareil, vous pouvez aussi bronsoniser tous les Pierre Tramos...

      • [^] # Re: Là aussi il y a une tâche

        Posté par  . Évalué à 1.

        Ah... Si j'avais pensé à publier une clé publique à l'époque (et que je n'eusse pas également perdu la clé privée correspondante entre temps...), j'aurais eu, peut-être, un moyen de vous convaincre :)

        Je peux aussi comprendre que ce n'est pas plus mal de conserver ce contenu, cela a un intérêt. Je vous rassure, ce n'est vraiment pas grave pour moi, je ne vais pas faire un caca nerveux pour si peu. C'est en tant que responsable de mes propres commentaires que je me suis permis d'exprimer ce desideratum. Je comprends très bien pourquoi il ne peut être exaucé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.