SHA-1 Générateur de Hachage

A: Les deux sont non sécurisés, mais SHA-1 est légèrement meilleur que MD5. MD5 : 1) Sortie de 128 bits. 2) Cassé en 2004, complexité de collision 2^39. 3) Les attaques par collision peuvent être complétées en heures sur des ordinateurs ordinaires. SHA-1 : 1) Sortie de 160 bits. 2) Cassé en 2017, complexité de collision approximativement 2^63. 3) Les attaques par collision nécessitent des ressources computationnelles significatives mais ont été démontrées pratiquement. Conclusion : Aucun ne doit être utilisé dans des scénarios de sécurité ; utilisez SHA-256 ou des algorithmes de niveau supérieur.

A: Git utilise SHA-1 pour identifier les commits, les arbres et les objets, mais c'est un problème hérité. Raisons historiques : Quand Git a été créé en 2005, SHA-1 était considéré comme sécurisé. Compatibilité : Changer l'algorithme de hachage briserait la compatibilité avec tous les dépôts existants. Évaluation des risques : Le cas d'utilisation de Git (contrôle de version) diffère des certificats SSL ; le risque d'attaque par collision est relativement plus faible. Plan de migration : Git migre vers SHA-256 (Git 2.29+ le supporte), mais la transition prend du temps. Atténuation : Git implémente des mécanismes de détection de collision pour détecter les attaques de type SHAttered. Recommandation : Les nouveaux dépôts doivent utiliser SHA-256 ; les anciens dépôts peuvent continuer à utiliser SHA-1 (mais être conscient des risques).

A: Absolument pas. SHA-1 a non seulement des vulnérabilités de collision mais est également inadapté au stockage de mots de passe. Problèmes : 1) Trop rapide : Les GPU peuvent calculer des milliards de hachages SHA-1 par seconde, facilement cassable par force brute. 2) Vulnérabilité de collision : Les attaquants pourraient exploiter les collisions pour générer différents mots de passe avec le même hachage. 3) Pas de sel : Utiliser SHA-1 seul ne peut pas défendre contre les attaques par table arc-en-ciel. Approche correcte : Utiliser des algorithmes spécialisés de hachage de mots de passe : 1) Argon2 (recommandé par OWASP). 2) bcrypt (facteur de coût ≥ 12). 3) PBKDF2-SHA256 (≥ 600k itérations).

A: SHAttered est une attaque par collision SHA-1 démontrée par Google en 2017, prouvant que SHA-1 est pratiquement cassé. Principe de l'attaque : Générer deux fichiers PDF différents avec la même valeur de hachage SHA-1. Coût computationnel : Environ 6500 ans de temps CPU et 110 ans de temps GPU (calcul distribué). Impact : 1) Prouve que les attaques par collision SHA-1 sont faisables. 2) Le coût de l'attaque diminue avec le temps ; pourrait devenir plus facile à l'avenir. 3) Les principaux navigateurs ont cessé de faire confiance aux certificats SHA-1. Exemple : Google a publié deux fichiers PDF différents avec la même valeur de hachage SHA-1 (shattered.io).

A: Migrer vers SHA-256 nécessite d'évaluer l'impact et de développer un plan de migration. Évaluer l'impact : 1) Identifier tous les systèmes et composants utilisant SHA-1. 2) Évaluer la compatibilité et le coût de migration. 3) Déterminer les priorités de migration (scénarios sensibles à la sécurité en premier). Stratégies de migration : 1) Double hachage : Calculer à la fois SHA-1 et SHA-256, transition progressive. 2) Identification de version : Identifier l'algorithme de hachage utilisé dans les données. 3) Migration par phases : Migrer les nouvelles données d'abord, puis les anciennes données. Migration Git : Utiliser git config --global init.defaultBranch main et git config --global extensions.objectFormat sha256 pour créer des dépôts SHA-256.

A: SHA-1 n'est adapté qu'aux scénarios non liés à la sécurité et doit être migré vers des algorithmes plus sécurisés dès que possible. Usages acceptables : 1) Déduplication de fichiers : Identifier les fichiers en double dans des scénarios non liés à la sécurité (mais SHA-256 est meilleur). 2) Sommes de contrôle : Détecter la corruption accidentelle des données (pas la falsification malveillante). 3) Compatibilité avec les systèmes hérités : Maintenir des systèmes qui ne peuvent pas être mis à jour (solution temporaire). Usages inacceptables : 1) Signatures numériques. 2) Certificats SSL/TLS. 3) Signature de code. 4) Stockage de mots de passe. 5) Tout scénario sensible à la sécurité. Recommandation : Même dans des scénarios non liés à la sécurité, SHA-256 doit être priorisé car la différence de performance est minimale mais la sécurité est grandement améliorée.