Les fichiers Zip protégés par mot de passe sont-ils sécurisés?
Après mon réponse . Si je peux lister le contenu d'un fichier Zip protégé par mot de passe, vérifier les types de fichiers de chaque fichier stocké et même le remplacer par un autre, sans vraiment connaître le mot de passe, alors les fichiers Zip doivent-ils toujours être traités comme sécurisés?
Ceci est complètement précaire en termes d'ingénierie/influence sociale, etc.
Je peux détourner (intercepter) le fichier de quelqu'un d'autre (fichier Zip protégé par mot de passe) et je peux remplacer l'un des fichiers qu'il contient par le mien (faux, virus) sans connaître le mot de passe. Le fichier remplacé restera non chiffré, non protégé par mot de passe à l'intérieur du Zip, mais les autres fichiers ne seront pas modifiés.
Si une victime déballe une archive protégée par mot de passe, le programme d'extraction ne demandera le mot de passe qu'une seule fois, pas à chaque fois pour chaque fichier. L'utilisateur final ne verra donc pas la différence - que le programme ne demande pas de mot de passe, parce qu'il le connaît déjà (fichier d'origine) ou parce que le fichier extrait n'a pas besoin de mot de passe (fichier modifié par moi). De cette façon, je peux injecter quelque chose de vraiment mauvais dans un fichier Zip protégé par mot de passe, sans connaître son mot de passe et compter sur le récepteur en supposant que le fichier n'est pas modifié.
Suis-je en train de manquer quelque chose ou est-ce vraiment faux? Que pouvons-nous dire sur les conditions de sécurité d'une solution, si le mot de passe ( n'est pas requis pour introduire tout modification dans un fichier protégé par mot de passe?
Pour y répondre, il faut une meilleure définition de "sécurisé" et/ou "sûr". Il faut toujours le définir en fonction de l'objectif de la protection et du risque pour le système. Il n'y a pas de taille unique ici, ce qui est "assez sûr" pour un système peut être terriblement faible pour un autre. Et ce qui est "suffisamment sûr" sur un autre peut être prohibitif ou tout simplement impossible dans un autre cas.
Donc, en prenant les préoccupations typiques une par une:
Confidentialité - au mieux marginal. La confidentialité est généralement évaluée en fonction du temps qu'il faudra pour accéder au matériel protégé. Je peux peut-être changer le fichier Zip, mais en tant que pirate informatique, cela me prendra un certain temps soit à casser le mot de passe, soit à le forcer brutalement. Pas beaucoup de temps, les mots de passe sont l'une des protections les plus faibles, et compte tenu de la façon dont les fichiers Zip sont souvent partagés, l'ingénierie sociale pour accéder au mot de passe n'est généralement pas difficile.
Integrity - nope - comme le souligne le demandeur - il est facile de changer le paquet et de le rendre légitime.
Disponibilité - généralement non applicable à ce type de contrôle de sécurité - cela fait généralement référence au risque de rendre un service indisponible - le stockage/conditionnement des données n'affecte généralement pas la disponibilité d'une manière ou d'une autre.
Non répudiation - non, pas de protection - n'importe qui peut modifier le paquet, donc toute personne y contribuant a probablement un déni.
L'astuce est - combien mieux voulez-vous obtenir? Le courrier électronique crypté est une option - comme une meilleure protection. Bien qu'il pose ses propres problèmes de connectivité. Et il existe de nombreuses meilleures façons de crypter les données - mais les meilleures options impliquent également des défis de distribution clés qui peuvent ajouter des soucis de temps et de coût.
Comme moyen rapide de regrouper et de partager certaines données que vous ne voulez pas rendre complètement publiques - c'est mieux que rien, et c'est parfois le seul dénominateur commun que vous pouvez déterminer. Pour tout ce qui est à haut risque, je trouverais une meilleure option.
Le mot de passe est destiné à garantir la confidentialité et non l'intégrité ou l'authenticité.
C'est l'un de ces cas où la sécurité est limitée par la convivialité et l'intention humaine. Le gestionnaire d'archives n'a aucun moyen de dire si le fichier que vous avez modifié devait ou non être crypté en premier lieu. Il s'agit essentiellement d'une attaque d'ingénierie sociale, dans la mesure où vous avez fait croire à l'utilisateur que le fichier d'origine était en place. Cependant, la véritable vulnérabilité de sécurité serait que vous disposiez en premier lieu d'un accès en lecture/écriture à une archive sensible.
En ce qui concerne l'atténuation, il existe plusieurs façons d'augmenter la sécurité:
- Utilisez un format d'archive qui prend en charge le cryptage des noms de fichiers (par exemple 7Zip, RAR)
- Signez l'archive avec une clé privée, par ex. via GPG.
Non. Pour créer un fichier crypté (de manière non sûre car le mot de passe est répété):
$ cd -- "$(mktemp --directory)"
$ echo secret > 1.txt
$ echo super secret > 2.txt
$ Zip -e -P Dig4BuOTFh secret.Zip 1.txt 2.txt
adding: 1.txt (stored 0%)
adding: 2.txt (stored 0%)
Pour savoir quels fichiers sont inclus:
$ unzip -l secret.Zip
Archive: secret.Zip
Length Date Time Name
--------- ---------- ----- ----
7 2013-05-14 10:15 1.txt
13 2013-05-14 10:14 2.txt
--------- -------
20 2 files
Pour remplacer un fichier avec de fausses données sans connaître le mot de passe:
$ echo lie > 2.txt
$ Zip -u secret.Zip 2.txt
updating: 2.txt (stored 0%)
Vérifier:
$ unzip -o -P Dig4BuOTFh secret.Zip
Archive: secret.Zip
extracting: 1.txt
extracting: 2.txt
$ cat 2.txt
lie
man Zip ne mentionne pas cette mise en garde dans la description du -e option, mais ce qui suit provient de la documentation de -P:
(Et lorsque la sécurité est vraiment importante, utilisez un cryptage fort tel que Pretty Good Privacy au lieu du cryptage standard relativement faible fourni par les utilitaires zipfile.)
Le chiffrement faible connu devrait être supprimé de l'utilitaire pour éviter un faux sentiment de sécurité, mais c'est une autre histoire.
Ce n'est pas sécurisé dans le sens où vous ne pouvez pas dépendre de l'intégrité du fichier Zip. La confidentialité est toujours de mise puisque vous ne pouvez pas accéder au contenu du fichier (uniquement les noms de fichier).
Cet inconvénient dans Zip a déjà été discuté, personnellement, j'utilise toujours rar simplement à cause de ce problème. Une autre solution consiste à signer le fichier Zip avec PGP.
En plus des risques que vous avez déjà signalés, à mon humble avis, l'un des plus gros problèmes avec les outils de compression est lié à l'utilisation de dossiers temporaires pour stocker les fichiers non compressés. Comme les fichiers d'entrée peuvent être de taille arbitraire, les fichiers de sortie non compressés peuvent ne pas tenir dans la RAM. Un dossier de sortie temporaire (souvent celui par défaut du système d'exploitation) est utilisé.
Peu importe la force de l'algorithme de chiffrement si vous oubliez de déchiqueter correctement les dossiers temporaires chaque fois que vous décompressez un fichier protégé par psw. La plupart des outils ne nettoient pas automatiquement le répertoire de sortie et n'en avertissent pas l'utilisateur. Même chose lors de la compression: vous devez vous assurer de déchiqueter le fichier d'origine.
Si je devais utiliser la définition générale de Secure pour signifier qu'elle applique la confidentialité, l'authentification, l'intégrité et la non-répudiation, je dirais que ce n'est pas sûr à plusieurs égards. Mais comme la protection par mot de passe sur un fichier Zip crypté ne vise qu'à assurer la confidentialité (interdisant la visualisation du contenu d'un fichier, sauf par les parties concernées), je dirais qu'il fait son travail.
La spécification officielle du format .Zip permet de masquer la liste des noms de fichiers (mais pas le nombre de fichiers), ainsi que de masquer les métadonnées telles que la taille du fichier d'origine et le CRC du fichier d'origine. Mais vous ne pouvez pas utiliser WinZip ou Info-Zip pour cela. De plus, l'intégrité dans la spécification officielle .Zip est fournie par l'utilisation d'une ou plusieurs signatures numériques en plus du cryptage. Ma recommandation personnelle, cependant, est d'éviter les mots de passe et d'utiliser à la place des clés publiques. Les fonctions de dérivation des clés sont de plus en plus rapides, et je ne pense pas qu'un fournisseur ait même essayé de suivre.
Si vous avez une version non chiffrée de l'un des fichiers dans un Zip protégé par mot de passe, vous pouvez utiliser une attaque en texte clair connue pour obtenir le mot de passe pour tous les autres fichiers.
Tout ce qui est protégé par mot de passe ne peut pas être piraté par des attaques par force brute. Cependant, les fichiers Zip peuvent être piratés par la force brute. D'autres systèmes ont des contrôles en place, comme par exemple le verrouillage après trois tentatives, des vérifications par clé, etc.
Donc, en fin de compte, à moins qu'il n'y ait une vulnérabilité ou une porte dérobée dans le code de cryptage, il est aussi sécurisé que votre phrase de passe résiste aux attaques par force brute. Il existe différents sites sur Internet où vous pouvez prototyper le schéma que vous avez l'intention d'utiliser, pour vérifier à peu près combien de temps il faudrait pour se fissurer. (N'utilisez pas CE QUE vous avez l'intention d'utiliser)
Tout ce que n'importe qui peut accéder physiquement est fissurable, avec suffisamment de temps. Cependant, vous pouvez bénéficier d'une sécurité pratique si le coût et/ou le temps requis pour accéder aux informations dépassent leur valeur probable. À moins qu'il ne s'agisse d'informations financières, il y a souvent une grande différence entre ce qui est précieux pour un pirate informatique et ce qui est précieux pour vous. Si le nom de votre fichier à l'intérieur du Zip est Attachment_1 et que le contenu non chiffré de l'e-mail ne décrit pas le contenu de la pièce jointe, cela ne donne pas grand-chose à un pirate. Un pirate ne sera probablement pas disposé à consacrer beaucoup de temps, et certainement pas d'argent, à accéder à quelque chose qui n'a pas une probabilité convaincante de contenir quelque chose de valeur pour lui.