Linux Mint a été compromise

Posté par Jehan (site web personnel, Mastodon) le 07 mars 2016 à 11:01. Édité par Benoît Sibaud, M5oul, palm123, BAud, Xavier Teyssier, xunfr et tuiu pol. Modéré par Benoît Sibaud. Licence CC By‑SA.

Étiquettes :

mar.

2016

Message d'intérêt général : les serveurs de la distribution Linux Mint ont été compromis.

Des images ISO (images disque utilisées pour l'installation) de Linux Mint Cinammon 17.3 ont été remplacées et contenaient une porte dérobée. À priori cela n'affecte que des images ISO téléchargées les 20 et 21 février 2016. Néanmoins vous êtes invités à la plus grande prudence si vous utilisez Linux Mint et l'avez installée dernièrement.
Le forum a également été compromis et la base de données copiée par les attaquants, entre autres avec les adresses de courriel, mots de passes hachés et d'autres informations personnelles. Cette base de données aurait fuité depuis au moins le début de l'année 2016.

Il convient d'être très prudent car une ou plusieurs attaques ont donc été jouées sur plusieurs mois, et même si les images ISO vérolées semblent ne l'avoir été que sur deux jours, il est conseillé de :

désinstaller/réinstaller Linux Mint si vous venez de l'installer ;
dans tous les cas de changer vos mots de passe, non seulement sur les forums Linux Mint mais aussi sur tout autre service où vous auriez pu utiliser le même mot de passe ;
Et dans ce genre de situation, il vaut mieux être le plus inclusif possible : si vous avez utilisé d'autres services Mint, il est préférable de considérer vos mots de passe là-bas aussi comme potentiellement compromis.

Vous êtes invité à lire la seconde partie de la dépêche pour des informations plus détaillées.

Sommaire

Données privées (dont mots de passe) compromis

Infos techniques

D'après un commentaire du mainteneur et chef de projet, Clément Lefebvre, les données compromises incluent les adresses de courriel, dates de naissance, les empreintes des mots de passe, dernières IP utilisées par chaque utilisateur avant copie(s), et toute l'activité — potentiellement privée comme des messages privés ou des fils de discussion privés — ou informations de profils, que les utilisateurs ont eu sur le forum, le tout attaché à des pseudonymes d'utilisateur que vous réutilisez peut-être ailleurs.

Les informations ont été mises à la vente le 20 février 2016 pour seulement 0,191 bitcoin (~85$):
Donnée Mint à la vente
La vente inclut la base de données du forum, ainsi que le shell et phpmailer, bien que je ne sois absolument pas sûr de ce que sont ces deux derniers éléments (peut-être les logs du shell, ainsi que de phpmailer, ce qui donnerait — potentiellement — une liste supplémentaire d'adresses de courriel ?).

Néanmoins quelqu'un avait déjà remarqué le 16 janvier 2016, plus d'un mois auparavant, que plusieurs bases de données de Mint étaient déjà en vente sur d'autres forums, depuis au moins le 2 janvier 2016:
Données Mint à la vente 2

Cela laisse à penser que cette attaque a en fait duré bien plus longtemps que deux jours. Ou alors, il y a eu plusieurs attaques de plusieurs origines au fil des mois mais seule la dernière a été découverte.

Les discussions privées le sont-elles vraiment?

Une première information sensible sont les messages ou discussions privés si jamais vous les avez utilisés pour divulguer des informations que vous ne voulez surtout pas voir se répandre. Un bon rappel sur le fait que quoi que vous diffusiez, même en privé a priori, il y a toujours un risque. Il ne faut donc jamais se laisser avoir au "discours marketing", même de grosses sociétés, qui vous assurent que toute discussion privée le restera à jamais. La réalité, bien plus technique et froide, rattrape souvent ces mensonges. De nombreux utilisateurs de services de rencontre (sujet très sensible pour certains) en ont d'ailleurs fait les frais au cours des années.

Il ne faut enfin jamais oublier que même sans compromission, les administrateurs de site ont accès à toutes vos données privées. La réalité informatique est même que beaucoup d'entreprises ne prennent pas la sécurité des données suffisamment au sérieux et les données sont souvent accessibles à n'importe quel technicien, développeur, voire employé un peu zélé. Ne vous croyez jamais seul sur Internet!

Autres données privées

Un autre type de données privées qui ont pu passer inaperçues sont les données de profil, ou votre date de naissance (9% des utilisateurs avaient rempli cette information). Bien sûr, pour beaucoup cela est considéré comme une donnée publique. Et vous avez bien raison!
Mais il se trouve que beaucoup de services semblent considérer des données aussi absurdes que les dates de naissance, votre adresse, votre ancienne école, ou le nom de votre chien comme des données hautement sensibles! En effet, qui n'a jamais rempli les fameuses "questions sécurité", avec de tels exemples tous plus ridicules les uns que les autres? Ce sont malheureusement des informations que beaucoup mettent pourtant maintenant sur la page principale de leur blog ou page de réseau social!

Alors pour ceux qui avaient un compte, demandez-vous si vous n'avez pas utilisé ces infos comme réponse secrète sur un autre service, permettant aux attaquants de gagner l'accès à votre compte sans même avoir besoin du mot de passe.

Mots de passe

Les empreintes par fonction de hachage des mots de passe (et non pas un chiffrage comme annoncé initialement) sont donc dans la nature. Le hachage est une fonction à sens unique; il n'y a pas de clé pour trouver le mot de passe originel à partie de l'empreinte.
Cependant il est possible de trouver les mots de passe par force brute, de façon extrêmement simple, coûteuse uniquement en temps. Il s'agit de simplement hacher des suites de texte semi-aléatoirement jusqu'à trouver des correspondances (création d'une table de hachage). Les mots de passe les plus vulnérables sont donc : les termes des dictionnaires (on peut être sûr qu'ils seront trouvés), les mots de passe "courants" (même s'ils ne sont pas dans un dictionnaire "normal"), et les mots de passe courts.

Cela ne signifie absolument pas que les mots de passe longs qui ne sont pas dans un dictionnaire sont saufs. Avec suffisamment de temps, n'importe quel mot de passe est vulnérable. Si vous étiez utilisateur des forums Mint, vous devez considérer votre mot de passe comme compromis et ne plus jamais le réutiliser.

Pour les gens friands d'informations encore plus techniques, les empreintes était salées, mais les attaquants ont eu accès au sel. Il n'est pas dit explicitement comment, ni où ce sel était sauvegardé. En général, il est sauvegardé dans un fichier texte, c'est à dire accessible seulement par le système de fichier, ce qui en fait une donnée secrète pour un attaquant avec accès seulement à la base de données, rendant la tâche de création d'une table de hachage bien plus difficile (mais pas impossible). Si par contre il avait été aussi sauvé en base, cela le rend beaucoup moins utile pour la sécurité (sauf s'il s'agit d'un sel aléatoire, unique par utilisateur) car un attaquant avec accès à la base a aussi accès au sel. On peut donc supposer que le système de fichier (du forum) a aussi été compromis, c'est-à-dire un accès plus direct au serveur (d'ailleurs le mainteneur parle de dumps de base de données sur le serveur, ce qui semble confirmer ce point).
La conséquence est que les attaquants ne peuvent probablement pas réutiliser une table de hachage existante et doivent en créer une de zéro. Par contre hormis ce petit contretemps, algorithmiquement, un sel connu n'apporte aucune sécurité et la complexité de cryptanalyse est du niveau d'empreintes hachées sans sel.

Enfin — sauf erreur — les administrateurs et développeurs de Linux Mint n'ont jamais donné le nom de l'algorithme de hachage utilisé, malgré des demandes en commentaires. Or certains disent que phpBB utilise la fonction de hachage MD5 par défaut, ce qui est loin d'être vraiment rassurant car cet algorithme n'est plus du tout considéré comme sûr.
D'autres notent que phpBB est passé en 2014 à bcrypt, plus sûr (même si ce n'est jamais suffisant). Mais rien ne dit que les forums de Linux Mint, qui existaient déjà ont fait la transition (puisqu'ils avaient déjà une base d'utilisateur et les empreintes étant non réversibles, la migration peut être complexe).
Donc hormis s'il y a un communiqué clair sur le sujet, il est dur de savoir quel algorithme fut vraiment utilisé.

Comment réagir à la compromission des mots de passe

Dans tous les cas, considérant l'ampleur de la compromission (base de données, probablement système de fichier, etc.) qui s'est étendue sur au moins deux services (le site web et le forum) depuis plus de deux mois, il faut considérer le pire. C'est le seul conseil valide dans un cas comme celui-ci.

C'est le moment de rappeler l'intérêt d'un minimum de paranoïa dans l'utilisation de l'outil informatique. J'ai trouvé personnellement les annonces de Linux Mint un peu trop "rassurantes". Alors je le redis: qu'importe la force (supposée) de votre mot de passe, considérez le cassé à partir de maintenant et ne le réutilisez plus jamais!

Voici quelques conseils :

Allez immédiatement changer vos mots de passe sur tous services Mint que vous pouviez utiliser (pas seulement les forums, il faut être le plus inclusif possible en sécurité).
Allez changer vos mots de passe sur tout autre service (hors Mint) où vous utilisiez les mêmes mots de passe que ceux changés précédemment.
Vérifiez que tout a l'air normal sur ces services tiers et que rien ne paraît "différent" ou louche. Si oui, demandez-vous quels informations auraient pu être récupérées (notamment s'il s'agit d'un compte email) et agissez en conséquence.
Demandez-vous si vos questions de sécurité sur divers services utilisent peut-être des informations personnelles qui ont pu être dérobées. Si tel est le cas, changez les dites questions et réponses ainsi que les mots de passe sur ces services.

Les développeurs de Linux Mint conseillent ce service qui contient des listes de d'adresses de courriel compromises: https://haveibeenpwned.com/ ¹
Néanmoins sachez que même si vous n'êtes pas dans la liste, cela ne signifie pas pour autant que vous n'avez pas été compromis.

(¹) Je n'ai pas entièrement confiance dans un quelconque site web qui me demande mon adresse de courriel. Néanmoins ce site semble être géré par un développeur sécurité de Microsoft avec a priori pignon sur rue. Il a donc l'air raisonnablement de confiance.

Quelques règles de base pour vos mots de passe

Profitons en pour rappeler quelques règles de base pour créer un mot de passe fort, défini ainsi:

Un mot de passe fort est un mot de passe qui n'est pas faible

Il est difficile de définir ce terme hormis comme l'opposé de ce qui est aisément découvrable, ce qui évolue en permanence. Voici les spécificités d'un mot de passe faible à ce jour:

Un mot de passe court: de nos jours, un mot de passe devrait faire au moins 10 caractères.
Un mot du dictionnaire: même "anticonstitutionnellement", mot français le plus long, est un mot de passe faible.
Un mot répandu, même si ce n'est dans aucun dictionnaire.
Un mot avec des substitutions connues: remplacer 'o' par '0', ou le son /œ̃/ par '1' sont des astuces bien trop répandues. Donc non 'Tr0ub4dour' n'est pas un bon mot de passe.
Un mot dérivé de vos informations personnelles: votre nom, nom de votre chien, date de naissance…
Une expression connue.
Un mot qui utilise un seul type de caractère: mélangez alphabet, majuscules et minuscules, nombres, et même des ponctuations (points, virgules…) ou autres caractères spéciaux (€$%…).

En tous cas, ne prenez surtout pas exemple sur les administrateurs de Linux Mint dont le mot de passe de la base de données semble avoir été "upMint": 6 caractères sans caractère spécial ni nombre, et comprenant le nom du projet!

Pour le reste, il existe deux types de mots de passe : ceux dont on se souvient, et les autres.

Mots de passe dont on se souvient

Les mots de passe les plus communs. Ils ont cependant un double problème :

S'il n'est sauvé nulle part, alors il y a risque de l'oublier (surtout si on ne l'utilise pas souvent).
Si on s'en souvient facilement, c'est peut-être qu'il est faible.

Ce second problème n'est pas forcément vrai. Il existe des moyens mnémotechniques pour se souvenir de mots de passes forts. Par exemple, un exemple classique est d'utiliser une phrase entière: Vas-tuchezmonp0teM4xime?. Notez que je mélange certains des concepts faibles (utilisation de substitutions…), et que je ne me complique même pas énormément avec les positions des majuscules et ponctuation. C'est toutefois un mot de passe plutôt fort, long avec plusieurs types de caractères et dont on se souvient bien.

Par contre, n'utilisez pas de phrases connus. Par exemple, ceci n'est pas bon: Iwillbeb4ck! (réplique de Terminator)

À ce sujet, riez un coup avec la fameuse BD XKCD (vous reconnaîtrez l'exemple du troubadour).

Mots de passe dont on ne se souvient pas

Il existe une autre manière de gérer les mots de passe, de plus en plus courante dans notre société numérique qui requiert de plus en plus de mots de passe : la génération automatique de mots de passe (par exemple un plugin dans le navigateur qui génère des suites de caractères aléatoires).

Bien sûr, cela est rarement dans un but de mémorisation et la plupart des gens vont donc utiliser en plus un logiciel de portefeuille de mots de passe pour les mémoriser, comme GNOME_Keyring ou KWallet sous les bureaux libres respectifs GNOME et KDE.

Certains experts en sécurité vous conseillent même de les écrire sur des bouts de papier (un carnet toujours dans votre poche par exemple). Bien que cela puisse paraître farfelu, le fait est qu'il est toujours bon de séparer vos données sur plusieurs supports: le jour où votre ordinateur se fait compromettre, au moins vous n'aviez pas tout vos mots de passe (même chiffrés, le risque existe) dessus. À l'opposé, il est plutôt rare que quelqu'un vous vole un carnet de notes et s'amuse à comprendre les gribouillis que vous y avez faits! Même si on vole votre sac, on va plutôt s'emparer des billets dans le portefeuille à côté et jeter le carnet.

Ne pas réutilisez vos mots de passe

Enfin un conseil important s'il en est: quel que soit la force de vos mots de passe, ne pas les réutiliser!

1 mot de passe == 1 service.

Car le jour où ce dernier est déchiffré, qu'importe sa force, les attaquants peuvent simplement le réessayer sur de multiples services connus, en association avec votre login ou votre email.
Cela est d'autant plus vrai pour les services importants, comme votre compte en banque, mais même votre email. Votre compte sur un réseau social est aussi un compte majeur si vous l'utilisez pour vous connecter sur d'autres sites.

Soyez original

Vous remarquerez que XKCD proposait une méthode différente de la mienne car mes phrases ont un sens. Je ne pense pas que cela fragilise les mots de passe tant que ce ne sont pas des phrases connues (une méthode avancée de force brute essayera des combinaisons de mots, mais je doute qu'on y ajouterait du traitement grammatical, car cela a aussi un coût non négligeable) et je trouve ces mots plus simples à mémoriser.

Au final il vaut mieux ne pas avoir tous le même algorithme personnel de création de mots de passe forts, tout simplement car le jour où cela arriverait, ces mots de passe ne seraient plus forts. Il convient donc d'adapter et de trouver votre propre technique pour créer vos mots de passe longs et complexes.

Installation compromise

Infos techniques

Par une faille de Wordpress, les attaquants ont eu accès au serveur, et ont escaladé les privilèges jusqu'à avoir contrôle de l'utilisateur www-data. Cela leur a permis de modifier les pages HTML pour le téléchargement, et en particulier de changer les liens sur le site officiel pour pointer à la place vers des images ISO vérolées hébergées à l'IP 5.104.175.212, mais aussi les empreintes MD5 de vérification d'intégrité. Quand vous installiez la distribution avec ces ISO, vous mettiez en place une porte dérobée dans votre système qui se connectait à l'URL absentvodka.com, située ~~en Bulgarie~~ au Belize (tout comme l'IP).
Certains serveurs miroirs ont apparemment aussi diffusé l'ISO, ce qui paraît étrange. Habituellement un serveur miroir devrait se synchroniser avec un serveur upstream (en général avec rsync) et n'aurait pas dû être infecté par une page HTML pointant sur la mauvaise adresse.

Cette porte dérobée prend la forme d'un fichier /var/lib/man.cy (dont le contenu a été copié sur le web, bien que je n'ai pas réussi à vérifier la véracité de l'origine), qui serait un malware connu sous les noms de kaiten ou tsunami et utiliserait une méthode d'auto-compilation sur les machines des victimes. Ce malware se connecte sur un canal IRC (ici le canal #mint sur le serveur updates.absentvodka.com), rejoignant ainsi un botnet, transformant l'ordinateur de la victime en zombie attendant silencieusement des ordres. Le but principal serait de pouvoir utiliser le botnet pour effectuer des DDOS d'envergure sur commande, mais la lecture du code montre que cela permet aussi de lancer des téléchargements sur les ordinateurs zombies, et surtout d'exécuter des commandes shell quelconques. Il s'agit donc bien d'un accès shell sur l'ensemble du botnet.

Plusieurs sites ont étayé les informations, dont Softpedia, mais surtout ZDNet qui aurait été en contact avec l'attaquant (pseudonyme "Peace", assez ironiquement). Celui-ci aurait affirmé avoir plusieurs centaines d'installations Mint dans son botnet et avoir 2 copies de la base (28 janvier et 18 février, ce qui confirmerait que l'attaque ait été en cours depuis un mois, mais indiquerait que les ventes précédentes de la base de données auraient été faites par d'autres attaquants). Apparemment l'attaquant avait bien découvert une faille sur le site web, et se trouvait être déjà en possession d'un accès en temps qu'admin sur le site web.

A priori rien n'indique si d'autres portes dérobées auraient pu être introduites dans cet ISO vérolé. Tsunami pourrait n'avoir été que la partie visible de l'iceberg qui cache d'autres portes. Je n'ai pas vu cependant d'information filtrer sur la découverte d'aucune autre porte d'accès.

Vérifier si on a été compromis

Il est conseillé de:

Couper internet sur la machine.
Vérifier le nom de domaine du téléchargement (Firefox montre cette info dans la fenêtre de téléchargement). Si c'est 5.104.175.212, vous êtes compromis.
Vérifier l'ISO avec laquelle on a installé (si on l'a encore). Son empreinte MD5 doit correspondre à l'une de celles-ci:

6e7f7e03500747c6c3bfece2c9c8394f linuxmint-17.3-cinnamon-32bit.iso
e71a2aad8b58605e906dbea444dc4983 linuxmint-17.3-cinnamon-64bit.iso
30fef1aa1134c5f3778c77c4417f7238 linuxmint-17.3-cinnamon-nocodecs-32bit.iso
3406350a87c201cdca0927b1bc7c2ccd linuxmint-17.3-cinnamon-nocodecs-64bit.iso
df38af96e99726bb0a1ef3e5cd47563d linuxmint-17.3-cinnamon-oem-64bit.iso

En particulier, vous ne devez pas obtenir l'empreinte présente sur le commentaire en lien (je ne la copie pas pour éviter qu'un lecteur inattentif croit qu'il s'agit d'une empreinte valide).

Vérifier l'existence de /var/lib/man.cy (note: certains s'inquiètent de /var/lib/man-db , mais ce fichier n'est pas un problème).
Vérifier les connexions sortantes (en rétablissant internet).

Il est à noter que l'existence ou absence de /var/lib/man.cy n'est pas suffisant comme information. Les commentaires sur le site linuxmint sont clairs dessus et surtout le malware Tsunami a une commande pour s'auto-supprimer afin d'effacer toute trace, ce qui ne signifie pas qu'il n'aurait pas au préalable exécuté d'autres commandes pour se préparer des portes dérobées alternatives (ou simplement s'il n'y avait pas une autre porte dérobée non découverte, depuis le début).

Mon conseil est de ne pas se poser trop de question et de simplement supprimer Linux Mint si vous l'avez installé récemment, pour le réinstaller (ou quelque chose d'autre). Il vaut mieux n'avoir aucun doute. Le mainteneur semble avoir le même conseil que moi.

Que faire ensuite ?

Si vous trouvez le fichier /var/lib/man.cy, sauvez vos données et désinstallez Linux Mint.
Si vous avez installé récemment, sauvez vos données et désinstallez Linux Mint.

Pour les développeurs de Linux Mint, la définition de "récemment" semble tabler autour du 20 février 2016 (on sait de source sûre que les ISO ont été à nouveau compromises le 21, même s'il n'y a pas eu d'annonce officielle, hormis un commentaire perdu sous l'annonce, laquelle ne donne toujours que le 20 comme date), mais considérant la compromission sur au moins 2 mois du forum, et le manque d'information, je serais bien plus paranoïaque et donnerait une marge de 3 mois au moins, juste pour être sûr. Il y a pu y avoir d'autres compromissions plus subtiles qui n'ont pas encore été découvertes.

Dans le doute: désinstallez et réinstallez avec une distribution fraiche de Linux Mint, voire une autre distribution.

Dans le futur ?

Toujours vérifier au minimum les empreintes des ISO téléchargées. Bien sûr, ce n'est pas suffisant, et ce cas en est la preuve car l'attaquant avait aussi modifié ces empreintes sur le site web. Cela n'aurait donc servi à rien sur cette attaque. Mais cela peut servir lors d'une attaque où par exemple le serveur de téléchargement est compromis, mais pas le site web.
Utilisez https sur la page de téléchargement si disponible et vérifiez le nom de domaine. Refusez un téléchargement sur une page https si une alerte du navigateur intervient.
Si vous téléchargez Linux Mint, et que le nom de domaine est autre chose que linuxmint.com ou *.linuxmint.com, fuyez. Par exemple sur ce coup, le nom de domaine était une adresse IP, ce qui aurait dû mettre la puce à l'oreille à tout le monde. Il n'y avait aucune raison pour le projet Mint de ne pas utiliser leur nom de domaine.
Il y a peu de solutions à ce type de problème à l'heure actuelle en fait en tant qu'utilisateur (en tant que développeurs, il y a beaucoup plus). Il convient néanmoins de rester conscient de sa vulnérabilité et de réagir si des évènements louches se produisent. Par exemple si vous constatez des connexions étranges sortantes de votre machine, ou des processus qui prennent beaucoup de mémoire ou de processeur. Il ne faut jamais hésiter à ouvrir des rapports de bugs pour relever des comportements anormaux.
Tenez-vous au courant si possible des nouvelles de votre distribution ou logiciel. Ici des dizaines voire centaines de personnes n'ont probablement toujours pas entendu parler de cette attaque et restent compromis.
Installez les mises-à-jour. Linux Mint a ainsi rapidement mis en ligne une mise-à-jour pour prévenir les utilisateurs et tenter de détecter la présence du malware. Bien sûr, ce conseil peut être à double tranchant. Si l'attaquant avait modifié la source des paquets de la distribution, il pourrait générer de fausses mises-à-jour à installer sur les ordinateurs cible. Cela ne semble heureusement pas avoir été le cas sur ces attaques.

Oh mon dieu ! C’est vraiment une preuve de la faiblesse du Libre !

Cela arrive tout le temps, même chez les gros services propriétaires

Après toute la paranoïa, je pense qu'il convient de remettre certaines pendules à l'heure. Oui, les développeurs et administrateurs de Mint n'ont pas été très bons sur ce coup. Y a clairement eu faille sur faille et manque de clairvoyance.

Cependant, ce type d'attaques arrive tout le temps, et à de très gros services propriétaires également. Le site "have i been pwned?" donne une liste de sites dont des fuites de données ont été divulguées (beaucoup de sites ne sont peut-être pas dans cette liste, mais cela ne signifie pas qu'ils n'ont jamais subi la même chose. Le pire peut être caché).

Les plus gros services fuités sont essentiellement des services purement propriétaires, et la plus grosse compromission connue à ce jour reste celle d'Adobe en 2013, avec 153 millions de comptes dans la nature, des emails, mots de passes faiblement chiffrés et des "indices" de mots de passe (je crois qu'il s'agit des fameuses questions du type "le nom de votre chien?" ou autre pour récupérer un accès au compte) en clair.
Ou encore le site de rencontre Ashley Madison qui a fait beaucoup parler de lui l'an dernier (notamment car comme il s'agissait d'un site de rencontre spécialisé "extra conjugal" et qu'il y a eu des suicides suite à la révélation des données).

Vous êtes responsables aussi

De plus, il convient de rappeler qu'il ne faut jamais faire une confiance aveugle à un étranger qui vous donne des bonbons. Au final, vous êtes toujours responsables de vos actes. Vous choisissez à qui vous faites confiance, et il ne faut s'en prendre qu'à soi-même si vous n'avez pas protégé vos arrières. Ce qu'on a dit plus haut aussi bien pour le choix des mots de passe ou les vérifications de base lors du téléchargement d'un logiciel (ou n'importe quel fichier) est toujours valable, où que ce soit. Il faut toujours faire jouer son cerveau avant d'accepter quelque chose, que ce soit un contrat, un téléchargement ou un message d'alerte.

Le but n'est pas de culpabiliser l'utilisateur mais bien de le rendre acteur et responsable. Il est toujours facile d'accuser autrui, mais il ne faut jamais oublier que chacun a sa part de responsabilité.

La transparence du service

Linux Mint aurait dû donner plus d'informations selon moi, mais ils ont tout de même fait preuve d'un minimum de transparence qu'on n'aurait sûrement pas dans la plupart des services typiques et propriétaires. En fait la plupart ne feraient même pas d'alertes aux utilisateurs tant que la compromission ne fait pas la une des journaux. Le dernier gros en date, Hashley Madison< en est un bon exemple puisque les représentants du site ont nié la réussite du vol de données (voir aussi une annonce officielle) pour finalement l'admettre un mois plus tard.
Quant à Adobe, à l'époque, ils avaient essayé de minimiser l'attaque en prétendant que 3 millions de compte avaient fui, quand il s'agissait en fait de 38 millions… ah non en fait plus de 150 millions.

Quand on compare, Linux Mint a réagi en 1 heure pour couper le téléchargement, quelques heures pour publier une alerte par blog post, des réponses multiples en commentaires sous ledit post, et une mise à jour avec une alerte et recherche du malware 2 jours plus tard. Ce n'est pas si mal. Alors oui, ils auraient pu faire mieux au niveau information. J'aurais notamment préféré de nouveaux blog posts ou une édition du post initial avec les informations essentielles supplémentaires (plutôt que chercher dans les commentaires), plus de chiffres et de détails techniques (je ne sais toujours pas quel fut la fonction de hachage utilisée par exemple: MD5, bcrypt, une autre?).
Mais ils ont tout de même donné le minimum d'information et fait preuve de rapidité de réaction pour un service qualifiable de transparent et à qui on peut accorder un début de confiance.

Les premières réactions de Mint

Linux Mint a publié le premier mars ses nouvelles mensuelles. Bien entendu, les attaques étaient le cœur des nouvelles. Ils annoncent avoir eu le soutien de phpBB, ainsi que d'Automattic (entreprise derrière Wordpress). Ils ont aussi obtenu l'aide d'Avast qui a analysé l'ISO et a produit une analyse, permettant à Linux Mint de créer la mise-à-jour pour contrer le malware, à Avast de faire une mise-à-jour pour leurs propres utilisateurs, et surtout Avast aurait bloqué l'accès au serveur malveillant.
Je n'ai malheureusement pas trouvé de lien avec l'analyse détaillée d'Avast ni ne trouve ce que signifie exactement de "bloquer l'accès au serveur". Je doute qu'ils aient fait fermé le serveur en rentrant en contact avec la police locale (ce ne serait pas si rapide et ils n'auraient pas parlé de "bloquer" les accès). Je doute également qu'ils aient pu agir au niveau des DNS. Alors est-ce une sorte de règle pour les utilisateurs d'Avast seulement? Quoi d'autre?

En dehors de cela, Linux Mint a annoncé des changements à venir au niveau de la sécurité, mais peu de détails furent données pour savoir desquels il s'agit, hormis:

passer les sites en HTTPS (comme expliqué, cela n'aurait pas changé grand chose à cette attaque précise, mais c'est quand même un bon début), faire des empreintes SHA256 plutôt que MD5 (pareil), ajouter des signatures GPG (cela est mieux mais seulement pour ceux qui comprennent comment marche GPG et ont récupéré les clés publiques de Linux Mint par un moyen sûr, c'est donc limité).
ajouter Gufw dans les logiciels installés par défaut, qui est une interface graphique au pare-feu UFW. Ceci est probablement une bonne idée d'avoir un pare-feu par défaut, mais sa configuration reste importante, et surtout si un ISO est vérolé, un attaquant pourrait simplement désactiver le dit parefeu.

Aucun détail n'est donné sur l'amélioration de sécurité des serveurs, la partie la plus importante en vue de ces attaques, bien que le sujet est abordé.

Enfin Linux Mint termine sa revue en remerciant les donateurs et sponsors.

Le mot de la fin

Je conseille personnellement de mettre un peu Mint de côté pour l'instant. Ce n'est pas contre Mint. Je l'ai utilisé moi-même pendant quelques années et ai apprécié l'expérience même si je n'utilise plus depuis déjà plusieurs mois. C'était aussi la distribution que je continuais à conseiller si on me demandait (j'en ai installé un sur l'ordi d'un ami, il y a peut-être 6 mois).
Néanmoins le manque d'information et le doute fait que je ne peux affirmer (et j'ai l'impression que personne ne le peut à l'heure actuelle, pas même les admins de leur infrastructure) si tout est rentré en ordre, même à ce jour, ni l'étendue de la compromission ou encore "depuis quand".

Il semblerait que cela ait duré depuis plus longtemps qu'ils n'aimeraient l'avouer (cf. les révélations sur la base de données fuitant depuis début 2016), et aussi donc que ce soit plus étendu qu'on ne le croit (cf. leur trop rapide remise en route des téléchargements et la découverte le 21 — soit le lendemain — que les ISO étaient à nouveau corrompues alors qu'ils pensaient avoir réglé le problème).
Je ne pense pas que ce soit entièrement leur faute. Ils sont probablement une plus petite équipe que les utilisateurs ne le pensent, et entièrement bénévoles (sauf erreur). En outre, ils ne sont pas experts en sécurité mais développeurs de logiciels, de leurs propres dires, et soyons clair, je ne doute pas une seule seconde qu'une telle chose pourrait aussi m'arriver et que je puisse me faire avoir de la même façon (car je ne suis pas expert en sécurité non plus).
Ce n'est donc pas une critique, c'est souvent le cas dans le libre; et la réalité est que bien souvent des bénévoles peuvent produire du travail de meilleure qualité que certaines entreprises (comme l'a démontré la liste des sites compromis avec de grosses entreprises en tête). Mais parfois ce n'est pas suffisant.

C'est pourquoi il faut se rendre à l'évidence, l'aspect sécurité est une part trop importante pour le système d'exploitation que vous installerez sur votre ordinateur pour votre utilisation quotidienne. Donc s'ils ne sont pas experts en sécurité, je préconise d'attendre que certains joignent l'équipe et viennent sécuriser Linux Mint. Je ne doute pas qu'après cet évènement, ils obtiennent de l'aide sur le sujet (j'ai pu remarquer plusieurs propositions dans les commentaires de leurs posts d'ailleurs).
Je pense donc qu'il faut attendre au moins quelques mois et voir comment cela évolue, comment ils réagissent, quels changements ils afficheront, etc. avant de faire à nouveau confiance à, et conseiller, Mint.

Dans tous les cas, il faut toujours garder la tête froide et ne jamais oublier qu'au final, le dernier maillon faible ou fort, c'est nous. Cet évènement nous rappelle de toujours tout vérifier et sécuriser ce qu'on peut "de notre côté".

Sur ce, je souhaite aux développeurs et admins de Linux Mint une bonne continuation et beaucoup de courage pour tout sécuriser, tout vérifier et enquêter sur les origines du problème, car je sens que ça va être une épreuve longue et loin d'être finie pour eux.

Aller plus loin

Journal sur LinuxFr au sujet des images ISO compromises (572 clics)
Journal sur LinuxFr au sujet du forum compromis (187 clics)
Annonce officielle au sujet des images ISO compromises (179 clics)
Annonce officielle au sujet du forum compromis (109 clics)
Journal officiel sur les premiers changements relatifs à la sécurité de Linux Mint suite à l'attaque (183 clics)

# Comment détecter une intrusion ?

Posté par Victor STINNER (site web personnel) le 07 mars 2016 à 11:29. Évalué à 4. Dernière modification le 07 mars 2016 à 11:31.

Comme dit dans l'article, les intrusions de ce genre sont malheureusement courantes. Je me demande à chaque fois comment une telle intrusion pourrait être détectée au plus tôt pour limiter la portée de l'attaque. Je suppose que Wordpress et phpBB sont hébergés sur un serveur qq. part. Faut-il installer un outil de détection d'intrusion dessus ?

Ma petite expérience. A un moment j'avais installé un serveur SSH accessible depuis Internet sur ma machine perso (authentification uniquement par clé SSH, pas par mot de passe, uniquement un login $USER, pas root). C'est tout con, mais j'ai remarqué que des bots l'attaquaient en essayant plein de mots passe parce que le ventilateur de mon CPU tournait très vite (était bruyant). Je suppose qu'il existe des outils plus subtils qu'écouter un ventilateur :-)
- [^] # Re: Comment détecter une intrusion ?
  
  Posté par Olivier Esver (site web personnel) le 07 mars 2016 à 11:35. Évalué à 10.
  
  Pour les bots qui essayent des mots de passe, j'utilise fail2ban, qui fonctionne aussi avec les mots de passe htaccess d'Apache en plus d'SSH.
  Je n'autorise que 3 mauvais essais avant ban de 10 min de l'IP, ça ne sécurise pas mieux, mais ça peut ralentir les attaques brute force.
  
  S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
  - [^] # Re: Comment détecter une intrusion ?
    
    Posté par MarbolanGos (site web personnel) le 07 mars 2016 à 12:03. Évalué à 2.
    
    Il y a denyhosts qui fait aussi a même chose.
  - [^] # Re: Comment détecter une intrusion ?
    
    Posté par David Marec le 07 mars 2016 à 12:16. Évalué à 1.
    
    j'utilise fail2ban
    
    Je l'ai mis sur un serveur, mais je me contente surtout de règles de Packet Filter sur le port SSH; règles qui se déclenchent au nombres de tentatives de connexions, réussies au non, dans l'heure ou la demi-heure. Évidemment, à l'administrateur de ne pas se reconnecter trop fréquemment.
    Ça a l'avantage de régler le problème en amont. Je ne sais plus si failtoban ajoute des entrées dans le pare-feu…
    
    Je n'autorise que 3 mauvais essais avant ban de 10 min de l'IP
    
    J'ai surtout des attaques lentes, du genre une tentative toutes les dix minutes; mais, c'est peut-être parce que les plus bourrins ont déjà été filtrés.
    - [^] # Re: Comment détecter une intrusion ?
      
      Posté par Parleur le 07 mars 2016 à 14:52. Évalué à 2.
      
      Je ne sais plus si failtoban ajoute des entrées dans le pare-feu…
      
      Oui. Et le nom, c'est bien fail2ban.
    - [^] # Re: Comment détecter une intrusion ?
      
      Posté par THE_ALF_ le 07 mars 2016 à 16:37. Évalué à 3.
      
      Je confirme qu'un serveur se fait systématiquement scanner. Je filtre mon serveur (avec juste du ssh autorisé, tout le reste est fermé; il ne me sert en fait à pas grand chose d'autre que d'observer des tentatives de connexions en ce moment…) avec fail2ban + UFW. L'intérêt de UFW (qui permet de gérer simplement les iptables) et de rapporter toutes les tentatives de connections non autorisées (et donc les tentatives de connections sur tous les ports, ce qui permet aussi de détecter ceux qui scannent en barbare à la recherche de portes ouvertes). Très rapidement, cela s'est stabilisé à en gros un ban d'IP toutes les 8 minutes!
      Les IP proviennent d'un peu partout (TOP 5: Chine, USA, Corée, Russie, Brésil), ce qui laisse penser à des scans patients lancés à partir d'un grand nombre ordis disséminés (bots?) sur des grand ranges d'IP et de ports pour conserver une attaque constante malgré les bans.
      Du brute force au carré, bien organisé…
      - [^] # Re: Comment détecter une intrusion ?
        
        Posté par Pyscal le 08 mars 2016 à 11:58. Évalué à 5.
        
        https://wiki.archlinux.org/index.php/Port_knocking
        
        [^] # Re: Comment détecter une intrusion ?
        
        Posté par THE_ALF_ le 09 mars 2016 à 13:28. Évalué à 2.
        
        Tiens, je ne connaissais pas cette méthode. Merci, cela peut être intéressant à tester.
- [^] # Re: Comment détecter une intrusion ?
  
  Posté par Jehan (site web personnel, Mastodon) le 07 mars 2016 à 12:58. Évalué à 9.
  
  Comme notent d'autres, il existe des méthodes. En fait pleins à différents niveaux. C'est pour ça que je dis dans la news:
  
  Il y a peu de solutions à ce type de problème à l'heure actuelle en fait en tant qu'utilisateur (en tant que développeurs, il y a beaucoup plus).
  
  Car les admins ont quand même pas mal de possibilités de savoir ce qu'il se passe d'anormal sur un serveur en temps réel, et je dois dire que j'ai trouvé ceux de Mint un peu légers sur le coup. Comme je le dis, je ne suis pas du tout expert en sécurité non plus, ni admin de formation, et je ne doute pas une seule seconde que je puisse me faire trouer aussi. Mais je mets tout de même un minimum de sécurité et j'ai pas l'impression qu'ils en aient mis la moindre. J'ai un serveur perso qui me sert à héberger des sites web de projet ou associatifs, des emails, etc.
  
  Bon déjà j'ai fail2ban, que d'autres ont cité. Ça réduit les attaques de type "force brute". J'ai des règles très strictes pour SSH (je sais plus, probablement 3 tentatives seulement. On s'attend à ce que quelqu'un avec un accès SSH ne perde pas son mot de passe. D'ailleurs il devrait plutôt utiliser une clé). Un peu moins strictes (mais un peu quand même) pour IMAP (soyons un peu plus souple avec les utilisateurs IMAP qui peuvent être moins techniciens. Mais pas trop quand même. Au pire, l'utilisateur a son IP bloquée et il me contacte pour me demander de le débloquer). Des règles pour le HTTP (essayer de contenir un peu les DOS et autres bots un peu insistants), des règles sur les POSTs, des règles spécifiques Wordpress (tentatives de connexion répétées…), etc. On peut déjà pas mal limiter la casse avec fail2ban.
  
  Ensuite ça limite pas tout, par exemple si quelqu'un connaît déjà une faille particulière sur une plateforme (Wordpress ou autre) et n'a donc pas besoin de tester des injections SQL sur tous les formulaires avec un bot, etc. alors il ne sera pas détecté par fail2ban. Par contre si ça lui permet disons de changer des fichiers sur le serveur, on peut avoir un script qui surveille les fichiers du site web et envoie une alerte au moindre changement de fichiers. On pourrait d'ailleurs imaginer la même chose pour les pages vitales (comme la page de download) en base de donnée: chaque modif du texte envoie un email à l'admin (le seul qui aurait le droit de toucher la page). Si c'est lui qui vient de l'effectuer, il ignore l'email. S'il n'a pas touché à la page, il sait immédiatement qu'il y a un problème.
  
  Pour revenir sur les connexions SSH, car c'est un des nerfs du système, je reçois un email à chaque connexion SSH réussie (donc si je me suis pas connecté et que je reçois un email, je sais immédiatement qu'il y a un problème, puisque je suis le seul avec un accès). Bien sûr, je suis le seul admin sur mon petit serveur. S'il y avait 5 personnes avec accès au serveur (je ne parle pas d'un serveur avec accès simple-utilisateur, mais bien d'un serveur vital, genre pour les emails, le site, etc. Y aura jamais beaucoup de personnes autorisées sur celui-là) on peut imaginer alors un système un peu plus complexe en 2 temps, comme la réception d'un email automatique par cette personne seulement et l'obligation d'y répondre en moins de 5 minutes sinon tous les admins reçoivent une alerte à leur tour.
  Ensuite root: je reçois aussi un email à chaque login root, avec le nom de l'utilisateur d'origine (y a plusieurs moyens de connaître cette info, comme logname, etc. Aussi je précise que la connexion SSH en root direct doit toujours être interdite sur un serveur. Ça permet notamment de savoir qui est l'utilisateur de base, par exemple pour détecter les montées de privilèges). Même une connexion sudo pourrait générer des emails automatiques.
  
  Quant à un dump de base de données, je n'y ai jamais pensé et me rend compte que je n'ai rien fait, mais je suis sûr qu'il doit y avoir aussi moyen aussi de générer une alerte automatique à chaque tentative de dump. Vous pouvez ignorer votre message hebdomadaire (ou quotidien, pour un gros service) de backup, mais si vous recevez un message hors du créneau habituel, vous savez que quelque chose de louche est en train de se passer sur votre serveur.
  
  Etc. etc. Les idées ne manquent pas au niveau administrateur pour détecter des choses qui ne devraient pas se produire sur un serveur. Le fait est qu'on n'est pas trop censé toucher un serveur en production. Donc dès qu'il y a une activité un peu inhabituelle, c'est assez facile à détecter, et envoyer des alertes à chaque mouvement n'est pas overkill selon moi. Surtout lorsqu'on a juste quelques serveurs, comme c'est probablement le cas de Mint (je doute qu'ils aient 1000 serveurs en production). Ensuite oui si vous avez des centaines de serveur, vous ferez les choses différemment (enfin probablement similaire, mais vous voudrez pas recevoir des emails pour un oui ou pour un non. À ce moment, vous pouvez avec des scripts un peu plus ciblés, des interfaces de gestion de votre parc pour gérer les alertes, etc.).
  
  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
- [^] # Re: Comment détecter une intrusion ?
  
  Posté par christophe brocas (site web personnel) le 07 mars 2016 à 17:17. Évalué à 7.
  
  Je me dis que l'une des bonnes réponses aurait été de séparer le serveur au moins en deux :
  . Un serveur avec site web statique pour les annonces et les liens vers le serveur d'iso.
  . Un serveur avec de l'input user permise comme un site web de forums.
  
  Le premier est critique et on empêche au maximum l'accès externe (sur le serveur, pas d'interpréteur de commandes type PHP/Ruby prenant des inputs user).
  Le second, moins critique, prend des commentaires etc.
# Confusion entre empreinte et signature

Posté par Laurent Bonnaud le 07 mars 2016 à 11:39. Évalué à 6.

"mais aussi les signatures MD5 de vérification d'intégrité"

Merci d'écrire "empreinte" au lieu de "signature" et de réserver le mot "signature" à ce que l'on obtient avec GnuPG.
- [^] # Re: Confusion entre empreinte et signature
  
  Posté par Benoît Sibaud (site web personnel) le 07 mars 2016 à 13:00. Évalué à 3.
  
  Corrigé, merci.
- [^] # Re: Confusion entre empreinte et signature
  
  Posté par Jehan (site web personnel, Mastodon) le 07 mars 2016 à 13:00. Évalué à 2.
  
  C'est vrai. Un admin dans le coin? :-)
  
  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Quelques règles de base pour vos mots de passe

Posté par arnaudus le 07 mars 2016 à 11:49. Évalué à 10.

Ces règles sont de plus en plus chiantes. > 10 caractères, jamais les mêmes, pas de mots, pas de substitutions connues, des symboles ésotériques dont la place n'est jamais la même sur les claviers (voire absent de certains claviers). En gros, à part la gestion par un système de mots de passe random + portefeuille, il n'y a aucun moyen d'avoir des mots de passe acceptables.

Le fait est que 99% des gens ne respectent pas ces consignes. Il faudrait peut-être un jour se décider à comprendre que c'est le principe de la protection par MDP qui est troué (parce qu'il est humainement impossible de respecter toutes ces consignes), et que la faute ne vient pas des utilisateurs.
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 07 mars 2016 à 13:29. Évalué à -10.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Quelques règles de base pour vos mots de passe
    
    Posté par arnaudus le 07 mars 2016 à 13:59. Évalué à 10.
    
    Linuxfr me dit "Do not feed the troll", tu as donc été détécté comme un troll par le système :-)
    
    Je pense que tu n'as pas compris le sens de mon message. Je ne parle pas des mots de passe du style "1234", qui correspondent en effet à des gens qui se foutent du monde. Un "bon" mot de passe est un mot de passe qui ne peut pas être deviné. "Sésame Ouvre-Toi" est un excellent mot de passe, on peut passer sa vie devant la caverne en disant tout ce qui nous passe par la tête, et on ne trouvera jamais. Le problème, c'est qu'avec les progrès de l'informatique, les mots de passe peuvent être devinés. En clair, il devient de moins en moins possible pour un être humain de trouver des mots de passe respectant les principes de base du mot de passe (c'est un MOT, on peut s'en rappeler, on peut le transmettre à quelqu'un d'autre, il est secret et ne laisse pas de trace, etc). Regarde les conditions qu'on nous sort : ça ne doit pas être un mot, on doit utiliser des caractères qui ne sont pas des lettres, ça ne doit pas être prononçable, il faut les écrire et les conserver sur un papier—** un papier! **). Bref, c'est complètement con, ça n'est plus un mot de passe, c'est une clé. On a une clé par serrure, on ne se rappelle pas d'une clé (c'est un objet physique qu'porte sur soi), on n'a pas besoin de changer sa clé à moins qu'on pense que quelqu'un a pu la copier.
    
    Alors oui, je veux bien qu'on s'identifie sur Internet à l'aide de clés. C'est plus sûr et c'est probablement plus logique. Mais alors il faut donner des clés aux gens, et leur donner des porte-clés qui sont compatibles avec les clés. Il faut que quand ils arrivent dans un endroit, on leur refile la clé, et qu'on leur propose de la stocker dans leur porte-clé. Pour l'instant, la "solution", c'est de leur dire "Alors, votre clé c'est grande pointe-grand creux-petite pointe-grand creux - moyenne pointe plate - grosse pointe, si vous ne vous en rappelez pas démerdez-vous, et si quelqu'un la devine démerdez-vous", et je trouve ça complètement con.
  - [^] # Re: Quelques règles de base pour vos mots de passe
    
    Posté par Nairwolf le 07 mars 2016 à 13:59. Évalué à 4.
    
    J'ai jamais compris ce xkcd, car s'il y a beaucoup plus de bits d'entropie que le premier, il n'est pas forcément plus difficile à casser. Un script qui ferait une attaque par dictionnaire, un peu évolué, pourrait facilement le casser, vous ne pensez pas ?
    - [^] # Re: Quelques règles de base pour vos mots de passe
      
      Posté par Moonz le 07 mars 2016 à 15:33. Évalué à 7.
      
      s'il y a beaucoup plus de bits d'entropie que le premier, il n'est pas forcément plus difficile à casser
      
      Ben si, de par la définition d’un bit : la quantité d’information nécessaire pour diviser le nombre de possibilités par deux. Autrement dit, si un schéma a n bits d’entropie, par définition ça signifie qu’il faut tester environ possibilités pour le deviner (plus précisément, il faut tester possibilités pour avoir 100% de chance de le deviner, $2^{n-1}$ possibilités pour avoir 50% de chances de le deviner, $2^{n-2}$ possibilités pour avoir 25% de chance de le deviner…)
      
      4 mots tirés d’un dictionnaire de 3000 mots, c’est 3000⁴=81 téra-possibilités (téra=10¹²). C’est bien plus (environ un million de fois plus) que les 2**16 * 2 * 2 * 2**3 * 2**4 * 2**3 = 2**28 = 268 méga-possibilités (10⁶) offertes par le premier.
      
      Le problème de ce XKCD c’est qu’il ne présente pas l’alternative qui est une chaîne générée aléatoirement (au lieu de partir d’un mot de base). En se limitant à [a-zA-Z0-9], pour obtenir les 46 bits d’information équivalents, il suffit de 8 caractères. 7 si tu inclus les caractères spéciaux. Perso j’ai pas tellement plus de difficultés à retenir (sur le long terme) 8 caractères plutôt que 4 mots. Et c’est plus court à taper.
    - [^] # Re: Quelques règles de base pour vos mots de passe
      
      Posté par X345 le 07 mars 2016 à 15:52. Évalué à 5.
      
      Tu te trompes, le nombre de bits d'entropie définit complètement la sécurité d'un mot de passe. Si un mot de passe a b bits d'entropie, alors il faut essayer 2^b mot de passes pour le deviner, quelque soit le type d'attaque.
      
      La nombre de bits d'entropie d'un mot de passe est le log_2 du nombre de possibilités.
      
      Par exemple, pour 4 mots choisis au hasard dans un dictionnaire de 5000 mots (vocabulaire courant):
      entropie = log_2(5000^4) = 49 (bits d'entropie, ie 2^49 possibilités)
      
      Note qu'ici, on fait la supposition d'une attaque par dictionnaire: l'attaquant sait que le mot de passe utilisé est composé de 4 mots du dictionnaire.
      
      Pour un mot de passe de 8 caractères (majuscules, minuscules, chiffres = 2*26+10=62 possibilités par caractère):
      entropie = log_2(62^8) = 47 (bits d'entropie, ie 2^47 possibilités)
      
      Pour un mot de passe de 13 caractères (majuscules, miniscules, chiffres + caractères spéciaux courants = 2*26+10+10 = 72 possibilités par caractère):
      entropie = log_2(72^13) = 80 (bits d'entropie, ie 2^80 possibilités)
      
      Par définition, chaque bit d'entropie ajouté multiple la durée de l'attaque par deux.
      
      Si le service/site web est correctement configuré (ie pas plus de 1000 essais par seconde, comme dans l'exemple de XKCD), 40-50 bits d'entropie sont largement suffisants. Si la base de données fuite (offline crack) et utilise un hashage faible (par exemple 1 itération de SHA256), alors au minimum 80 bits d'entropie sont nécessaires. Si la base de données fuite et utilise un hashage fort (PBKDF2 avec 10000 itérations), 50-60 bits devraient suffire.
      - [^] # Re: Quelques règles de base pour vos mots de passe
        
        Posté par barmic le 07 mars 2016 à 18:04. Évalué à 4.
        
        Tu te trompes, le nombre de bits d'entropie définit complètement la sécurité d'un mot de passe. Si un mot de passe a b bits d'entropie, alors il faut essayer 2b mot de passes pour le deviner, quelque soit le type d'attaque.
        
        Faux. Sinon il n'y aurais pas de problème d'utiliser des mots du dictionnaire :)
        
        La subtilité c'est dans la phrase « il faut essayer 2b mot de passes pour le deviner ». Non il ne faut pas utiliser 2b mot de passe, mais potentiellement jusqu'à 2b mots de passe, hors les outil de brute force ne font des attaques par dictionnaires pour rendre "anticonstitutionnellement" moins solide que "ifiedikieayeijee".
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Quelques règles de base pour vos mots de passe
        
        Posté par barmic le 07 mars 2016 à 18:12. Évalué à 2.
        
        Pour en ajouter une couche. Quand tu prend des mots (et si on considère que l'outil de brute force prend en compte les mots), il ne faut pas calculer l'entropie de la même manière. Il ne s'agit plus d'une suite de N caractères choisi parmi [A-Za-z0-9._-,], mais d'une suite de M mots choisi dans des dictionnaires de quelques dizaines de milliers de mots (flemme de calculer l'entropie de chacun).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Quelques règles de base pour vos mots de passe
        
        Posté par X345 le 07 mars 2016 à 18:23. Évalué à 10. Dernière modification le 07 mars 2016 à 18:24.
        
        Non, ton calcul d'entropie est erroné et tu fais la même erreur que Nairwolf.
        
        Dans le calcul de nombre de bits d'entropie pour quatre mots du dictionnaire (5000 mots), je calcule 5000⁴ (49 bits) et non pas: 26²⁴ (112 bits) ce qui correspondrait à 4 mots aléatoires de 6 caractères chacun (ie 24 caractères aléatoires).
        
        Il n'y pas de problème particulier à utiliser des mots du dictionnaire, c'est juste que le dictionnaire est un ensemble de petite taille et donc génère une entropie assez faible. Si vous faites suffisamment (4-5) de tirages dans cet ensemble, l'entropie générée est satisfaisante.
        
        C'est exactement l'idée du XKCD: mieux vaut tirer trois mots aléatoirement du dictionnaire qu'un mot de passe alphabétique lowercase aléatoire de 6 caractères. C'est peut-être contre intuitif parce qu'on nous répète de craindre les attaques par dictionnaire depuis des années. Mais en faisant les calculs d'entropie, on voit que la première alternative est largement supérieure.
        
        Il n'y a pas de différence fondamentale entre une attaque bruteforce et une attaque dite par dictionnaire: dans les deux cas l'attaquant énumère un ensemble de mots de passe possible. La seule chose qui importe est la taille de cet ensemble.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 08 mars 2016 à 08:33. Évalué à -10.
        
        Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Quelques règles de base pour vos mots de passe
  
  Posté par Jehan (site web personnel, Mastodon) le 07 mars 2016 à 13:46. Évalué à 5.
  
  Ces règles sont de plus en plus chiantes.
  
  Clairement. Et ça va pas aller en s'améliorant avec des machines de plus en plus puissantes (même si les processeurs s'améliorent moins vite maintenant, le nombre de cœurs eux augmentent).
  
  Il faudrait peut-être un jour se décider à comprendre que c'est le principe de la protection par MDP qui est troué (parce qu'il est humainement impossible de respecter toutes ces consignes)
  
  Je suis d'accord. Malheureusement la solution viendrait surtout des systèmes de login centralisé (qui a aussi ses problèmes), et sur le coup, seuls les gros services propriétaires (Facebook, Google…) ont réussi à s'y faire une place. Même Mozilla a essayé et vient d'abandonner. Donc il n'y a encore rien de viable (l'alternative "service proprio" n'étant pas considérable comme "viable" pour moi).
  
  la faute ne vient pas des utilisateurs.
  
  Alors comme je disais dans mon article, ce n'est pas seulement la faute des utilisateurs, mais chacun a sa part de responsabilité. C'est trop facile de rejeter le blâme sur "les autres" et de considérer l'informatique comme "magique", et que ça devrait marcher "tout seul". Non, ce n'est pas comme ça que ça se passe.
  
  Par exemple je disais que les systèmes de login centralisé ont aussi leur lot de problème. Il y en a surtout un, majeur: un tel système est un "single point of failure" (point central d'échec?). S'il se fait trouer, un attaquant a accès à l'ensemble de vos services et données! Or que se passera-t-il au moment où un tel système est utilisé par tous? Les gens mettront-ils soudainement un mot de passe très fort sur ce point central? Pour beaucoup, non bien sûr que non! Ils continueront avec leur mot de passe à 5 caractères, qui est le nom du chien. Donc ça restera un très gros problème, peut-être pire.
  D'ailleurs je suis sûr que la plupart des gens ont des mots de passe bidons sur leur compte Facebook ou Gmail, alors que ce sont déjà des systèmes de login centralisé.
  
  En outre, je n'ai pas vu les utilisateurs se précipiter dès qu'on essaie de leur proposer des alternatives, que ce soit OpenID, Mozilla Persona, connexion validée par IM/XMPP… La plupart restent bien au choix avec leurs mots de passe faibles.
  
  Enfin si tu parles de connexions avec clés, le problème est que la plupart des utilisateurs trouvent cela trop compliqué et ne veulent simplement pas utiliser (il faut mettre la clé sur un support portable, genre clé USB, pour utiliser sur un autre ordi, vous vous rendez compte! Et encore ça c'est quand ils ont fait l'effort d'essayer). Même les dévs sur github, environ 30% n'auraient pas de clés (ce que l'auteur de l'article trouve bas, mais que je trouve haut car je me vois pas taper mon mot de passe à chaque git push). Donc on en est à chercher soit des systèmes que les utilisateurs comprennent (les mots de passe), soit à trouver des systèmes plus simples mais qui d'une manière ou d'une autre vont enlever un peu de liberté aux utilisateurs (comme les propositions d'avoir une identification "nationale", genre avec une puce dans la carte d'identité, ce qui veut dire que toute connexion avec serait traqué par le gouvernement, ou à l'heure actuelle les identifications par grosses sociétés qui traquent aussi, mais pour la publicité ciblée).
  
  Donc non, c'est trop facile de dire qu'aucune faute ne va aux utilisateurs. Ils sont encore (pour le moment) libres de choisir et ils font des choix, tous les jours. Cette façon de voir est trop asymétrique, si ce n'est dangereuse: aux uns (utilisateurs), on leur dit qu'ils ont bien le droit de ne pas réfléchir du tout et que d'autres devraient réfléchir à leur place (ce qui, selon moi, est une autre façon de leur dire qu'on veut leur enlever de la liberté); aux autres (développeurs et admins), on dit qu'ils sont vraiment trop des incapables — si ce n'est des idiots — de pas avoir encore trouvé le système de login idéal pour sécuriser complètement les connexions du premier groupe qui ne devrait pas avoir à réfléchir.
  Ce n'est pas ma vision du futur idéal (bien qu'on ait l'air de s'y diriger).
  
  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
  - [^] # Re: Quelques règles de base pour vos mots de passe
    
    Posté par lolop (site web personnel) le 07 mars 2016 à 14:07. Évalué à 4.
    
    Malheureusement la solution viendrait surtout des systèmes de login centralisé (qui a aussi ses problèmes),
    
    Ben, maintenant y'a France Connect et les fournisseurs d'identité numérique comme La Poste.
    
    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: Quelques règles de base pour vos mots de passe
    
    Posté par ariasuni le 11 mars 2016 à 00:27. Évalué à 5.
    
    C’est différent de dire aux utilisateurs/trices qu’ils ont le droit de ne pas réfléchir; et de les culpabiliser parce que personne dit d’apprendre ou ne leur apprends à utiliser correctement un système assez contraignant. Évidemment pour les utilisateurs/trices sensibilisées c’est un peu différent, mais pour les autres (l’écrasante majorité)?
    
    Faire porter (en partie) la responsabilité sur la victime de l’usurpation de compte ne résoudra rien; construire des systèmes plus simples et efficaces, et sensibiliser aux pratiques de sécurité basiques serait sans doute bien plus efficace à court terme.
    
    D’autre part, la plupart de la chaine de sécurité est déjà côté serveur (responsabilité des admins) ou dans les paramètres des applications (ex: navigateurs web) souvent inchangés (responsabilité des devs): utilisation d’une empreinte avec un bon algorithme et utilisation de sel pour la vérification des mots de passe, utilisation de connexions sécurisés avec versions récentes de TLS, maintenance et mise à jour des différents logiciels pour éviter les failles de sécurité, etc.
    
    Donc, à long terme, on peut penser à la promotion de la décentralisation pour limiter les dégâts en cas d’attaque, lutte générale contre les virus, trojan et botnets, financement et développement des logiciels critiques pour la sécurité (bibliothèques de cryptographie, systèmes de sandboxing, analyses statiques de code source, fuzzing, etc.), forcer à l’utilisation d’algorithmes de chiffrements plus solides, etc.
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Quelques règles de base pour vos mots de passe
      
      Posté par Jehan (site web personnel, Mastodon) le 11 mars 2016 à 18:57. Évalué à 4.
      
      de les culpabiliser
      
      Heureusement que j'ai dit explicitement:
      
      Le but n'est pas de culpabiliser l'utilisateur mais bien de le rendre acteur et responsable.
      
      Donc non, je ne cherche nullement à culpabiliser les utilisateurs, bien au contraire. Je ne dis d'ailleurs jamais qu'ils sont responsables de l'attaque ou du vol de données, ou de l'usurpation de compte, ou de quoi que ce soit du genre. Je dis qu'ils sont "responsables de leurs actes", et surtout "responsables" (tout court: des êtres responsables). C'est pour moi quelque chose de très important et de fondamental de responsabiliser les gens. C'est le même mot, mais avec un sens bien différent (notamment positif plutôt que négatif).
      
      sensibiliser aux pratiques de sécurité basiques serait sans doute bien plus efficace à court terme.
      
      C'est ce qu'essaient de faire beaucoup de sites de nos jours, avec des règles sur les mots de passe de plus en plus restrictifs (longueur minimum, mot de passe avec au moins majuscule, minuscule, nombre, caractère spécial…). Et en général, ce que j'entends quand un site essaie de "sensibiliser" ainsi les utilisateurs, c'est "tain ils sont chiants, ça me force à créer un nouveau mot de passe plutôt que mon mot de passe habituel".
      Quelqu'un citait même les impôts qui avaient tenté l'expérience de l'identification par clé et se sont retrouvé à être obligé de faire marche arrière car beaucoup de gens ne comprenaient pas.
      
      Le problème est que dès qu'un site essaie de sensibiliser à de meilleures pratiques ou de leur proposer des systèmes d'identification plus sécurisés, beaucoup se plaignent. Un mot de passe par contre, ça oui tous comprennent. Et de préférence, simple, et qu'ils pourront dire à tout le monde (ça me tue toujours les gens qui me donnent leur mot de passe pour utiliser leur ordinateur ou leur boîte email).
      
      D’autre part, la plupart de la chaine de sécurité est déjà côté serveur
      
      Oui et les développeurs et admins essaient d'améliorer les choses (la sécurité est quand même vachement mieux de nos jours, globabelement, qu'il y a quelques années), mais la sécurité n'est pas encore parfaite (et ne le sera sans doute jamais). Alors on fait quoi? On critique les admins et développeurs en leur mettant tout sur le dos et en les traitant d'incapables car ils ont pas encore réussi à trouver le système idéal? Ou en attendant ce jour (totalement hypothétique), on prend un peu sur soi, on fait un effort et on est "responsable"?
      
      Quand on achète une serrure moderne ultra-sophistiquée, on s'attend quand même à ce que vous preniez le temps de fermer la porte à clé en sortant (sinon la serrure sert à rien). Ou on achète une porte qui ferme en claquant, ce qui simplifie beaucoup, mais le jour où vous avez oublié la clé à l'intérieur, vous maudissez le fabricant d'avoir fait ce système. Et si vous avez une serrure biométrique, j'ose espérer que vous n'avez pas d'objet suffisamment de valeur pour donner envie à un voleur de vous arracher votre œil ou de vous couper le doigt (et même sans ça, les empreintes biométriques restent falsifiables). Y a pas de système parfait si on veut sécurité et confort d'utilisation.
      
      Conclusion: personne ne culpabilise ou ne rend responsable les utilisateurs des méfaits perpétrés par des malfrats. Mais on veut rappeler qu'ils sont tous des êtres responsables (tout court) et qu'ils doivent agir en tant que tel. Et donc on les sensibilise aux pratiques de sécurité basiques, notamment en écrivant cet article sur linuxfr.org. C'est donc exactement ce que tu demandes!
      
      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
      - [^] # Re: Quelques règles de base pour vos mots de passe
        
        Posté par ariasuni le 11 mars 2016 à 23:33. Évalué à 1.
        
        Heureusement que j'ai dit explicitement:
        
        Le but n'est pas de culpabiliser l'utilisateur mais bien de le rendre acteur et responsable.
        
        Oui enfin c’est pas parce que tu le dis que tu le fais.
        
        Je ne crois pas que nous soyons en désaccord sur le fond comme tu le dis, mais sur la forme et notamment les mots choisis. Effectivement, rendre acteur/trice de sa propre sécurité c’est une idée qui me plait aussi bien dans le fond que dans la formulation, c’est surtout le mot «responsable» qui m’a accroché car il véhicule l’idée c’est alors de sa faute s’il lui arrive quelque chose — c’est pourquoi j’ai parlé de formation d’utilisateurs/trices, et des contraintes plus fortes au moment du choix du mot de passe uniquement, c’est bien insuffisant…
        
        D’autre part, je tenais à réaffirmer à quel point tout le reste de la chaine est important, surtout que dans beaucoup de cas c’est bien les failles côté serveur qui risquent les données même pour celles/ceux qui utilisent un mot de passe raisonnablement fort. J’aurais beau avoir un bon mot de passe, s’il est stocké en MD5 sans sel j’aurais bien l’air maline.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Quelques règles de base pour vos mots de passe
        
        Posté par Jehan (site web personnel, Mastodon) le 12 mars 2016 à 14:51. Évalué à 4. Dernière modification le 12 mars 2016 à 14:54.
        
        Oui enfin c’est pas parce que tu le dis que tu le fais.
        
        Bon en même temps, si c'est ce que tu penses que j'essaie d'insinuer (tout en disant le contraire. Je le fais pour la forme, alors?), on peut aussi arrêter d'en discuter immédiatement. Non parce que les gens qui croient mieux savoir que toi ce que tu penses, ça commence à être fatigant. Affirmer que les utilisateurs seraient responsables d'une attaque sur un serveur qu'ils utilisent serait simplement d'une grave bêtise. C'est tout. Donc non ce n'est pas ce que j'ai dit, ni n'est ce que j’insinuerais en catimini.
        Je comprends même pas comment le sujet peut être mis sur le tapis. J'avais d'ailleurs remarqué l'autre fil en commentaire sur le propos mais avais résisté d'y répondre pour ne pas nourrir le troll. Bon bah je me suis fait avoir la seconde fois et ai répondu!
        
        le mot «responsable» qui m’a accroché car il véhicule l’idée c’est alors de sa faute s’il lui arrive quelque chose
        
        "Responsable" a plusieurs sens. Et "être responsable" (tout court) ne véhicule absolument pas cette idée, bien au contraire. Je suis contre la déresponsabilisation à tout va des êtres pensants, ce qui est une forme de débilitation, c'est à dire d'affaiblissement du pouvoir de choix et de décision attribué à chacun.
        
        tout le reste de la chaine est important
        
        Comme toute chaîne, tous les maillons sont importants. Si t'as des serveurs super sécurisés, si de son côté, l'utilisateur fait n'importe quoi, il a de grandes chances de perdre ses données quand même. Croire que tout se joue de l'autre côté est faux, et en plus dangereux (pour soi et autrui). Les utilisateurs doivent en être conscients, être responsables, et cesser de tout mettre sur le dos des autres.
        On parle de ce type d'attaques car elles touchent beaucoup de monde d'un coup, mais croire que les attaques sur compte unique n'existent pas, c'est se voiler la face. Y en a tous les jours, et j'en ai connu personnellement (en particulier une personne qui a perdu l'accès à son compte email et n'a même jamais réussi à le récupérer). Simplement certes les journalistes en parlent moins parce qu'on va pas faire un article chaque fois qu'un quidam quelconque perd son accès à un service (y aurait des articles tous les jours!), sauf lorsqu'il s'agit de personnalités, dissidents politiques, espionnage, journalistes, politiciens (ce sont juste quelques liens que j'ai trouvés en faisant une recherche vite fait. Je ne suis pas certain de la pertinence de toutes ces affaires, mais on en trouve pleins d'autres du genre. Y a l'embarras du choix)…
        
        Une simple petite recherche sur un moteur de recherche avec "compte email hacké" retourne pleins d'articles et d'histoires persos sur ce sujet, de fils de discussions sur des forums regorgeant de gens à qui c'est arrivé (pas des personnalités, ça arrive à tout un chacun même si on ne parle dans la presse que des cas où une personnalité est touchée), et pleins d'articles sur comment récupérer un compte compromis.
        
        Une grosse partie des compromissions ne se passent pas côté serveur, mais bien côté client, et ce quotidiennement. Simplement on n'en parle pas car ça fait moins jazzer dans la presse que X millions de comptes d'un seul coup. Alors non, toute la chaîne est important. Et justement promouvoir la sécurité seulement d'un côté, faire porter toute la sécurisation sur le "service" et ses admins/dévs, et dire aux utilisateurs que tout va bien, et de continuer comme ça, c'est justement irresponsable.
        
        Sur ce, ce sera mon dernier message sur le sujet.
        
        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
        
        [^] # Re: Quelques règles de base pour vos mots de passe
        
        Posté par ariasuni le 14 mars 2016 à 01:25. Évalué à 3.
        
        Oui enfin c’est pas parce que tu le dis que tu le fais.
        
        Bon en même temps, si c'est ce que tu penses que j'essaie d'insinuer (tout en disant le contraire. Je le fais pour la forme, alors?), on peut aussi arrêter d'en discuter immédiatement. Non parce que les gens qui croient mieux savoir que toi ce que tu penses, ça commence à être fatigant.
        
        Je vais prendre un exemple: «je suis pas sexiste/homophobe/etc. mais […]». On peut dire quelque chose et le penser en toute bonne foi mais se contredire sans le vouloir (parce que la réalité est souvent plus subtile que l’exemple grossier que j’ai utilisé). Je ne t’accuses absolument pas de mentir.
        
        Je suis globalement d’accord avec le reste de ton commentaire, et c’est logique que les personnalités prennent un peu plus de mesures de sécurité que les autres. Je voulais juste dire que c’est pas forcément aussi simple que «utilise un mot de passe fort» pour beaucoup de gens.
        
        Pour moi le système de mot de passe est cassé par conception puisqu’il nécessite de se remémorer un nombre important de suites de caractères plus ou moins arbitraires. On demande à un être humain de faire une tâche d’ordinateur. Et y’a des gens qui ont autre chose à foutre que ça, pas forcément par inconscience.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Quelques règles de base pour vos mots de passe
        
        Posté par Jehan (site web personnel, Mastodon) le 14 mars 2016 à 19:02. Évalué à 6.
        
        Je voulais pas répondre, et je vais passer outre les comparaisons absolument malsaines (et complètement hors sujet) auxquelles tu as essayé de m'associer. Mais je pouvais pas laisser dire ces choses ci-dessous:
        
        Je suis globalement d’accord avec le reste de ton commentaire, et c’est logique que les personnalités prennent un peu plus de mesures de sécurité que les autres.
        
        Non, on n'est pas d'accord! Je n'ai absolument pas dit que les personnalités doivent prendre plus de mesures de sécurité que les autres. J'ai dit au contraire que ça arrive à tout le monde mais qu'on n'entend parler que des cas qui touchent les personnalités. Et je suis désolé, mais mes données valent autant (et même 10000 fois plus, à mes yeux à moi) que celles de n'importe quelle personnalité. Alors à part si vous vous foutez de vos données numériques, de les perdre ou de les savoir entre des mains malveillantes (y a des gens qui s'en fichent réellement, donc c'est pas un "si" hypothétique. Je connais pas mal de gens qui sont bien moins engoncés dans les méandres de l'informatique), ben non tout le monde doit prendre plus de mesures de sécurité.
        
        Pour moi le système de mot de passe est cassé par conception
        
        Ce n'est pas cassé. C'est simplement le meilleur système que nous arrivions à produire que tout un chacun accepte d'utiliser à l'heure actuelle (attention, je ne dis pas "le meilleur système" tout court. Il y a bien plus sophistiqué mais beaucoup d'utilisateurs refusent ou sont rebutés/perdus, cf. par exemple le cas du site des impôts). Ce n'est pas la faute des gens qui essaient de créer ces systèmes si les gens refusent de faire autre chose qu'une "tâche d'ordinateur".
        
        <aparté>
        D'ailleurs c'est assez marrant de penser que c'est nécessairement une tâche d'ordinateur. Les mots de passe existaient bien avant que les ordinateurs existent (ex: Ali Baba et son "Sésame, ouvre toi", et on sait que les mots de passe étaient déjà utilisé des milliers d'années plus tôt, par exemple chez les militaires romains ou en Grèce ancienne, etc.). Et je pense que cette notion existera chez l'humain, en dehors même de toute interaction avec l'informatique et les machines, pendant encore longtemps. Et ça explique aussi probablement pourquoi dans l'informatique, les utilisateurs ne semblent pas enclins à s'essayer aux autres systèmes d'identification. En un sens, je comprends bien même (tout en étant d'accord que ça a des limites à cause de la puissance de calcul des ordis actuels, problème qui n'existait pas en Grèce ancienne!). C'est très similaire à la problématique du vote électronique que l'on discute souvent ici: les gens comprennent le système, donc ils lui font plus confiance (ou du moins sont plus rassurés) qu'en d'autres systèmes dont ils ne comprennent pas les arcanes.
        </aparté>
        
        Donc non ce n'est pas cassé. On n'arrive juste pas à la fois à trouver mieux, et à la fois à le faire accepter par tous. Si tu trouves ce Saint Graal, nous serons tous très heureux de lire les spécifications de ton système révolutionnaire. On n'attend que ça, un meilleur système acceptable par tous. Je pense même que tu en ressortiras riche. En attendant ce jour où tu nous donneras ce système, juste dire "le système de mot de passe est cassé par conception", ben c'est simplement condescendant. Des milliers de développeurs ou mathématiciens ont travaillé/travaillent sur les problématiques d'identification (et comme je l'ai expliqué, ça date pas d'hier) et arrivent difficilement à trouver le système idéal que tous acceptent d'utiliser (Mozilla s'y est aussi cassé les dents dernièrement!). Donc juste dire "c'est cassé", ce n'est pas un comportement constructif. Les seules choses constructives sont soit de trouver mieux, soit — en attendant — de sensibiliser les gens aux règles de base de la sécurité pour les protéger un minimum.
        
        Et y’a des gens qui ont autre chose à foutre que ça, pas forcément par inconscience.
        
        Eh bien si tu es absolument persuadée que leur dire en gros: « mais vous avez bien raison, vous avez autre chose à foutre que d'essayer de vous protéger un minimum. D'ailleurs c'est tout de la faute de ces idiots de développeurs qui nous font un système cassé par conception; le jour où vos comptes en ligne se feront compromettre et vos données effacées/copiées, vous pourrez vous dire que c'est de la faute du système et donc continuer ainsi plein de joie. » est plus constructif que d'essayer de dire « bon, on n'a malheureusement pas encore le système idéal. Il est imparfait, mais on fait ce qu'on peut et donc y a des limites à la sécurité de vos données; mais ensemble, si on suit quelques règles de base (un peu chiantes) et qu'on fait des efforts, on peut arriver à repousser un peu certaines attaques (des vrais responsables, qui ne sont ni les dévs ni les utilisateurs en général, on est tous d'accord sur ce point). »
        En gros si tu penses vraiment que les indulger plutôt que les former un peu à créer des mots de passe un peu plus sûrs que d'autres, si tu penses que ça, ce n'est absolument pas de l'inconscience… ben je sais vraiment plus trop quoi dire.
        
        Sur ce, cette fois c'est vraiment mon dernier message. J'ai assez nourri le troll.
        
        P.S.: moi aussi j'ai autre chose à foutre que fermer les portes, surtout qu'on sait bien que le système de clé est "cassé par conception" (vous avez déjà vu des vidéos de crochetage de serrure? Bon ceci dit, je considère pas ce système "cassé par conception" non plus, je reprenais juste l'exception. Là encore, c'est juste le meilleur compromis prix/simplicité/compréhension qu'on arrive à trouver pour sécuriser des portes). Pourtant je le fais quand même.
        
        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
  - [^] # Re: Quelques règles de base pour vos mots de passe
    
    Posté par Antoine le 15 mars 2016 à 15:37. Évalué à 3.
    
    En outre, je n'ai pas vu les utilisateurs se précipiter dès qu'on essaie de leur proposer des alternatives, que ce soit OpenID, Mozilla Persona, connexion validée par IM/XMPP…
    
    Personnellement je n'ai pas vu foule de services proposer ce genre d'intégrations. J'ai une identité OpenID mais je ne peux l'utiliser que sur un nombre de plus en plus faible de services externes.
    
    (et je passe sur les problèmes d'interopérabilité, du fait que la norme est plus ou moins bien implémentée par les uns et les autres…)
    
    Clairement. Et ça va pas aller en s'améliorant avec des machines de plus en plus puissantes (même si les processeurs s'améliorent moins vite maintenant, le nombre de cœurs eux augmentent).
    
    Pas forcément. En utilisant des fonctions de dérivation de clé (genre PBKDF2) avec un bon facteur de charge, il n'y a pas de raison que l'augmentation des performances oblige à rendre les mots de passe plus robuste (mais simplement à augmenter le facteur de charge, par exemple le nombre d'itérations).
- [^] # Re: Quelques règles de base pour vos mots de passe
  
  Posté par Matthieu le 07 mars 2016 à 17:32. Évalué à 5.
  
  Personnellement j'utilisais un mot de passe assez compliqué, j'avais tapé n'importe quoi sur mon clavier, 8 caractères et je l'avais appris par coeur. Des lettres et des chiffres uniquement. Depuis, je m'en suis fait un second de la même manière, mais avec des caractères autres que chiffres et lettres. Je recherchais le mot de passe ainsi histoire d'avoir quelque chose de particulier pas trop compliqué à saisir (le mouvement de saisie n'est pas chaotique).
  
  Depuis, j'ai compliqué mon premier mot de passe en me fabriquant une formule : je préfixe et je suffixe ce mot de passe par des séquences propres au service auquel je me connecte :
  
  Par exemple :
  - nombre de caractère du nom du service
  - 3e puis 1ere puis 2e lettre du nom du service (avec telle lettre en majuscule)
  - nombre de voyelles
  - …
  
  Vous pouvez choisir d'insérer un symbole entre la racine et le préfixe et/ou le suffixe.
  
  Ainsi, le mot de passe est unique au service. Vous ne devez retenir que le milieu et les formules.
  
  Si cela peut aider à sécuriser vos mots de passe.
  - [^] # Re: Quelques règles de base pour vos mots de passe
    
    Posté par Frank-N-Furter le 08 mars 2016 à 13:25. Évalué à 4.
    
    http://security.stackexchange.com/questions/80120/are-passwords-comprised-of-key-sequences-on-a-keyboard-any-less-secure-than-the
    
    Depending on the time of day, the French go either way.
# MINT met en avant les empreintes MD5 et ni les empreintes SHA256 ni les signatures GnuPG

Posté par Laurent Bonnaud le 07 mars 2016 à 11:58. Évalué à 3.

Sur la page de téléchargement de MINT, on trouve mises en avant des empreintes MD5 et c'est tout.

Quand on regarde sur un miroir, par exemple ici:

http://ftp.crifo.org/mint-cd//stable/17.3/

on trouve des empreintes SHA256 et surtout une signature GnuPG. Dommage qu'elles ne soient pas mises en avant.
- [^] # Re: MINT met en avant les empreintes MD5 et ni les empreintes SHA256 ni les signatures GnuPG
  
  Posté par fcartegnie le 07 mars 2016 à 15:26. Évalué à 8.
  
  on trouve des empreintes SHA256 et surtout une signature GnuPG. Dommage qu'elles ne soient pas mises en a
  
  Ca nous fait une belle jambe de vérifier la signature du résultat si les serveurs qui servent à faire les builds sont tout aussi sécurisés.
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 09 mars 2016 à 10:42. Évalué à -10.
  
  Ce commentaire a été supprimé par l’équipe de modération.
# Comment vérifier

Posté par Bobob le 07 mars 2016 à 12:23. Évalué à 3.

Salut,
Merci de ce décorticage précis. j'avoue être assez ennuyé par cette nouvelle, Linux Mint est particulièrement stable et pratique pour un univers Desktop (on l'installe à tour de bras dans une association bossant autour du numérique).

je sais que l'équipe de Tails travaille sur un plugin de vérification des empreintes

https://addons.mozilla.org/fr/firefox/addon/tails-download-and-verify/?src=search

Cela peut être intéressant.
j'avoue que c'est plus sympa à faire que la vérification qui se passe souvent en trois temps en ligne de commande. D'ailleurs, c'était galère de trouver les empreintes sur le site.

Vérification de la clef
-gpg --verify linuxmint.asc linuxmin.iso
L'ordinateur de connaît pas cette clef 3EF003F3

Import de la clef publique du signataire:
-gpg --recv-keys 3EF003F3

On vérifie à nouveau
-gpg --verify linuxmint.asc linuxmin.iso

La clef est marquée au pif.
Voilà, c'est une piste si des gens ont les compétences pour donner suite avec l'équipe de linux Mint
# "Nous" ?

Posté par MTux le 07 mars 2016 à 13:25. Évalué à 2.

nous ne saurions trop vous conseiller de

"Nous" ? Vous faites partie de l'équipe Linux Mint ?
- [^] # Re: "Nous" ?
  
  Posté par Benoît Sibaud (site web personnel) le 07 mars 2016 à 13:31. Évalué à 5.
  
  Pour éviter la confusion possible entre le « nous Linux Mint », le « nous les contributeurs de la dépêche » ou le « nous LinuxFr.org », j'ai reformulé les phrases concernées.
  - [^] # Re: "Nous" ?
    
    Posté par MTux le 07 mars 2016 à 13:50. Évalué à 2.
    
    Ok, car c'est donc un peu délicat de recommander publiquement aux gens de désinstaller Mint…
    - [^] # Re: "Nous" ?
      
      Posté par Jehan (site web personnel, Mastodon) le 07 mars 2016 à 14:05. Évalué à 10. Dernière modification le 07 mars 2016 à 14:07.
      
      Ça dépend. De désinstaller pour réinstaller, ça pas de problème. Même les dévs de Mint conseillent de tout supprimer, s'il y a le moindre doute. Par contre bien sûr, ces derniers sous-entendent: tout supprimer pour réinstaller.
      
      Là où je te rejoins, c'est qu'il est délicat de proposer de supprimer pour réinstaller une autre distribution, ce que je fais sur la fin. J'ai longtemps hésité si je devais faire cette suggestion ou pas. Mais à un moment donné, je me suis dit qu'il fallait être honnête avec moi-même. Personnellement je n'installerai plus Mint ni ne le conseillerai pour un petit bout de temps. Par contre je me tiendrai au courant et il n'est pas impossible que j'y revienne un jour. Mais dans l'immédiat, la confiance que je leur ai accordée à une époque a été ébranlée. C'est vraiment purement technique, rien d'émotionnel. Je serais heureux d'en discuter autour d'un verre avec un dév Mint. Je trouve toujours leur projet sympa, ainsi que les divers logiciels qu'ils ont créé, et je leur souhaite vraiment du succès. Je suis désolé pour eux, car c'est une position difficile. Mais je dois faire preuve d'honnêteté intellectuelle: je ne m'installerai plus de Mint pour l'instant, et ce serait donc malhonnête (et même presque malveillant) de prétendre que tout va bien et de conseiller aux autres ce que je refuserais pour moi-même.
      
      C'est donc ma position, et le raisonnement qui m'a poussé à ce conseil, même s'il n'est peut-être pas justifié techniquement (mais justement c'est aussi ça le problème: on a du mal à le savoir. Trop de choses sont encore passées sous silence dans les journaux officiels de Mint, comme je le note dans la dépêche).
      
      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
- [^] # Re: "Nous" ?
  
  Posté par MarbolanGos (site web personnel) le 07 mars 2016 à 13:32. Évalué à 2. Dernière modification le 07 mars 2016 à 13:32.
  
  "Nous" ? Vous faites partie de l'équipe Linux Mint ?
  
  Je suppose que c'est ça le nous :
  
  Posté par Jehan (page perso) le 07/03/16 à 11:01. Édité par 6 contributeurs. Modéré par Benoît Sibaud. Licence CC by-sa
  - [^] # Re: "Nous" ?
    
    Posté par Jehan (site web personnel, Mastodon) le 07 mars 2016 à 13:50. Évalué à 5.
    
    Je suppose que c'est ça le nous :
    
    Posté par Jehan (page perso) le 07/03/16 à 11:01. Édité par 6 contributeurs. Modéré par Benoît Sibaud. Licence CC by-sa
    
    En effet, le "nous", c'était "les contributeurs à la dépêche sur linuxfr" (c'est à dire la citation de MarbolanGos juste au dessus!). Je n'ai aucun lien avec Linux Mint, si ce n'est que j'en ai été un utilisateur à un moment donné, et que je trouve qu'il est important de relayer cette information (pour les gens sur linuxfr qui ne lisent que la première page).
    
    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
    - [^] # Re: "Nous" ?
      
      Posté par MTux le 07 mars 2016 à 13:50. Évalué à -4.
      
      Le passage où vous recommandez de désinstaller Linux Mint par sécurité est quand même un peu choquant.
      - [^] # Re: "Nous" ?
        
        Posté par ekyo le 07 mars 2016 à 14:02. Évalué à 3.
        
        Choquant ? Pourtant, cela me semble relever du bon sens : on ne sait pas à partir de quand les machines ont été compromises. Rien ne permet donc d'affirmer que ta réinstallation toute neuve n'est pas elle même compromise.
        
        De plus, cette affaire a mis en lumière plusieurs manquements aux bonnes pratiques de sécurité de la part de l'équipe Linux Mint. La transparence est réduite, les zones d'ombre nombreuses. La question est donc elle aussi légitime : si je suis soucieux de la sécurité, dois-je utiliser Linux Mint ?
# Mots de passe et imprécisions...

Posté par X345 le 07 mars 2016 à 13:53. Évalué à 10. Dernière modification le 07 mars 2016 à 13:55.
Pas mal d'imprécisions dans le paragraphe sur le stockage des mots de passe: confusion entre les hash tables et rainbow tables, méprise sur l'utilité du salt, et pas de mention de l'utilisation des GPU qui sont quand même la méthode à l'état de l'art pour le cassage des mots de passe.

Le problème général avec le stockage des mots de passe est que même si la fonction de hachage h utilisée pour hasher un mot de passe p est robuste, ie il est impossible de déterminer p à partir de h(p), il est (relativement) facile d'énumérer tout les p. En effet l'espace P des mots de passe p est relativement petit: on ne peut pas demander aux utilisateurs de retenir des mots de passe avec 25 caractères aléatoires. En général, on demande 8-15 caractères, ce qui génère un espace petit. Par exemple pour un mot de passe totalement aléatoire de 8 caractères comprenant majuscules, minuscules et chiffres, il y a ~2⁴⁷ possibilités, ce qui est énumérable avec les moyens actuels (une workstation avec un GPU à 1000€ vous permet de casser ça en quelques jours).

Un des premiers moyen utilisés pour accélérer le cassage des mots de passe a été d'utiliser des tables de hash précalculés. L'idée est simple: pour une fonction de hachage h donnée (exemple: h=md5 ou h=sha256), on précalcule h(p) pour tout les mots de passe p de 0-8 caractères. Ensuite, pour un hash h(p) donné, on cherche h(p) dans la table, et on retrouve p. Le problème est que ces tables précalculées ont une taille rédhibitoire: on est déjà à plusieurs téraoctets pour des mots de passe de 5-6 caractères, et la taille augmente exponentiellement avec le nombre de caractères (donc on est à des centaines de teras pour 8 caractères). Les rainbow tables ont été inventées pour résoudre ce problème. Très grossièrement, les rainbow tables permettent d'obtenir les mêmes résultats que les tables de hash précalculés, pour une fraction de l'espace de stockage (dizaines à centaines de gigas). J'ai l'impression que l'auteur confond les rainbow tables, avec les hash tables, une structure de données couramment utilisée qui n'a rien de spécifique à la cryptanalyse. On peut aujourd'hui facilement télécharger des rainbow tables sur internet pour de nombreuses fonctions de hachage (je vous laisse chercher hein…).

Pour se protéger des attaques basées sur les rainbow tables, on utilise un salt ou sel. L'idée est très simple: au lieu de stocker le hash du mot de passe h(p) dans la base de données, on stocke le hash de concaténation du mot de passe p et du sel s : h(s.p). La rainbow table qui stocke les correspondances h(p) -> p n'est donc plus utilisable, il faut recalculer une rainbow table pour chaque sel s. Plusieurs informations érronées dans l'article: les sels ne pas des information secrètes, vous pouvez les stocker dans la base de données, avec les hash. Même si le sel n'est pas secret, et leake avec les hashs, vous êtes protégés contre les attaques basées sur les rainbow tables. La seule contrainte est que le sel doit être de taille suffisante (64-128 bits c'est très bien), et différent pour chaque utilisateur. Il ne faut pas utiliser un sel unique pour toute la base de données, parce qu'à ce moment il devient possible de calculer une rainbow table pour votre base de données. Si le sel est différent pour chaque utilisateur, il faut calculer une rainbow table par utilisateur (ce qui la rend inutile, évidemment). Je le répète: un sel différent pour chaque utilisateur, et stockez-le dans la base de données et vous êtes protégés des rainbow tables.

Bon, malheureusement, les rainbow tables ne sont plus la méthode à l'état de l'art pour le cassage des mots de passe. C'était le cas il y a dix ans, mais depuis on utilise des GPUs. Les GPUs sont très efficaces pour calculer des fonctions de hashage: une machine avec 8 GPU (~8000€) peut calculer plus de 14 milliards de hash SHA256 par seconde (voir Performance hashcat). En d'autres termes, ce genre de machine peut bruteforcer 4 milliards de mot de passes par seconde. En quelques semaines/mois, vous pouvez casser n'importe quel mot de passe de 10 caractères (Speed Hashing). Pour 9 caractères, c'est quelques heures/jours. Et ce même si un sel a été utilisé.

Pour répondre à ce problème, une des techniques utilisés est le key stretching (mais malheureusement seuls peu de systèmes/sites utilisent cette technique). L'idée est simple: au lieu de hasher une seule fois h(s.p), on hashe itérativement un nombre configurable de fois (de l'ordre de quelques dizaines de milliers à quelques centaines de milliers) h(h(h(…h(s.p))). Parmi les algorithmes qui utilisent le key stretching on trouve PBKDF2 et sha512crypt. Par exemple, cryptsetup (utilisé pour le chiffrement disque sous Linux) hashe les mots de passe en utilisant sha256 pendant 2 secondes (sur ma machine, ça fait ~50000 itérations de sha256), GPG hashe les mots de passe en faisant 65536 itérations de SHA1. PAM (sha512crypt) fait 5000 itérations de sha512 (d'ailleurs de nos jours, 5000 itérations de sha512, c'est un peu léger). L'uilisation de PBKDF2 ou sha512crypt est aujourd'hui chaudement recommandée pour atténuer les attaques utilisant des GPUs.

Le problème du key stretching est que les GPUs restent toujours très efficaces pour casser les mot de passe. Même si vous réduisez le nombre d'essais de 4 milliards/s à 100 000/s, ça reste toujours beaucoup, surtout si vos utilisateurs ont des mots de passe "normaux": par exemple 8 caractères alphabétiques lower-case. Il est aussi possible de construire du hardware spécialisé (FPGA, ASIC) pour accélérer encore plus le cassage des mot de passage. Ça se voit avec les ASIC pour miner du bitcoin (qui calcule plein de fois des hash sha256) qui sont capables de calculer des centaines de milliards de sha256 par seconde.

Pour répondre à ce problème, on est en train d'inventer des fonctions de hashage memory-hard: le hash d'un mot de passe doit non seulement être couteux en temps mais aussi utiliser une certaine quantité de mémoire (par exemple 64Mo-1Go. Pour info, pour sha512 ou sha256, on est <1Ko). Ça permet de réduire à néant l'efficacité des GPU et du hardware spécialisé. Pour un GPU avec 16Go, il n'y a que "250 blocks" de 64Mo, ce qui l'empêche de calculer plus de 250 hash par seconde. Même chose pour les ASIC: des grandes quantité de mémoire restent couteuses en espace silicium, et aussi en complexité d'adressage. Ces fonctions de hashage memory-hard restent à l'état de recherche/prototype. En Juin 2015 a eu lieu la Password Hashing Competition dont le but était de sélectionner pour standardisation une fonction de hashage de mot de passe memory-hard. Le gagnant a été argon2 dont le code source est distribué sous CC0.

En résumé :
- Si vous êtes administateur ou développeur: utilisez un sel différent pour chaque utilisateur et stocké en base de données. Utilisez sha512crypt ou PBKDF2 1 avec le nombre maximal d'itérations que vous pouvez supporter. Si un délai de 0.5-1s pour une vérification de mot de passe est acceptable, utilisez 100000 itérations. Suivez l'évolution de argon2 (par exemple l'auteur de cryptsetup a annoncé sa volonté de l'utiliser), et implémentez-le lorsqu'il sort de sa phase de beta. Je fais partie de ceux qui pensent que ce n'est pas aux utilisateurs de retenir des mots de passe de 20 caractères aléatoires: c'est au admins de rendre les attaques par bruteforce impraticables.
- Si vous êtes utilisateur, et que vous voulez protéger votre mot de passe quoi qu'il arrive (ie même si l'administateur d'un site n'utilise pas de sel ni de key stretching), alors il faut un mot de passe d'au moins 13 caractères aléatoires. Sinon, éviter de partager les mots de passe entre différents service, éventuellement en utilisant un wallet ou keepass (les conseils données dans l'article sont tout à fait valides sur ce domaine).
[1]: Je connais mal bcrypt et scrypt mais ce sont probablement des alternatives correctes. Gardez à l'esprit qu'elles ne sont cependant pas standardisées.
- [^] # Re: Mots de passe et imprécisions...
  
  Posté par fredoche le 07 mars 2016 à 14:48. Évalué à 1.
  
  Excellent topo, merci. Le passage sur les fonctions de hachage "memory-hard" est très intéressant.
- [^] # Re: Mots de passe et imprécisions...
  
  Posté par Michaël (site web personnel) le 07 mars 2016 à 15:13. Évalué à 3.
  
  La seule contrainte est que le sel doit être de taille suffisante (128 bits c'est très bien), et différent pour chaque utilisateur.
  
  Question naïve: le choix (tout aussi naïf) consistant à prendre comme sel le nom civil de l'utilisateur (pas son login, souvent trop court pour arriver à 128 bits, mais son vrai nom) ou bien son login+date de naissance, numéro de personnel, etc. , sont donc des choix possibles et sains?
  
  Et merci pour ce commentaire-journal très détaillé et intéressant!
  - [^] # Re: Mots de passe et imprécisions...
    
    Posté par X345 le 07 mars 2016 à 15:22. Évalué à 6.
    
    Les schémas que tu proposes ne sont pas recommandés, mais pas très problématiques non plus. La seule propriété utile d'un sel est qu'il ne doit être utilisé qu'une et une seule fois. Avec 64 ou 128 bits aléatoires, tu es sur que jamais deux utilisateurs auront le même sel. Éventuellement en cas de particulière malchance, deux utilisateurs pourraient avoir le même nom civil ET la même date de naissance, et donc le même sel. Ce n'est pas recommandé, mais pas dramatique non plus (du moins de ce que j'en sais, je ne suis pas un expert).
    
    Le plus simple est de sortir 8 ou 16 octets de /dev/urandom (ou autre PRNG équivalent) et de les utiliser directement. Utiliser un uuid4 (random uuid) est également une bonne idée. La principale raison pour laquelle je ne recommanderais pas ce que tu proposes est la première règle de la crypto: "Don't roll your own" (ne faites pas votre propre crypto). Mieux vaut se cantonner à la pratique standard qui consiste à sortir 8 ou 16 octets d'un PRNG.
  - [^] # Re: Mots de passe et imprécisions...
    
    Posté par ariasuni le 11 mars 2016 à 01:04. Évalué à -1.
    
    Hors-sujet: Rappel que «civil» ≠ «vrai» nom. En plus on peut généralement mettre n’importe quoi dans ces champs de formulaires donc les informations peuvent ne pas être authentiques.
    
    Mon pseudonyme n’est pas moins vrai que mon nom civil, mon nom «social» (i.e. celui qui est utilisé la plupart du temps) n’est pas moins vrai que mon nom civil, etc.
    
    Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Mots de passe et imprécisions...
  
  Posté par Jehan (site web personnel, Mastodon) le 07 mars 2016 à 16:57. Évalué à 4.
  
  confusion entre les hash tables et rainbow tables
  
  Oui, ou même une erreur de ma part, plutôt qu'une confusion. Je voulais bien entendu dire les rainbow tables, pas hash tables qui sont en effet juste une structure de données qu'on utilise souvent en programmation.
  
  Pour le reste, je crois que tu es plus calé que moi sur ce sujet (initialement je voulais même pas l'écrire cet article, mais ça n'intéressait personne visiblement. J'espérais plus de contributions).
  
  Je n'ai pas envie d'encombrer l'article d'un passage beaucoup trop technique (qui va très bien en commentaire par contre, merci), par contre ce serait bien de remplacer mon texte erroné par une version simplifiée de ton texte. Si un admin passe dans le coin, ce serait possible?
  
  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Qui est responsable ?!?

Posté par Zorro (site web personnel) le 07 mars 2016 à 15:28. Évalué à 0.

"et il ne faut s'en prendre qu'à soi-même si vous n'avez pas protégé vos arrières."
Si je comprends bien, c'est la faute aux utilisateurs et administrateurs, et pas à ces misérables cons de voleurs qui pourrissent la vie de tout le monde… Ces pauvres gens ne font qu'obéir à leur nature, il faut les comprendre. Et s'ils viennent en plus vous narguer par des commentaires narquois et méprisants, c'est juste que c'est dans l'ordre des choses, très certainement.
C'est comme pour les filles violées, c'est bien sûr de leur faute, c'est elles qu'il faut punir.
- [^] # Re: Qui est responsable ?!?
  
  Posté par arnaudus le 07 mars 2016 à 17:33. Évalué à 10.
  
  Ça me gonfle aussi. Les assurances profitent énormément de ces raisonnements fallacieux, c'est de votre faute si un voleur est rentré chez vous par la porte ouverte, c'est de votre faute si on a regardé par dessus votre épaule quand vous tapiez votre code, etc.
  
  La responsabilité et la culpabilité reposent uniquement sur les gens malhonnêtes qui font sciemment des trucs illégaux. Ensuite, on peut reprocher aux gens un manque de précautions, mais l'absence de précautions dans un monde violent n'a jamais fait de quelqu'un un coupable. Ça n'a vraiment rien à voir.
  
  La seule exception est évidemment quand on parle d'un milieu professionnel. Un admin sys est payé pour assurer une certaine sécurité, et en tant que professionnel, il se doit de prendre un certain nombre de précautions (il est payé pour ça). S'il s'avère qu'il n'a pas pris les précautions qu'il étant cénsé prendre, alors oui, il doit en assurer la responsabilité. Ceci dit, cette responsabilité n'est pas une responsabilité légale, il n'a commis aucun délit (si on oublie cette loi débile, inappliquable, et inappliquée de sécurisation d'unaccès internet). Bref, il n'y a rien de comparable, et je suis complètement d'accord que c'est exactement le même raisonnement qui permet de dire qu'on a bien cherché de se faire agresser parce qu'on a trainé dans un quartier glauque.
  - [^] # Re: Qui est responsable ?!?
    
    Posté par Zorro (site web personnel) le 07 mars 2016 à 17:45. Évalué à 3.
    
    Oui.
    Il est amusant, et désespérant aussi, de constater qu'aucune suite légale n'est mentionnée dans la news Linuxfr. Peut-être dans les billets de blog de Mint, mais en tout cas rien dans la news.
    Comme si les actions de ces salopards étaient normales et qu'il faille faire avec, comme la pluie ou les orages ! Voilà, c'est comme ça.
    Mais capturer ou débusquer les méchants qui se cachent derrière la technologie est un sujet à haut risque, en ce moment…
    - [^] # Re: Qui est responsable ?!?
      
      Posté par Zenitram (site web personnel) le 08 mars 2016 à 08:15. Évalué à -3.
      
      Pas normal, mais oui il faut faire avec car ça existe, voila tout.
      Après, demande-toi l'utilité de porter plainte dans ton pays quand tu sais que l'@IP passe par un pays aussi coopératif que le Bélize, est-ce que la police va faire une pression diplomatique sur le Bélize pour tes quelques milliers d'utilisateurs compromis sans grande conséquence?
      
      C'est comme les déclaration de vol physique, si on t'a piqué 10€ vas-tu te faire plaisir à passer 3 heures au poste de police pour porter plainte? perso j'ai fait opposition sur ma CB la semaine dernière et ne compte pas aller au poste de police déposer plainte pour les quelques Euros (ben ouais, pour les plus gros montant je remercie la protection de ma CB avec un code envoyé sur mon mobile, j'ai reçu des codes que je n'avais pas demandé, plus simple que d'aller porter plainte) qui m'ont été piqué (et qui me seront remboursés), est-ce mal?
      - [^] # Re: Qui est responsable ?!?
        
        Posté par Zorro (site web personnel) le 08 mars 2016 à 11:11. Évalué à 1.
        
        Tu donnes pas des bons exemples. Tu prends le bout de la chaîne, avec des petits larcins pris individuellement. Mais 1. ceux qui ont été "petitement" attaqués peuvent très bien s'unir pour porter plainte. C'est le principe des plaintes collectives contre les petites arnaques, les fournisseurs d'accès, opérateurs, etc…
        2. Du côté des propriétaires des services (mince, je parle en ITIL, maintenant…), la somme des comptes volés vaut très cher, et en plus, ça met en cause leur business et ça peut potentiellement les ruiner.
        
        Mais bon, c'est comme ça, faut faire avec. Surtout pas remettre en cause des structures de réseaux complètement pourries qui permettent ces choses-là. Ni des merdeux encavés qui se prennent pour des héros du hack alors qu'ils font juste tourner des détecteurs de failles…
        
        [^] # Re: Qui est responsable ?!?
        
        Posté par Zenitram (site web personnel) le 08 mars 2016 à 11:53. Évalué à -4.
        
        Tu donnes pas des bons exemples.
        
        Mais tu n'as pas dit si tu es prêt à perdre 3 heures de ton temps pour porter plainte (qui sera sans doute mise dans un tiroir, et si elle ne l'est pas tu y passera encore plus de temps), toi individuellement.
        
        Facile d'accuser les autres, reste à savoir si toi tu seras le héros qui y passera le temps.
        
        J'ai justement donné des exemples qui font que dans la pratique, ça ne vaut pas le coup pour celui qui est "attaqué" et donc pas de motivation à le faire, mais c'est si facile d'accuser les gens de ne pas vouloir perdre leur temps…
        
        C'est le principe des plaintes collectives contre les petites arnaques,
        
        Les plaintes collectives sont une autre histoire : même processus pour tout le monde, un coupable, et généralement dans un pays "correct". Ici, ça n'a rien à voir (une attaque unique non généralisable, des pays non coopératifs), donc tu n'as contre-argumenté sur le sujet, juste fait du hors sujet.
        
        Surtout pas remettre en cause des structures de réseaux complètement pourries qui permettent ces choses-là.
        
        Ben, faudra savoir : je croyais ici les gens contre les scans automatiques de la NSA et pour le magnifique Tor et Bitcoin qui empêchent de choper les coupables, 2 choses incompatibles avec ta volonté de mieux faire avec les réseaux, ça devient schizophrène. Je t'en prie, donne une solution, car la tu dis "faut changer" mais sans rien proposer, donc bon en pratique tu ne proposes rien mais dit que c'est pas bien de ne rien faire. Bref, du vent pour ne rien dire mais juste critiquer gratuitement. Je demande plus que ça pour accepter une telle critique.
        
        Je ne donne peut-être pas de bon exemples, mais tu ne donnes pas de contre-exemples ni explique vraiment en quoi mes exemples sont des mauvais exemples (tu pars sur des principes théoriques, sans essayer de comprendre les gens), c'est un peu vide.
        
        [^] # Re: Qui est responsable ?!?
        
        Posté par ariasuni le 11 mars 2016 à 01:51. Évalué à 2.
        
        Merci de ne pas confondre schizophrénie et personnalités multiples, et merci de ne pas utiliser cette maladie comme insulte ou pour rabaisser une opinion.
        
        Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Qui est responsable ?!?
    
    Posté par gouttegd le 08 mars 2016 à 09:00. Évalué à 9.
    
    S'il s'avère qu'il n'a pas pris les précautions qu'il étant cénsé prendre, alors oui, il doit en assurer la responsabilité. Ceci dit, cette responsabilité n'est pas une responsabilité légale, il n'a commis aucun délit
    
    Euh, si. Du moment qu’il y a des données personnelles en jeu (il suffit de stocker des adresses e-mail par exemple), tu es légalement « tenu de prendre toutes précautions utiles […] pour préserver la sécurité des données et, notamment, empêcher […] que des tiers non autorisés y aient accès. »
    
    Ce n’est pas la loi HADOPI (« débile, inapplicable et inappliquée ») qui dit ça, mais la loi « informatique et libertés » du 6 janvier 1978 (article 34).
    
    Manquer à cette obligation est un délit, passible de cinq ans d’emprisonnement et 300 000 euros d’amende (article 226-17 du code pénal).
    
    Et la loi ne semble pas faire de différence en fonction du caractère professionnel ou amateur du sysadmin : si tu gères un STAD stockant des données personnelles, tu en es responsable, que tu sois payé à le faire ou pas.
# Le pirate c'est plus ou moins expliqué

Posté par Brunus le 07 mars 2016 à 17:57. Évalué à 4.

Effectivement le pirate, "Peace", avait compromis le site web depuis le mois de janvier.
Il indique que le botnet qu'il avait récupéré ne représentait que quelques centaines de machines et que le nombre a rapidement baissé suite à la découverte de l'attaque et la diffusion de l'information.

http://www.zdnet.com/article/hacker-hundreds-were-tricked-into-installing-linux-mint-backdoor/
# haveibeenp0wned.com

Posté par pasBill pasGates le 07 mars 2016 à 23:57. Évalué à 2.

ce site est assez connu pour ce qu'il fait est effectivement n'est pas une platforme de spam :)

Sinon, l'auteur n'est pas développeur/employé MS, il est MVP Microsoft(= un gars que Microsoft aime bien et à qui ils filent des trucs sympa car il aide leur communauté), pas la même chose, mais ça ne le rend pas plus suspect. Il s'affiche publiquement et est un peu connu.
- [^] # Re: haveibeenp0wned.com
  
  Posté par Jehan (site web personnel, Mastodon) le 08 mars 2016 à 00:28. Évalué à 3. Dernière modification le 08 mars 2016 à 00:30.
  
  Sinon, l'auteur n'est pas développeur/employé MS, il est MVP Microsoft(
  
  Oh ok. J'avais lu ça ("Microsoft MVP for Developer Security") et avais cru qu'il s'agissait d'un type de poste employé. Y a un admin pour mettre ça à jour?
  Merci pour la correction.
  
  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
  - [^] # Re: haveibeenp0wned.com
    
    Posté par Zenitram (site web personnel) le 08 mars 2016 à 08:19. Évalué à 2. Dernière modification le 08 mars 2016 à 08:21.
    
    (…) avais cru qu'il s'agissait d'un type de poste employé
    
    Wikipedia est ton ami ;-)
    https://fr.wikipedia.org/wiki/Microsoft_Most_Valuable_Professional
    "désigne une distinction"
    "Le programme MVP s'est développé initialement à partir de la communauté des développeurs"
    
    Bref, qui sait un jour tu seras un LinuxFr MVP (ou MVT, Most Valuable Trolleur) mais ça ne voudra pas dire que tu es employé ;-).
    (j'en profite pour dire un grand bravo pour la dépêche)
# Une attaque pour les discréditer tous ?

Posté par Shunesburg69 le 09 mars 2016 à 10:02. Évalué à -4. Dernière modification le 09 mars 2016 à 10:03.

Je veux pas faire mon parano mais quand j'ai lu les nombreuses news sur le net concernant cette attaque, j'ai pensé que si ça se trouve, c'est une attaque non pas pour récupérer de malheureux mails et des mots de passes qui de toute manière sont cryptés mais pour faire une grosse mauvaise pub contre l'une des plus utilisé distribution pour les débutants qui quittent Windows. Suis-je le seul à avoir pensé ça ? Surtout quand on voit que Windows 10 a peine à décoller et que Microsoft est obliger de migrer certains services vers Linux (.net, SQL…).
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 09 mars 2016 à 10:33. Évalué à -10.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Une attaque pour les discréditer tous ?
    
    Posté par Shunesburg69 le 09 mars 2016 à 20:50. Évalué à 1.
    
    leur systeme fetiche
    
    C'est marrant, je ne tourne pas sous LinuxMint mais sur OpenSUSE donc pas pertinent ton message.
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 10 mars 2016 à 12:56. Évalué à -10.
      
      Ce commentaire a été supprimé par l’équipe de modération.
# Exactement la période ou j'ai installé Mint à la place de Win10 sur mon PC ...

Posté par Kwiknclean le 15 mars 2016 à 12:37. Évalué à 2.

.. Bon ça fait plaisir.

Je ne peux pas vérifier d'ici, mais ma date d'installation correspond bien à la fourchette de hack … Il y a des chances que j'ai un charmant PC corrompu donc … à vérifier.

Ca m'ennuie tout de même pas mal de réinstaller je commençais à avoir bien tout tuner …

Et donc en attendant on met Mint sur la touche, vous me préconiserait quoi en parallèle … Sachant que Je n'ai pas envie de passer mes soirée à faire de la conf je veux du "plug and play" casi out-of-the-box … C'te bonne vieille Ubuntu ?
- [^] # Re: Exactement la période ou j'ai installé Mint à la place de Win10 sur mon PC ...
  
  Posté par Jehan (site web personnel, Mastodon) le 15 mars 2016 à 17:31. Évalué à 2.
  
  Ca m'ennuie tout de même pas mal de réinstaller je commençais à avoir bien tout tuner …
  
  Alors tu vas découvrir l'une des joies de Linux: sauvegarde tout ce qui est sous /home/ (par exemple sur un disque dur externe), et sur ta prochaine installation, copie simplement toutes ces données à la place du nouveau /home/. Et tadaaa! Toutes tes configurations (ainsi que les données bien sûr) sont retrouvées (pour peu que tu utilises les mêmes logiciels bien sûr)!
  Y a aussi le bureau dans le lot. Si tu utilisais Cinammon notamment (j'imagine, car l'ISO qui a été compromise était celle avec Cinammon par défaut), qu'il te plaisait et que tu l'as configuré, tu voudras peut-être t'assurer de réutiliser Cinammon après encore.
  
  En fait souvent tu n'as même pas besoin de sauver sur disque externe si le home était dans une partition propre, que tu peux simplement garder et réutiliser direct sans formater. Mais comme c'est un peu avancé, je conseille de toujours sauver le home au cas où (de toutes façons, il vaut mieux faire des sauvegardes dès qu'on touche au système. C'est dans les bonnes pratiques…).
  
  Et donc en attendant on met Mint sur la touche
  
  Comme d'autres le disent en commentaire, c'est à chacun de voir. Les développeurs de Mint disent que tout est réglé. Donc tu peux aussi simplement réinstaller Mint en téléchargeant une nouvelle ISO.
  C'est à chacun de décider s'il veut faire confiance immédiatement après cette compromission.
  
  Moi je préfère être un peu parano, mais pas tout le monde n'est obligé de l'être.
  
  vous me préconiserait quoi en parallèle … Sachant que Je n'ai pas envie de passer mes soirée à faire de la conf je veux du "plug and play" casi out-of-the-box … C'te bonne vieille Ubuntu ?
  
  De nos jours, la plupart des distributions (même celles considérées "avancées") sont assez plug'n play. De manières générales, les distribs estampillées "grand public" seront Ubuntu ou Mageia, je pense. Y en a sûrement d'autres, mais ce sont les deux qui me viennent à l'esprit.
  
  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
  - [^] # Re: Exactement la période ou j'ai installé Mint à la place de Win10 sur mon PC ...
    
    Posté par BAud (site web personnel) le 15 mars 2016 à 23:12. Évalué à 2.
    Comme d'autres le disent en commentaire, c'est à chacun de voir. Les développeurs de Mint disent que tout est réglé. Donc tu peux aussi simplement réinstaller Mint en téléchargeant une nouvelle ISO.
    
    avant de réinstaller, vérifier l'iso initialement utilisé (si conservé dans un coin) :
    - si les SHA1/MD5 correspondent à ceux actuellement annoncés sur le site de mint comme « bons » => pas besoin de réinstaller
    - sinon, réinstaller en listant au préalable les .deb qui avaient été installés (ce qui permettra de comparer et installer ceux manquants)
  - [^] # Re: Exactement la période ou j'ai installé Mint à la place de Win10 sur mon PC ...
    
    Posté par Florent Rougon (site web personnel) le 17 mars 2016 à 21:34. Évalué à 3.
    
    Hum, prétendre qu'il suffit « simplement » de recopier son /home pour récupérer sa config, c'est pas être parano, c'est même être un peu imprudent, à mon avis.
    
    Eh oui, quand on a été cracké, on ne peut faire confiance à pratiquement rien sur la machine crackée. Même en dehors des systèmes de fichiers, le secteur boot de chaque disque peut avoir été modifié (je crois que les Windowsiens connaissent bien ça). Dans le /home, il y a certainement des .profile, .bashrc, .zshrc, etc. et/ou un répertoire bin, ainsi que des fichiers de config divers et variés qui peuvent être mis à profit par l'attaquant pour récupérer le contrôle sur la nouvelle installation une fois que le /home aura été gentiment recopié. Lalala…
    - [^] # Re: Exactement la période ou j'ai installé Mint à la place de Win10 sur mon PC ...
      
      Posté par Jehan (site web personnel, Mastodon) le 18 mars 2016 à 00:41. Évalué à 2.
      
      Eh oui, quand on a été cracké, on ne peut faire confiance à pratiquement rien sur la machine crackée.
      
      Tu as raison. Mais il y a des limites à ce qu'un utilisateur est prêt à perdre. En l'occurrence, les données sont le truc qu'on peut difficilement proposer de supprimer. Tu ne peux pas dire à quelqu'un: "débarrasse toi de toutes tes données, au cas où".
      
      Ensuite ça dépend ce qu'on appelle données. Les configurations logicielles sont certes remplaçables. D'un autre côté, on peut y avoir passé beaucoup de temps au fil des années à peaufiner son utilisation et je sais que je tiens à mes scripts, et ce qu'il y a dans mon .bashrc, etc. Personnellement tous mes fichiers de configuration (enfin ceux auxquels je tiens, je fais du cas par cas) sont versionnés dans un dépôt de source. Ça me permettrait notamment de détecter des changements qui ne sont pas de moi (ensuite le serveur distant peut aussi théoriquement être corrompu, ainsi que mon dépôt local, un attaquant pourrait alors forcer un changement de l'historique pour que j'y vois que du feu, etc. Mais bon faudrait que ce soit une attaque sacrément ciblée).
      
      Il y a plein d'autres choses faisables, comme notamment des backups réguliers. Mais surtout sur le long terme, car si on a utilisé un système corrompu depuis un mois et que tes sauvegardes sont aussi vieilles de moins d'un mois, ben tes données sont aussi potentiellement corrompues. Et puis surtout pour quelqu'un avec un usage intensif de l'ordinateur, un mois de données (même une semaine), c'est une éternité et énormément de données (pas forcément en espace disque, mais beaucoup de choses ne se comptent pas en espace disque et valent tous les téras du monde).
      
      Enfin voilà, tout cela pour dire qu'il faut être parano, mais à un moment, il faut aussi savoir où s'arrêter. Sinon arrête tout de suite l'informatique avant de te rendre malade et de rentrer en dépression. D'ailleurs tout dépend de son lien (affectif, financier, de travail…) avec les données. Car si moi par exemple, je peux me permettre de dire "j'installe plus Mint" (ça me coûte pas grand chose d'aller voir les autres distribs), les dévs Mint par exemple ne vont bien entendu pas dire cela, après avoir codé dessus pendant des mois ou années. Pourtant les attaquants ont eu accès au système de fichier du site, à la base de données (en écriture aussi, j'imagine donc ils auraient aussi pu corrompre les données, et pas seulement les copier). Mais bon, ils vont pas dire "bon on efface le site, le forum et on recommence". Ils font un entredeux, et formateront probablement le système (enfin j'espère), mais garderont bien sûr les données et les fichiers de configuration importants après quelques vérifications et analyses des données.*
      
      Donc oui, il y a toujours des risques pour plein de choses. Mais à un moment donné, faut quand même vivre un peu. Quand je dis que je suis "parano", je le suis pas vraiment. Disons que je connais un minimum les risques informatiques pour être capable de dire aux gens qu'ils doivent arrêter d'être aussi insouciants, mais c'est pas pour autant que je vais m'enfermer chez moi et ne rien faire (ni encourager autrui à faire de même).
      
      (*) Au passage un utilisateur "normal" pourra difficilement faire des vérifs et analyse de ses données, hormis l'antivirus qui ne détecterait probablement pas un changement de fichiers de config.
      
      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
      - [^] # Re: Exactement la période ou j'ai installé Mint à la place de Win10 sur mon PC ...
        
        Posté par Florent Rougon (site web personnel) le 19 mars 2016 à 09:07. Évalué à 1.
        
        Ouh là, quelle réaction. :-)
        
        Bon, je pense qu'on est à peu près d'accord. L'idée à laquelle je m'opposais est celle selon laquelle sous Linux, on pourrait tranquillou recopier son /home et repartir comme en quarante. Si on est d'accord sur le fait que c'est faux, pas de problème.
        
        Alors, que faire en restant réaliste ? Tu évoques le cas de l'utilisateur qui ne serait pas capable d'auditer son .bashrc autrement qu'en s'en remettant à un antivirus. Un tel utilisateur n'a par définition pas pu faire de changement « intéressant » à ces fichiers-là(*), par conséquent il n'a pas besoin de les récupérer : mieux vaut repartir des versions installées avec la nouvelle distrib, je pense. Eh puis il y a les autres utilisateurs, qui ont passé peut-être des dizaines d'heures sur leurs fichiers de config ou autres. Dans ce cas, je pense qu'il faut manuellement sélectionner et inspecter les fichiers qui en valent la peine, un à un, avant de les réutiliser pour le nouveau système. C'est chiant, mais moins que de ce qui pourrait se passer si l'attaquant gardait le contrôle du système (en tout cas, c'est moins égoïste, car rappelons que les machines rootées servent très souvent de base pour attaquer d'autres personnes plus ou moins incognito—hélas, il y a beaucoup de personnes égoïstes :-/).
        
        Si les plus vieux backups que tu as datent d'un mois, c'est qu'il faut changer de système… de backup. Quant aux dépots Git et autres, je pense que c'est un des cas les plus simples à condition qu'ils aient un miroir en ligne et que d'autres personnes les utilisent et communiquent (oui, ça fait pas mal de conditions; la seule autre solution est de comparer avec un backup à mon avis…). Car même si l'attaquant a réécrit l'histoire dans le dépôt, à moins que tous les autres n'utilisent des paramètres très bizarres (--no-ff pour 'git pull' ?), ils vont s'apercevoir qu'il y a un problème en essayant de mettre à jour leur clone, et avant de se faire contaminer, en plus. Donc c'est bien. :-)
        
        (*) Il a peut-être des documents OpenOffice, mais ça, c'est autre chose et l'antivirus doit mieux marcher pour ce genre de fichiers à mon avis.
        
        [^] # Re: Exactement la période ou j'ai installé Mint à la place de Win10 sur mon PC ...
        
        Posté par Jehan (site web personnel, Mastodon) le 19 mars 2016 à 14:04. Évalué à 2. Dernière modification le 19 mars 2016 à 14:07.
        
        Bon, je pense qu'on est à peu près d'accord.
        
        Oui.
        
        L'idée à laquelle je m'opposais est celle selon laquelle sous Linux, on pourrait tranquillou recopier son /home et repartir comme en quarante. Si on est d'accord sur le fait que c'est faux, pas de problème.
        
        Dans ce cas précis, je suis d'accord qu'il devrait y avoir des étapes supplémentaires. Ensuite il y a des limites à ce qu'on demande à un débutant. Et ici, les risques seront similaires que l'on soit sous Linux, Windows, OSX ou n'importe quoi.
        Mais de manière générale, hors compromission, Linux est quand même vachement mieux dans le sens "je recopie mon /home et c'est reparti comme en quarante". ;-)
        Je me souviens encore quand j'utilisais Windows (c'était y a longtemps), quand je voulais formater, je passais une bonne semaine avant le formatage à me faire une liste de choses à pas oublier (puis à rechercher où cela pouvait bien être caché) car chaque logiciel sauvait ses données à des endroits divers. Bon de nos jours, apparemment c'est mieux, mais ça a toujours pas l'air idéal. Alors que Linux, il m'est arrivé régulièrement de changer de distributions, etc. sans me poser trop de questions sur mes données ou mes configurations logicielles.
        
        Si les plus vieux backups que tu as datent d'un mois, c'est qu'il faut changer de système… de backup.
        
        Tout dépend de ta quantité de données et de ton rythme de modification. Même en faisant des backups incrémentaux, cela risque de prendre beaucoup de place. Cas classiques: tu as régulièrement des fichiers binaires (vidéos, photos, sons/musiques, archives diverses…). En outre, il est conseillé de ne pas faire que des backups incrémentaux, et de temps en temps, refaire un full backup (par sécurité, car si tu as un backup incrémental corrompu dans ta chaîne de backups, c'est la merde). Par exemple, déjà-dup (le système que j'utilise sur les ordis de bureaux) fait des sauvegardes complètes de temps en temps.
        Donc supposons que tu fais des backups quotidiens. En un mois, tu as donc 30 backups. Si vous êtes 2/3 (ou plus) machines à partager votre serveur de backup, ça fait pas mal de données à sauver. Je viens de regarder mon serveur de backup. Pour 2 ordinateurs de bureau et 1 serveur, j'utilise 1.8T (ce ne sont pas forcément des backups quotidiens. En fonction des données notamment). Et ensuite, pour faire vraiment bien, il faut dupliquer ce backup sur un disque séparé (et de préférence même une machine séparée et dans un autre lieu. Car le jour où on a un feu ou un cambriolage, byebye les données).
        
        Pour ma part, je peux remonter à 6 mois, c'est pas si mal. Mais je pourrais tout à fait imaginer un utilisateur de base, un peu avancé donc qui fera des backups, mais n'y dédiera pas des disques de plusieurs teras. Dans ces cas, tu peux avoir des backups vieux d'un mois, mais ce n'est pas suffisant si ton système était corrompu depuis 2 mois.
        Sans compter que sérieusement, le jour où ça arrive, tu fais pas juste un full-revert. Deux mois de données et de travail, c'est juste énorme. Non parce que quand on a des mois de dessins, je me vois pas dire à l'animateur: "tu peux tout redessiner stp? Y avait un malware et par sécurité on a fait un revert de toutes les données" :P Donc les vieux backup, c'est utile pour des cas particuliers (par exemple on se rend compte qu'un fichier qu'on n'a pas touché depuis longtemps est corrompu pour raison X ou Y et on arrive à remonter à une époque où il l'était pas pour sélectionner seulement ce fichier). Mais pas pour des raisons du type "y a eu un malware, on ne peut faire confiance à aucune données depuis un mois, hop on revert tout!"
        
        Enfin voilà, tout ça pour dire que les sauvegardes sur du très long terme, c'est bien, mais il y a quand même énormément de cas où c'est loin d'être une solution suffisante et acceptable (dès que des données mouvantes rentrent en jeu, en fait).
        
        Ouh là, quelle réaction. :-)
        
        P.S.: désolé, encore une fois, j'écris trop! Et ce nouveau commentaire ne fait pas exception. :P
        
        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Suivre le flux des commentaires

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