Français

Outils de développement · Calculateur de hachage SHA

Le hachage n'est pas un cryptage : pourquoi un hachage SHA-256 ne peut pas être déchiffré

· Pourquoi c'est important

cryptographie sécurité codage

Entrée circulant dans une fonction de hachage avec une flèche pointant vers l'avant pour digérer, mais aucune flèche ne revenant vers l'arrière
Illustration vectorielle originale de ToolAcre

Il n'y a ni clé ni inverse : un hachage est une fonction à sens unique. Cet article explique la différence avec le cryptage, pourquoi les sites de recherche de hachage semblent inverser les hachages et ce que cela signifie pour le hachage des données personnelles.

Veuillez décrypter ces hachages – le ticket qui révèle un malentendu sur ce qu'est le hachage

Un ticket d'assistance arrive demandant de décrypter certains hachages SHA-256. Le développeur qui le lit soupçonne un malentendu sur ce qu'est le hachage. La confusion est logique : le hachage et le chiffrement impliquent tous deux des algorithmes cryptographiques, tous deux produisent une sortie qui semble brouillée et tous deux sont pertinents pour la sécurité. Mais ce sont des outils fondamentalement différents. Le cryptage est réversible ; le hachage ne l’est pas. Cette distinction est suffisamment importante pour que leur confusion ait brisé les véritables systèmes de sécurité. Le ticket représente une lacune courante dans la compréhension qui affecte la conception du système.

Une fonction de hachage est une fonction unidirectionnelle. Vous pouvez hacher une entrée pour obtenir un résumé, mais il n'y a pas de clé ni d'opération inverse qui récupère l'entrée du résumé. Il ne s'agit pas d'une limitation ou d'un bug ; c'est la propriété déterminante d'un hachage. Le calculateur de hachage ToolAcre SHA produit des résumés du texte que vous collez, et il n'y a pas de bouton « décrypter » car aucun bouton ne peut exister. L’opération est irréversible par les mathématiques et non par choix. L’absence de fonction inverse n’est pas une fonctionnalité que vous pouvez demander.

Le cryptage a une clé et un inverse ; le hachage n'a ni l'un ni l'autre - la différence de définition en termes simples

Le cryptage fonctionne différemment. Un algorithme de chiffrement prend du texte en clair et une clé et produit du texte chiffré. Le texte chiffré est brouillé et illisible sans la clé. Surtout, la même clé peut déchiffrer le texte chiffré en texte brut. Le cryptage est réversible de par sa conception. Vous chiffrez pour garder les données secrètes ; vous décryptez pour le relire. La sécurité du cryptage dépend du secret de la clé. Seul le détenteur de la clé peut inverser la transformation.

Le hachage n'a ni clé ni inversion. Vous hachez quelque chose pour produire un résumé de longueur fixe. La même entrée produit toujours le même résumé. Une entrée différente produit un résumé différent, c'est-à-dire la propriété de résistance aux collisions. Mais vous ne pouvez pas faire un résumé et produire une contribution. La fonction ne va que dans un sens. Si vous devez chiffrer des données pour pouvoir les décrypter plus tard, le hachage n’est pas le bon outil. Si vous avez besoin d'une empreinte digitale de données pour la vérification ou l'adressage du contenu, le hachage est correct. Choisir le bon outil nécessite de comprendre la différence.

Comment fonctionnent les sites de recherche de hachage : dictionnaires précalculés d'entrées courantes, pas de décryptage

Cette distinction est si importante qu'elle sous-tend la sécurité de la vérification du mot de passe. Un serveur ne stocke pas les mots de passe. Il stocke le résultat du hachage du mot de passe. Lorsqu'un utilisateur se connecte, le serveur hache sa soumission et la compare à la valeur stockée. Si le serveur est compromis et que sa base de données est volée, l'attaquant n'obtient pas les mots de passe lui-même, mais uniquement les hachages. La nature unidirectionnelle du hachage signifie que l’attaquant ne peut pas procéder à une ingénierie inverse des mots de passe à partir des hachages. La sécurité du système dépend de cette propriété.

Si le serveur utilisait le cryptage à la place (s'il chiffrait les mots de passe et pouvait les déchiffrer), alors une compromission qui volait la clé exposerait immédiatement chaque mot de passe. Le hachage est choisi spécifiquement parce qu’il est irréversible. C'est pourquoi les systèmes de mots de passe utilisent le hachage et non le cryptage. L'irréversibilité n'est pas une limitation ; c'est tout le modèle de sécurité. Une base de données de mots de passe cryptés est fondamentalement plus faible qu’une base de données hachée car le cryptage est réversible.

Les entrées à faible entropie constituent la faiblesse : pourquoi le hachage d'une adresse e-mail, d'un numéro de téléphone ou d'un code PIN court offre peu de protection

Les sites de recherche de hachage existent pour créer l'illusion du décryptage. Ces sites hébergent des tableaux précalculés d'entrées communes et de leurs hachages. Les « tables arc-en-ciel » sont des dictionnaires pré-préparés : un tableau peut contenir les hachages des milliers de mots de passe les plus courants, ou toutes les combinaisons alphanumériques jusqu'à une certaine longueur, ou des listes de mots entières dans plusieurs langues. L'opérateur du site a déjà effectué le travail de hachage et stocké les résultats. Lorsque quelqu'un soumet un hachage à un site de recherche, le site ne décrypte rien. Il recherche simplement le hachage dans sa table. Si le hachage est présent (si un mot du dictionnaire ou un modèle de mot de passe correspond), la table renvoie l'entrée d'origine. Cela ressemble à un décryptage magique pour quelqu'un qui ne connaît pas la technique, mais il s'agit simplement d'une recherche dans une base de données. Le site n'inverse pas le hachage ; il le compare à des valeurs précalculées.

Exemple concret : hacher une valeur devinable et montrer comment un dictionnaire la récupérerait, par rapport à une longue valeur aléatoire qu'il ne pourrait pas

C'est pourquoi les intrants à faible entropie sont vulnérables. Si vous hachez un mot de passe commun tel que « mot de passe » ou une valeur prévisible comme l'adresse e-mail d'une personne, il y a de fortes chances qu'un site de recherche ait déjà calculé ce hachage et l'ait stocké. La recherche renvoie instantanément la valeur d'origine. Si vous hachez une chaîne aléatoire de 256 caractères, aucun site de recherche sur terre ne verra ce hachage particulier précalculé. Le site de recherche ne renvoie rien, car l'entrée ne figurait pas dans son dictionnaire. La sécurité du hachage dépend entièrement de l'entropie de l'entrée.

Le calculateur de hachage ToolAcre SHA le démontre directement. Hachez un mot courant et un attaquant déterminé pourrait le rechercher s'il exécutait son propre service de dictionnaire. Hachez une longue valeur aléatoire, et même un dictionnaire massif ne la contiendra probablement pas. Le déterminisme du hachage (des entrées identiques donnent des résultats identiques) est ce qui rend les attaques par dictionnaire possibles. C’est aussi ce qui rend les hachages utiles pour la vérification. La même propriété qui permet la recherche permet également la vérification.

Lorsque vous souhaitez réellement un chiffrement : les cas où les données doivent ressortir et où le hachage n'est pas le bon outil

Lorsque vous souhaitez réellement un chiffrement (lorsque vous devez envoyer des données secrètes et les récupérer plus tard), un chiffrement est le bon outil. AES est la norme moderne de chiffrement symétrique : une clé est partagée, et elle chiffre le texte en clair et déchiffre le texte chiffré. La cryptographie RSA ou à courbe elliptique est utilisée pour le chiffrement asymétrique : une clé publique chiffre et une clé privée déchiffre. Ces outils sont réversibles par conception. La sécurité vient du secret clé et non de l’irréversibilité. L'erreur consiste à utiliser le hachage là où le cryptage est nécessaire. Si vous hachez un numéro de carte de crédit dans l’intention de le vérifier plus tard, vous n’avez aucun moyen de le déchiffrer. Si vous hachez un identifiant personnel et devez le récupérer ultérieurement, le hachage n’est pas un bon choix. Ce sont des situations qui nécessitent un cryptage.

Un exemple concret sépare clairement les deux utilisations. Vous disposez d’une liste d’identifiants d’utilisateur qui doivent rester secrets les uns des autres et de votre propre personnel. Vous les chiffrez avec AES et stockez le résultat. Plus tard, lorsque vous avez besoin de rechercher un utilisateur, vous le décryptez et le lisez. Le hachage ne fonctionnerait pas ; une fois hachés, les identifiants sont perdus à jamais. En revanche, vous disposez de mots de passe utilisateur. Vous les hachez et stockez le hachage. Lorsqu'un utilisateur se connecte, vous hachez sa soumission et la comparez à la valeur stockée. Vous n'avez jamais besoin de récupérer les mots de passe eux-mêmes. Le cryptage serait une erreur ; vous n'avez aucune utilité pour les mots de passe en clair après la configuration initiale.

Ce que cela ne couvre pas : les conceptions de hachage à clé et salée, qui relèvent la barre mais constituent un sujet distinct

Le salage et le hachage à clé méritent un traitement séparé, car ni l'un ni l'autre ne transforme un résumé en chiffrement. Un sel fait en sorte que des entrées égales à faible entropie produisent différents enregistrements stockés, et une clé peut restreindre qui calcule une valeur d'authentification valide. La sortie reste irréversible ; les tentatives de récupération se déroulent toujours en testant les entrées candidates plutôt qu'en appliquant un inverse.

Le hachage de mot de passe ajoute un coût délibéré ainsi qu'un sel, tandis que HMAC authentifie les messages avec une clé secrète. ToolAcre n'implémente aucune des deux opérations. Les garder en dehors de cet article évite le raccourci dangereux consistant à décrire simplement SHA-256 plus un préfixe improvisé comme équivalent à un enregistrement de mot de passe révisé ou à une construction d'authentification de message.

À retenir : un seul sens : le calculateur de hachage ToolAcre SHA calcule les résumés ; il n'y a pas de bouton inverse car aucun ne peut exister

Le calculateur de hachage ToolAcre SHA vous montre le hachage en action : collez du texte, obtenez un résumé, c'est terminé. Aucun renversement n’est possible ou prévu. L'outil refuse à juste titre de fournir une fonction de « décryptage », car celle-ci ne peut pas exister. Si vous avez besoin d'un cryptage, utilisez un chiffrement approprié. L'absence d'inversion ne constitue pas une limitation de l'outil ; c'est un fait mathématique sur le hachage. Les fonctions à sens unique sont des outils puissants précisément parce qu’elles ne peuvent pas être inversées. Ils valident les données d'une manière qui ne peut pas être récupérée. Ils fournissent une vérification sans révéler l'original. Ils permettent des systèmes de mots de passe sécurisés même en cas de vol de la base de données. Les hachages de mots de passe salés et correctement réglés deviennent impossibles à inverser par devinette. L'irréversibilité est le mécanisme de sécurité.

Le calculateur de hachage ToolAcre SHA calcule des résumés unidirectionnels, utiles et correctement calculés par la propre implémentation Web Crypto du navigateur. Si vous avez besoin de hacher à des fins de vérification ou d'intégrité, utilisez-le. Si vous devez garder des données secrètes et les récupérer plus tard, le cryptage est votre outil. Comprendre la différence entre le hachage irréversible et le cryptage réversible est fondamental pour la sécurité et pour créer des systèmes qui font ce dont vous avez réellement besoin.