Visualiseur de hash de chaîne, gratuit

Comment ça marche

1. Saisissez votre texte : tapez ou collez n'importe quelle chaîne, mot de passe, contenu de fichier, identifiant ou tout texte à hasher.
2. Choisissez un algorithme : sélectionnez MD5, SHA-1, SHA-256, SHA-384 ou SHA-512 selon votre besoin.
3. Copiez le hash : la valeur du hash apparaît instantanément. Copiez-la pour stockage, comparaison ou vérification.

Pourquoi utiliser le générateur de hash de chaîne ?

Le hachage transforme une chaîne quelconque en une empreinte de longueur fixe, propre à son contenu. Un seul caractère modifié produit un hash complètement différent. C'est essentiel pour vérifier l'intégrité des données, stocker des mots de passe en toute sécurité, générer des clés de cache, dédupliquer des enregistrements et créer des identifiants basés sur le contenu. Comme le hachage est à sens unique, impossible de retrouver le texte d'origine à partir du hash, ce qui le rend sûr pour stocker des données sensibles.

Fonctionnalités

• Plusieurs algorithmes : MD5, SHA-1, SHA-256, SHA-384 et SHA-512, tous dans un même outil.
• Hachage en temps réel : le hash se met à jour instantanément pendant la saisie, sans clic sur un bouton.
• Sensible à la casse : « Hello » et « hello » produisent des hash différents, par conception.
• Copier dans le presse-papiers : copie du hash en un clic.
• 100 % dans le navigateur : les chaînes ne quittent jamais votre appareil, sûr pour les contenus sensibles.

Questions fréquentes

Quel algorithme de hash choisir ?

Pour les usages sensibles (mots de passe, signatures), utilisez SHA-256 ou SHA-512. MD5 et SHA-1 sont dépréciés pour la sécurité mais restent utiles pour les sommes de contrôle et les clés de cache où la robustesse cryptographique n'est pas requise.

Puis-je utiliser cet outil pour hasher des mots de passe à stocker ?

Le hachage de chaîne vous donne un hash à sens unique, mais pour stocker des mots de passe, il faut utiliser une fonction de dérivation de clé comme bcrypt, Argon2 ou PBKDF2 qui intègre sel et itérations. Les simples hash SHA sont trop rapides et vulnérables aux attaques par tables arc-en-ciel.

Les hash sont-ils réversibles ?

Non. Les fonctions de hachage sont à sens unique, impossible de retrouver la chaîne d'origine à partir de son hash. Si deux chaînes produisent le même hash (collision), c'est un défaut de l'algorithme. SHA-256 et SHA-512 n'ont pas de collisions pratiques connues.

Une histoire de 35 ans de fonctions de hachage : de MD5 à BLAKE3

Les fonctions de hachage cryptographiques ont évolué à travers une longue séquence de cycles casser-et-remplacer. MD5 a été publié par Ronald Rivest dans RFC 1321 (avril 1992) en tant que successeur de MD4. Sa sortie de 128 bits a été considérée comme assez forte pendant plus d'une décennie jusqu'à ce que Wang et Yu publient la première collision pratique en 2004. En 2008, des chercheurs avaient utilisé des collisions MD5 pour forger une autorité de certification SSL malveillante. SHA-1 a été conçu par la NSA et standardisé par NIST dans FIPS 180-1 (1995). Sa sortie de 160 bits a tenu jusqu'en février 2017, quand Google et CWI Amsterdam ont annoncé l'attaque SHAttered, produisant deux PDF avec le même hachage SHA-1. Coûts : environ 6 500 années-CPU équivalentes sur GPU. SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512), aussi de la NSA, a été publié dans FIPS 180-2 (août 2002). Il utilise la même construction Merkle-Damgård que SHA-1 mais avec des états plus grands et plus de rounds ; aucune attaque pratique n'existe sur les versions complètes aujourd'hui. SHA-3 (Keccak, par Bertoni et al.) a été sélectionné par NIST après une compétition publique et standardisé dans FIPS 202 (août 2015). SHA-3 utilise une construction éponge complètement différente, immunisée contre les attaques d'extension de longueur qui affectent SHA-2. En dehors de la famille NIST, BLAKE2 (Aumasson et al., 2012) et BLAKE3 (2020) offrent une sécurité de classe SHA-3 à la vitesse de MD5 ; BLAKE3 hache un fichier de 1 Go en environ une seconde sur un ordinateur portable moderne.

Quel algorithme choisir : un tableau de décision rapide

• MD5 (128 bits). Cassé depuis 2004. Acceptable pour des usages non sécuritaires : invalidation de cache, déduplication de fichiers où vous contrôlez les deux côtés, sommes de contrôle contre la corruption accidentelle. Ne jamais utiliser pour les mots de passe, les signatures ou tout contexte adversarial.
• SHA-1 (160 bits). Cassé depuis 2017 (SHAttered). Git l'utilise toujours pour les hachages de commit, mais en mars 2017, Git a commencé à intégrer une détection de collision (SHA-1DC) pour refuser les motifs d'attaque connus. Évitez SHA-1 pour le nouveau code.
• SHA-256 (256 bits). Le cheval de trait actuel. Utilisé par Bitcoin, les certificats TLS, les signatures de paquets Linux, la signature JWT (HMAC-SHA256), et la plupart des API modernes. Rapide en matériel (extensions Intel SHA, extensions cryptographiques ARMv8). Choix par défaut pour le hachage général.
• SHA-512 (512 bits). Même famille, sortie plus grande. Légèrement plus rapide que SHA-256 sur les machines 64 bits car son état interne est 64 bits. Utilisez quand vous avez besoin de résistance aux collisions supplémentaire ou quand 256 bits semble contraignant (rare).
• SHA-3 / Keccak (224/256/384/512 bits). L'alternative éponge standardisée à SHA-2. Résistant aux attaques d'extension de longueur qui affectent SHA-2 (pertinent lors de la construction de hachages à clé sans HMAC). Plus lent en logiciel que SHA-256 sur la plupart des CPU mais immunisé contre une classe d'attaques différente.
• BLAKE2 / BLAKE3. Alternatives modernes non-NIST. BLAKE3 est le hachage cryptographique le plus rapide largement disponible, hachant à environ la vitesse de memcpy grâce au parallélisme. Utilisé dans b3sum, IPFS, et le protocole VPN WireGuard. Pas encore dans crypto.subtle, mais disponible via des bibliothèques.

Où le hachage est réellement utilisé

• Vérification de l'intégrité des fichiers. Les distributions Linux publient des sommes SHA-256 à côté des téléchargements ISO afin que vous puissiez vérifier que le fichier n'a pas été corrompu en transit ou modifié par un attaquant. sha256sum -c ubuntu.sha256 en 10 secondes.
• Stockage adressé par contenu. Git utilise SHA-1 (en transition vers SHA-256) pour identifier chaque commit, arbre et blob. IPFS, les images Docker (sha256:...) et les chemins du store Nix utilisent tous l'adressage par contenu. Le hachage EST l'identifiant.
• Clés de cache. Hacher une URL ou une requête sérialisée vous donne une clé de longueur fixe qui s'adapte à n'importe quel système de stockage. Stripe, GitHub, chaque CDN utilise ceci pour les recherches de cache.
• Déduplication. Les systèmes de sauvegarde (Time Machine, Borg, Restic) hachent les blocs de fichiers et ne stockent que les uniques. Deux blocs identiques de 4 Ko à travers différents fichiers correspondent à un seul morceau stocké.
• HTTP ETags. Les serveurs web envoient le hachage d'une réponse comme en-tête ETag. Les navigateurs le renvoient avec If-None-Match ; le serveur retourne 304 si inchangé. Économise des téléchargements redondants.
• Signatures JWT et webhook. Les JSON Web Tokens signent leur payload avec HMAC-SHA256 (HS256 dans la spec). Stripe, GitHub, les webhooks Twilio signent tous leurs payloads pour que vous puissiez vérifier qu'ils n'ont pas été altérés en transit.
• Blockchains. Bitcoin utilise un double SHA-256 pour la preuve de travail et le lien de blocs. Ethereum utilise Keccak-256 (une variante SHA-3). Tout le concept de blockchain repose sur la propriété que trouver deux entrées avec le même hachage est computationnellement infaisable.

Erreurs de hachage qui font perdre de l'argent ou cassent des choses

• Utiliser des hachages SHA pour le stockage de mots de passe. SHA-256 est rapide : un GPU moderne calcule ~10 milliards de hachages SHA-256 par seconde. Avec une base de données fuitée, un attaquant peut essayer chaque mot d'un dictionnaire plus toutes les transformations courantes en minutes. Utilisez Argon2id (gagnant du Password Hashing Competition 2015), bcrypt, ou scrypt. Ils sont délibérément lents et exigeants en mémoire.
• Oublier de saler. Même avec un hachage lent, le même mot de passe haché sans sel produit la même sortie pour tous les utilisateurs, permettant les tables arc-en-ciel et la détection par canal latéral des mots de passe dupliqués. Stockez toujours un sel aléatoire par utilisateur aux côtés du hachage.
• Attaques d'extension de longueur sur SHA-2. hash(secret + message) avec SHA-256 est vulnérable : un attaquant qui connaît le hachage et la longueur de secret peut ajouter des données arbitraires et calculer le hachage résultant sans connaître secret. Utilisez plutôt HMAC-SHA256. SHA-3 et BLAKE2/3 sont immunisés.
• Comparaison de chaînes en temps constant. Comparer des hachages (ou toute valeur secrète) avec == en JavaScript fuit des informations par le timing : une fonction qui sort au premier mismatch de byte permet aux attaquants d'apprendre le hachage correct byte par byte sur de nombreuses requêtes. Utilisez crypto.timingSafeEqual dans Node, hmac.compare_digest dans Python.
• Hacher des chaînes sans spécifier l'encodage. sha256("hello") en Python 3 lève une erreur (vous avez besoin de bytes) ; en Node il défaut à UTF-8 ; en PHP et Java le défaut peut varier. Différents encodages produisent différents hachages. Encodez toujours explicitement en UTF-8 avant de hacher.
• Tronquer les hachages pour des «IDs courts». Une tranche de 64 bits de SHA-256 est pratique pour les IDs courts mais le paradoxe des anniversaires signifie que les collisions apparaissent à ~2³² éléments (environ 4 milliards), pas 2⁶⁴. Si vous tronquez, planifiez la gestion des collisions à l'échelle attendue.
• Traiter la sortie de hachage comme une chaîne sûre pour URL. Les bytes bruts de hachage ne sont pas imprimables. Utilisez hex (le plus courant) ou base64url. Le base64 standard contient + et / qui cassent dans les URL et les noms de fichiers ; base64url est la variante sûre.

Plus de questions fréquentes

Pourquoi MD5 et SHA-1 sont-ils «cassés» s'ils produisent toujours des hachages ?

«Cassé» signifie qu'un attaquant peut produire des collisions plus rapidement que la force brute. Pour MD5, trouver deux entrées avec le même hachage prend des secondes sur un ordinateur portable aujourd'hui. Pour SHA-1, cela a pris 6 500 années-CPU en 2017 et a chuté dramatiquement depuis. Les hachages fonctionnent toujours mécaniquement ; ce qui est cassé est la garantie de sécurité qu'ils sont «résistants aux collisions». Pour les usages non-adversariaux (somme de contrôle d'un fichier en lequel vous avez confiance contre la corruption accidentelle), MD5 fonctionne toujours bien. Pour tout ce qui implique un adversaire, les deux sont dangereux.

Dois-je m'inquiéter des ordinateurs quantiques cassant SHA-256 ?

Moins que vous ne pourriez le penser. L'algorithme de Grover accélère les attaques de préimage contre un hachage de 256 bits de 2²⁵⁶ à 2¹²⁸ équivalent travail classique, ce qui reste effectivement impossible. Les primitives symétriques (hachages, AES) survivent au calcul quantique en doublant les tailles de clés/sorties. La cryptographie à clé publique (RSA, ECDSA) est ce qui tombe durement aux attaques quantiques, d'où les normes post-quantiques NIST publiées en août 2024 (ML-KEM, ML-DSA, SLH-DSA). Si vous utilisez SHA-256 aujourd'hui, SHA-512 dans l'ère post-quantique sera plus que suffisant.

Quelle est la différence entre un hachage et HMAC ?

Un hachage (SHA-256) est sans clé : quiconque a l'entrée peut calculer la même sortie. Un HMAC (Hash-based Message Authentication Code) enveloppe le hachage avec une clé secrète, de sorte que seul quelqu'un connaissant la clé peut calculer ou vérifier le tag. Défini dans RFC 2104 (1997), HMAC est la façon standard de «signer» un message symétriquement (l'expéditeur et le destinataire partagent un secret). Utilisez HMAC-SHA256 pour les signatures de webhook, JWT HS256, signature de requête API. Le simple SHA-256 sur secret + message est dangereux à cause de l'extension de longueur.

Pourquoi différentes bibliothèques donnent-elles différents hachages pour la même chaîne ?

Trois causes courantes. Premièrement, l'encodage de caractères : UTF-8 vs UTF-16 vs Latin-1 donnent différents bytes pour les chaînes non-ASCII, donc différents hachages. Encodez toujours explicitement. Deuxièmement, les fins de ligne : "hello\n" et "hello\r\n" hachent différemment ; les sommes de contrôle Windows-vs-Unix diffèrent souvent pour cette raison. Troisièmement, le format de sortie : hex minuscule vs hex majuscule vs base64 ressemble à une valeur différente mais représente les mêmes bytes. Normalisez les formats d'entrée et de sortie avant de comparer.

Mon entrée est-elle envoyée à un serveur quand je hache ici ?

Non. Les quatre hachages sont calculés dans votre navigateur en utilisant l'API Web Crypto intégrée (crypto.subtle.digest). Ouvrez l'onglet Réseau dans DevTools et tapez dans l'entrée, vous verrez zéro requête sortante. Sûr pour les identifiants, jetons ou toute valeur privée que vous voulez hacher sans qu'elle quitte votre appareil.