Les données à conserver pour les hébergeurs

La “loi pour la confiance dans l’économie numérique” de 2004 (ou autrement appelée entre potes “LCEN”) prévoyait que les hébergeurs doivent “[conserver] les données de nature à permettre l’identification de quiconque a contribué à la création du contenu” (voir le II de l’article 6 de la loi du 21 juin 2004)1.

Mais, malheureusement, personne n’avait précisée quelles étaient ces informations…

Chapitre 1. Un décret utile (6,5 ans après)…

Le 25 février 2011, un décret2 est venu donner quelques précisions.

Ainsi, un hébergeur doit conserver :

Lors de la création d’un compte (durée de conservation 1 an à compter de la résiliation du compte) :

  • a) Au moment de la création du compte, l’identifiant de cette connexion ;
  • b) Les nom et prénom ou la raison sociale ;
  • c) Les adresses postales associées ;
  • d) Les pseudonymes utilisés ;
  • e) Les adresses de courrier électronique ou de compte associées ;
  • f) Les numéros de téléphone ;
  • g) Le mot de passe ainsi que les données permettant de le vérifier ou de le modifier, dans leur dernière version mise à jour ;

Pour chaque opération de paiement (durée de conservation 1 an à compter de la date de la facture) :

  • a) Le type de paiement utilisé ;
  • b) La référence du paiement ;
  • c) Le montant ;
  • d) La date et l’heure de la transaction ;

Pour chaque opération de modification ou de création de contenu (durée de conservation 1 an à compter de la création du contenu ou de sa modification) :

  • a) L’identifiant de la connexion à l’origine de la communication ;
  • b) L’identifiant attribué par le système d’information au contenu, objet de l’opération ;
  • c) Les types de protocoles utilisés pour la connexion au service et pour le transfert des contenus ;
  • d) La nature de l’opération ;
  • e) Les date et heure de l’opération ;
  • f) L’identifiant utilisé par l’auteur de l’opération lorsque celui-ci l’a fourni.

Chapitre 2. … mais déconnecté de la réalité technique !

Même si je trouve que ce décret va dans le bon sens, les informations listées me semblent (dans un certain nombre de cas) totalement absurdes.

Prenons donc un exemple concret : “les hébergeurs doivent conserver le mots de passe des utilisateurs” . Vous vous dites que c’est normal ? En fait c’est une absurdité technique et sécuritaire. Voyons donc pourquoi !

Section 2.1. Les mots de passe ne doivent pas être stockés en clair

Pour avoir été pendant longtemps consultant en sécurité informatique, je peux vous dire que quand je repérais un site qui stockait dans ses bases de données les mots de passe de ses utilisateurs en clair, je crisais un peu 🙂 Et cela arrivait assez fréquemment…

Mais avant toute chose, comme vous n’êtes pas spécialiste en sécurité informatique (enfin a priori), voici quelques notions… on appelle “stocker des mots de passe en clair” le fait d’enregistrer les mots de passes sans aucune modification. Par exemple, si le mot de passe de A est “azerty123” , j’enregistre sur mon disque une chaine de caractère contenant “azerty123” .

Vous me direz que c’est logique de procéder ainsi. En effet, lorsque je voudrais vérifier qu’une personne voulant se connecter au compte de A est bien A, je lui demanderai son mot de passe, et il me suffira de comparer celui-ci avec le mot de passe enregistré sur le disque.

Malheureusement, si un hacker accède à ma base de données (via une faille de sécurité), ce dernier pourra lire sans aucune difficulté tous les mots de passe de mes utilisateurs.

Section 2.2. Les mots de passes doivent être stockés dans un format “non-inversible”

L’idée de base est qu’il faut stocker les mots de passe dans un format qui ne permettent pas de les lire (de connaitre leur valeur exacte) tout en pouvant les vérifier.

Par exemple, les cryptologues ont inventés un grand nombre de fonction dites de “hash” (comme la fonction MD5 ou SHA1). Rassurez-vous, je ne détaillerai pas ici les principes mathématiques de ces fonctions.

Ainsi le mot de passe ne sera pas stocké sur le disque mais c’est son “hash” qui sera stocké. Par exemple, le hash MD5 de “azerty123” vaut “882baf28143fb700b388a87ef561a6e5” . Bien entendu, il n’existe aucun moyen de trouver facilement, à partir de ce hash “882baf28143fb700b388a87ef561a6e5” , le mot de passe initial.

Afin de vérifier le mot de passe qu’une personne soumet, il suffira alors de recalculer un hash sur le mot de passe soumis et de le comparer au hash sauvegardé sur le disque. Ainsi, il est possible de vérifier qu’un personne connait bien le mot de passe tout en étant incapable de connaitre ce dernier.

PS : pour les plus techniques d’entre vous, il est même conseillé d’utiliser SHA1 avec un salt secret.

Section 2.3. Un décret allant dans le sens inverse de la sécurité

Ainsi, demander aux hébergeurs de pouvoir fournir les mots de passe des utilisateurs me semble complètement idiot :

  1. d’un point de vue de la sécurité informatique, car cela implique que l’hébergeur les stockera en clair ;
  2. d’un point de vue de l’objectif de la loi, connaitre le mot de passe de quelqu’un ne permet pas de connaitre son identité.

Bref, je ne comprends vraiment pas…

 

L'URL courte pour partager cet article est: https://sedlex.fr/gldLQ

2 Comments:

  1. Le besoin principal des agents de police est de pouvoir investiguer, donc d’accéder à l’ensemble des informations associées à un compte. Le plus simple c’est d’avoir le mot de passe est de se connecter, d’où, je pense, cette acquériez du décret. Il suffit de simplement demander les informations recherchées dans la réquisition elle même.
    Encore faut-il savoir quoi demander, là est tout le problème. Ayant répondu à plusieurs réquisitions judiciaire, je me rend compte que les OPJ ne savent pas vraiment ce qui existe est font des demandes parfois très farfelues, ou alors revenant à demander plusieurs Go de données, par manque de ciblage.

    => on demande le mot passe + les reponses aux questions secrètes, ça donne accès à tout, puis on cherche dedans ce que l’on souhaite, comme dans le cas d’une perquisition physique.

    C’est bien dommage, alors qu’il suffirait de bloquer le compte en écriture, puis réinitialiser le mot de passe pour le fournir à la police. On y gagnerait la conservation des preuves et conserverait une protection décente des mots de passe. L’intéressé s’en rendrait compte, mais n’est-ce pas aussi le cas dans les perquisitions physiques ?

  2. Enfin un post où ton passé resurgit !!! 😀

Leave a Reply

Your email address will not be published. Required fields are marked *