La pire nuit de support de mon WP Adminify a commencé avec un écran blanc. Nous avons poussé la version 3.1.2 vers le serveur de mise à jour vers 23 heures et à 2 h 40. J'avais 14 billets pour dire la même chose : mise à jour installée, site mort. J'ai reculé, j'ai retesté le zip sur ma machine - fonctionnait parfaitement. même version. même fichier. Soi-disant.
Il m'a fallu un temps embarrassant pour faire la chose évidente : hacher les deux fichiers. Le SHA-256 du ZIP de mon ordinateur portable et le SHA-256 du ZIP assis sur le serveur de mise à jour ne correspondaient pas. Pas même proches - des résumés complètement différents. Le téléchargement avait été tronqué quelque part au milieu du transfert, le serveur a servi avec plaisir une archive cassée et PHP a étouffé les fichiers incomplets à l'intérieur. Une comparaison de somme de contrôle aurait été prise avant qu'un seul utilisateur ne soit mis à jour. Après cette nuit, chaque version de WP Adminify a obtenu son SHA-256 imprimé dans le journal de déploiement, et le script de téléchargement a refusé de publier à moins que le hachage distant ne corresponde à celui de local. Zéro rejets corrompus depuis.
C'est ce que le hachage est, à son niveau le plus pratique : une empreinte digitale pour les données. Alimenter un fichier ou une chaîne, récupérez un résumé de longueur fixe courte. Si un octet ne change même pas - un bit inversé, un téléchargement tronqué, un montage sournois - le résumé change complètement. J'accède maintenant à un générateur de hachage en ligne plusieurs fois par semaine : vérification des téléchargements, débogage des signatures de webhook, comparaison des fichiers de configuration dans les environnements, vérification de la santé mentale que deux fichiers "identiques" sont réellement.
C'est pourquoi j'ai construit un dans toolz.dev. Je voulais un outil de hachage qui calcule tout dans le navigateur, me montre MD5, SHA-1, SHA-256 et SHA-512 côte à côte, et ne télécharge jamais un octet de mon entrée n'importe où. Ce guide explique comment l'utiliser, ce qui se passe réellement sous le capot et la seule erreur de hachage que je me suis fait au début - et que je vois encore dans les bases de code aujourd'hui.
tl;dr : Utilisez le Générateur de hachage Toolz.dev Pour calculer les résumés de MD5, SHA-1, SHA-256 et SHA-512 à partir de texte ou de fichiers, instantanément et entièrement dans votre navigateur via l'API Web de crypto. Par défaut, SHA-256 pour tout ce qui compte ; traitez MD5 et SHA-1 uniquement comme des sommes de contrôle héritées. Et jamais, jamais, utilisez l'un de ces mots de passe. C'est un territoire bcrypt ou argon2.
Principales caractéristiques
Plusieurs algorithmes à la fois
Collez votre entrée une fois et obtenez le calcul simultané de MD5, SHA-1, SHA-256 et SHA-512. Cela semble être une petite commodité jusqu'à ce que vous déboguiez le système de quelqu'un d'autre et que vous ne sachiez pas quel algorithme il utilisait. J'ai perdu du temps réel à cela - un documentaire de Payment Gateway a déclaré "Sha Hash" sans numéro attaché, et je suis assis là à générer un algorithme à la fois dans un terminal jusqu'à ce qu'un seul appariement. Avec les quatre résumés à l'écran à la fois, vous accrochez simplement celui qui correspond à la valeur que vous essayez d'égaler. Cela rend également les différences viscérales : vous pouvez voir le MD5 à 32 caractères à côté du SHA-512 de 128 caractères et comprendre immédiatement ce que signifie "digérer la taille" en pratique.
Hachage de texte et de fichiers
Tapez ou collez une chaîne ou déposez un fichier — l'outil gère les deux. Le hachage de texte couvre les cas quotidiens : débogage de signatures d'API, clés de cache, comparaisons rapides. Le hachage de fichiers est l'endroit où le travail de vérification réel se produit. La vérification d'un programme d'installation téléchargé par rapport à une somme de contrôle publiée, la confirmation d'un plugin ZIP a survécu au voyage vers votre serveur de mise à jour, vérifiant un vidage de base de données copié intact entre les machines. Le fichier n'est jamais téléchargé nulle part, il est lu localement par votre navigateur et haché en place. J'ai ainsi haché des vidages SQL de plusieurs cents mégaoctets de cette façon. C'est plus rapide que ce à quoi vous vous attendez, car le gros du travail se produit dans le code du navigateur natif, et non dans les boucles JavaScript.
Calcul côté client instantané via Web crypto
Les résumés de la famille SHA sont calculés avec l'API de crypto Web intégrée du navigateur. crypto.subtle.digest — qui exécute un code cryptographique natif et optimisé fourni avec votre navigateur. Pas de serveur aller-retour, pas de file d'attente, pas de spinner. Vous obtenez des résultats aussi rapidement que votre machine peut lire l'entrée. Cela compte pour deux raisons. Premièrement, la vitesse : le hachage se produit en quelques millisecondes, même pour les grandes entrées. Deuxièmement, la confiance : parce que le calcul est local, l'outil fonctionne de la même manière, que vous soyez en ligne dans un café ou que vous hachis une configuration sensible sur un réseau verrouillé. La page se charge une fois ; après cela, le réseau n'est pas pertinent.
Sortie majuscule et minuscule
Fonction triviale, économise de vrais maux de tête. Les digestions hexadécimales sont insensibles à la casse - 2CF24DBA et 2cf24dba Encodez des octets identiques - mais les comparaisons de chaînes ne le savent pas. De nombreux systèmes stockent ou publient des résumés en majuscules (certains outils Windows, certaines pages de contrôle des fournisseurs), tandis que la plupart des outils Unix émettent des minuscules. Si vous collez un résumé dans un script de comparaison ou un fichier de configuration qui correspond exactement à la mise en correspondance des chaînes, Case compte beaucoup. La bascule signifie que vous copiez le format dont vous avez besoin au lieu d'exécuter la sortie via un convertisseur de cas ou, pire, "fixation" de la main et d'un caractère.
Comparer et vérifier le mode
Le hachage ne représente que la moitié du travail, généralement vous vérifiez un résumé par rapport à une valeur attendue. Collez la somme de contrôle publiée à côté de votre calcul et l'outil vous indique instantanément s'ils correspondent, sans plisser les yeux à 64 caractères hexadécimaux requis. J'avais l'habitude de vérifier les sommes de contrôle en comparant visuellement les premiers et derniers caractères. C'est exactement comme ça qu'on rate une incompatibilité au milieu. Les yeux humains sont terribles pour comparer de longues cordes aléatoires, c'est un travail pour un contrôle d'égalité. Le mode de vérification normalise également le boîtier et l'espacement des blancs avant de comparer, ce qui tue les fausses alertes les plus courantes : un espace de fuite errant à partir d'un copier-coller bâclé.
100% privé — rien ne quitte votre navigateur
C'est la fonctionnalité sur laquelle je refuse de faire des compromis sur l'ensemble de Toolz.dev. Votre entrée — texte ou fichier — est hachée localement et n'est jamais transmise. Il n'y a pas de traitement côté serveur, pas de journalisation, pas de "nous anonymes vos données" en petits caractères, car il n'y a pas de données à enregistrer. Cela compte plus pour le hachage que les gens ne le pensent : les choses que les développeurs hachage sont souvent exactement les choses qu'ils ne devraient pas coller dans un site Web aléatoire : secrets d'API lors du débogage des signatures HMAC, des clés de licence, des vidages avec les e-mails des clients. Avec un outil côté client, ce risque s'évapore. Ouvrez l'onglet Réseau de votre navigateur tout en hachant si vous voulez une preuve. J'ai écrit plus sur les raisons pour lesquelles cette architecture est importante dans mon Protection des données et outils en ligne Post.
Comment utiliser le générateur de hachage
Étape 1 : ouvrez l'outil et choisissez votre entrée
dirigez-vous vers le générateur de hasch. Vous verrez une zone de saisie qui accepte soit un texte dactylographié/collé, soit un fichier. Pour le texte, commencez simplement à taper - le hachage se produit au fur et à mesure. Pour les fichiers, faites-en glisser un vers la zone de dépôt ou utilisez le sélecteur de fichiers. Rien ne télécharge; le fichier est lu localement par votre navigateur. Il n'y a pas de plafond de taille au-delà de ce avec quoi la mémoire de votre machine est à l'aise.
Étape 2 : Lisez les résumés
Tous les algorithmes calculent à la fois : MD5, SHA-1, SHA-256, SHA-512. Chaque résumé apparaît dans sa propre ligne étiquetée, en hex. Notez les longueurs — 32 caractères pour MD5, 40 pour SHA-1, 64 pour SHA-256, 128 pour SHA-512. Si vous correspondez à une somme de contrôle connue et que vous n'êtes pas sûr de l'algorithme qui l'a produit, la longueur seule vous indique généralement avant de comparer un seul caractère.
Étape 3 : Basculez le cas si nécessaire
Si le système auquel vous correspondez à l'utilisation de l'hexagone en majuscule, retournez la bascule de la coque. Les octets de résumé sont identiques dans les deux cas, ce qui concerne uniquement le formatage des chaînes. Copiez le résumé avec le bouton Copier plutôt que de sélectionner à la main ; un résumé SHA-512 de 128 caractères est très facile à sélectionner partiellement et un condensé tronqué échouera silencieusement à chaque comparaison que vous faites avec.
Étape 4 : Vérifiez par rapport à un hachage attendu
Vous avez une somme de contrôle publiée à partir d'une page de téléchargement d'un fournisseur ou d'un journal de déploiement d'un collègue ? Collez-le dans le champ de comparaison. L'outil le vérifie par rapport à votre résumé calculé et vous donne une correspondance claire ou une incompatibilité. Match signifie que les données sont octes pour octet identiques à ce qui a produit le hachage d'origine. La non-concordance signifie quelque chose de modifié - transfert corrompu, version de fichiers erronée ou altération. Ne rationalisez pas une inadéquation. au sujet de -Télécharger et vérifier à nouveau.
MD5 vs SHA-256 : ce qui se passe réellement sous le capot
Une fonction de hachage cryptographique prend une entrée de toute longueur et produit une sortie de longueur fixe appelée un résumé. Quatre propriétés le rendent utile. déterministe — Le même apport donne toujours le même condensé. Il expose le effet d'avalanche — Changez un bit d'entrée et environ la moitié des bits de sortie basculent. à sens unique — Il n'y a pas de chemin de relance possible entre le résumé et l'entrée. Et c'est résistant aux collisions — Trouver deux entrées différentes qui produisent le même condensé devrait être impossible à réaliser.
L'effet d'avalanche vaut la peine d'être vu avec des valeurs réelles. Le MD5 de hello est 5d41402abc4b2a76b9719d911017c592. Mettre en majuscule une lettre — Hello — et vous obtenez 8b1a9953c4611296a827abf8c47804d7. Pas un personnage n'a changé, un résumé complètement sans rapport. Même histoire avec SHA-256 : hello Haches à 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824, tandis que Hello produit un résumé qui ne partage pratiquement rien avec lui. C'est le point. Un résumé vous dit que Les données modifiées, jamais combien.
Maintenant, les algorithmes. MD5 a été défini dans le RFC 1321 en 1992 et produit un résumé de 128 bits. C'est rapide, c'est partout - et c'est cryptographiquement cassé. Des attaques de collision pratiques existent depuis 2004 ; les chercheurs peuvent fabriquer deux entrées différentes avec le même MD5 Digest sur du matériel de base. Cela le tue pour tout ce qui est contradictoire : signatures, certificats, contrôles d'intégrité lorsqu'un attaquant peut remplacer le contenu. Cela reste très bien pour les sommes de contrôle non contradictoires - détectant une corruption accidentelle dans un transfert de fichiers, dédupliquant vos propres données - car la corruption aléatoire ne peut pas choisir ses octets. SHA-1 (160 bits) a duré plus longtemps, mais l'attaque brisée a démontré une collision pratique en 2017, avec deux fichiers PDF différents partageant un SHA-1 Digest. Git utilise toujours SHA-1 en interne pour des raisons historiques, mais aucun nouveau système ne devrait le faire.
le Famille SHA-2 — SHA-256 et SHA-512 parmi eux — est spécifié dans FIPS 180-4 et reste intact. SHA-256 vous donne un résumé de 256 bits et est le défaut sain pour presque tout. SHA-512 offre un plus grand résumé et est souvent plus vite sur les CPU 64 bits, car cela fonctionne en mots 64 bits.
Trois distinctions Les gens brouillent constamment. hachage est à sens unique - pas de clé, pas de retour. cryptage est bidirectionnel - n'importe qui avec la clé peut déchiffrer. codage, comme Base64, est une protection à zéro - c'est juste un changement de représentation que tout le monde peut inverser, aucune clé n'est nécessaire. Si vous avez déjà vu Base64 traité comme "cryptage", mon Convertisseur de base64 montrera gaiement pourquoi c'est un problème, et mon Guide d'encodage Base64 Couvre la distinction en profondeur.
Lorsque vous devez prouver qu'un message provenait d'une personne détenant un secret partagé - signatures de webhook, signature de demande d'API - un hachage simple n'est pas suffisant, car tout le monde peut hacher. C'est HMAC, défini dans RFC 2104 : une construction à clé qui enveloppe une fonction de hachage afin que seuls les détenteurs de clés puissent produire des résumés valides. HMAC-SHA256 est le cheval de bataille derrière la plupart des schémas de signature Webhook que vous aurez jamais déboguer.
Et le plus gros : Ne hachez jamais de mots de passe avec des hachages rapides. Rapide est l'ennemi ici - un attaquant avec une base de données divulguée peut tester des milliards de MD5 ou SHA-256 par seconde sur les GPU. Les mots de passe nécessitent des algorithmes délibérément lents et salés : bcrypt ou argon2. Laravel Hash::make() Utilise Bcrypt par défaut pour cette raison, et WordPress a passé des années sur le schéma de hachage portable PHPass avant de se moderniser - imparfait, mais l'instinct (le ralentir, le saler) était correct. J'ai appris cela à la dure : un de mes premiers projets indépendants, des années avant l'administration de WP, a stocké les mots de passe en tant que RAW md5($password). Déplacement de recrue classique. Personne n'a été violé, mais je grince toujours.
Voici ce que fait l'outil Toolz.dev sous le capot, et ce que vous écririez vous-même :
const data = new TextEncoder().encode('hello');
const buf = await crypto.subtle.digest('SHA-256', data);
const hex = [...new Uint8Array(buf)]
.map(b => b.toString(16).padStart(2, '0'))
.join('');
// "2cf24dba5fb0a30e26e83b2ac5b9e29e..."
Ou en PHP, une ligne : hash('sha256', 'hello'). Même entrée, même résumé, n'importe quelle langue, n'importe quelle machine. Ce déterminisme est le fondement.
Cas d'utilisation courants
Vérification des téléchargements de fichiers et des artefacts de publication
Le cas d'utilisation qui m'a brûlé dans l'introduction. Les fournisseurs publient des sommes de contrôle à côté de Téléchargements pour une raison : les transferts sont corrompus, les miroirs sont obsolètes et, parfois, quelqu'un de malveillance échange un fichier. Téléchargez le fichier, hachez-le avec le générateur de hasch, comparez la valeur publiée. Match : le fichier est byte-identique à ce que l'éditeur a hash. Non-concordance : Arrêtez et téléchargez à nouveau. Pour mes propres versions, la règle depuis cet incident de 2 h 40 est mécanique - le script de déploiement calcule SHA-256 localement, télécharge, récupère le hachage du fichier distant et refuse de retourner le pointeur "actuel de la version actuelle" à moins qu'ils ne soient égaux. C'est peut-être huit lignes de bash. Il a depuis 201 été enregistré deux téléchargements tronqués, ce qui aurait été des inondations de billets. Une assurance la moins chère dans mon pipeline.
Cache-cache et Etags
Les navigateurs s'insèrent de manière agressive, et "s'il vous plaît actualiser" n'est pas une stratégie de déploiement. Le correctif robuste est le nom de fichier haché de contenu : hachez le contenu du fichier et incorporez un morceau du résumé dans le nom, donc app.css se transforme app.2cf24dba.css. Changement de contenu, modifications de hachage, modifications de nom de fichier, erreurs de cache, utilisateurs obtiennent le nouveau fichier. Contenu identiques, nom de fichier identique, hit du cache. Laravel Mix and Vite le fait automatiquement; dans WP Adminify, j'ai fait une version locale, hachant le contenu des actifs pour créer le ver La chaîne de requête WordPress ajoute aux scripts mis en file d'attente - après un trop grand nombre de "tickets de paramètres, les tickets " qui étaient vraiment obsolètes". Le même principe alimente Etags : le serveur hache la réponse, le navigateur renvoie le hachage et une correspondance signifie un minuscule 304 au lieu d'une charge utile complète.
Dépollation du contenu
Vous voulez savoir si deux fichiers sont identiques sans les comparer octet par octet - ou quand ils vivent sur des machines différentes ? hacher les deux. Les indices égaux signifient un contenu égal (avec SHA-256, les cotes de collision sont si absurdes qu'elles ne valent pas la peine d'être réfléchies). Cela évolue à merveille : hachez un millier de téléchargements, triez les résumés et les doublons instantanément. Je l'ai utilisé pour déduplier une bibliothèque de médias WordPress qui avait accumulé des années de logo.png, logo-1.png, et logo-final-2.png — Hashing révélé qui était en fait la même image portant des noms différents. C'est aussi la façon dont les outils de sauvegarde décident de ce qu'il faut sauter et comment les magasins d'objets détectent qu'un "téléchargement" est le contenu qu'ils détiennent déjà.
Adressage de contenu de style Git
Git ne stocke pas les fichiers par leur nom - il les stocke par hachage. Chaque blob, arbre et commit est abordé par le résumé de son contenu (historiquement SHA-1, avec une transition SHA-256 en cours). C'est pourquoi les identifiants de validation ressemblent à des hachages : ils are hachage, et ils couvrent l'instantané, les parents, l'auteur, l'horodatage. Changez n'importe où dans l'histoire et chaque changement de hachage en aval, ce qui rend la falsification de l'histoire de Git à haute voix plutôt que discrètement possible. Comprendre cela a transformé la façon dont j'ai déboguer les problèmes de git. Lorsque deux machines sont en désaccord sur un commit, la comparaison de hachages vous indique instantanément si vous regardez le même objet ou que vous êtes divergent. L'adressage de contenu est l'une de ces idées qui semble académique jusqu'à ce qu'elle sauve votre référentiel.
Comparer les configurations sans exposer les secrets
La mise en scène fonctionne, la production n'est pas, et vous soupçonnez que le .env Les fichiers diffèrent, mais vous ne voulez pas que les secrets de production soient hébergés dans un fil de discussion ou un partage d'écran. Hachez chaque fichier sur sa propre machine et comparez les résumés à la place. Différents hachages confirment que les fichiers diffèrent sans révéler une seule valeur. Vous pouvez aller plus loin : hachage individuels ou clés spécifiques pour localiser qui L'entrée diverge. J'ai réglé les désaccords avec le support de l'hébergement de cette façon - "Votre copie de la configuration ne correspond pas à la mienne, voici mon SHA-256, vérifiez le vôtre" termine le débat dans un seul message. Le Digest prouve la différence ou la similitude tandis que les secrets restent exactement à leur place.
Débogage de signature de webhook
Stripe, GitHub, Paddle - Ils signent tous des charges utiles Webhook, généralement avec HMAC-SHA256, afin que vous puissiez vérifier que la demande provient réellement d'eux. Et lorsque votre vérification échoue, le débogage est misérable, car l'échec est silencieux : les signatures ne correspondent tout simplement pas, et le middleware dit non neuf fois sur dix, la charge utile est la charge utile - votre cadre a re-sérialisé le JSON, en modifiant les espaces blancs ou les commandes de clés, afin que vous hachissiez des octets différents de ceux signés. Hachage du âpre Le corps de la demande à différents points de votre pipeline vous indique exactement où les octets mutent. Si le résumé change entre votre gestionnaire de route et votre fonction de vérification, vous avez trouvé la couche qui touche le corps. Pendant que vous êtes dans ce quartier, mon Décodeur JWT est pratique pour le travail adjacent d'inspection des jetons signés.
MD5 vs SHA-1 vs SHA-256 vs SHA-512 : lequel devez-vous utiliser ?
| algorithme | Taille du résumé | Vitesse relative | État de sécurité | Utilisations appropriées |
|---|---|---|---|---|
| MD5 | 128 bits (32 caractères hexagonaux) | le plus rapide | Brisé — Collisions pratiques depuis 2004 | Checksums non contradictoires, compatibilité avec le système hérité, clés de cache |
| SHA-1 | 160 bits (40 caractères hexagonaux) | harde | Cassé - Collision brisée, 2017 | Les anciens git internes, interopératoires avec les anciens systèmes; rien de nouveau |
| SHA-256 | 256 bits (64 caractères hexagonaux) | harde | engager | Par défaut pour les vérifications d'intégrité, les signatures, l'adressage de contenu, HMAC |
| SHA-512 | 512 bits (128 caractères hexagonaux) | Rapide (souvent plus rapide sur les CPU 64 bits) | engager | Identique à SHA-256 ; lorsque vous souhaitez une marge supplémentaire ou un débit de 64 bits |
Ma position, et je vais être franc à ce sujet : par défaut sur SHA-256 et arrêtez d'y penser. Il est sécurisé, pris en charge universellement, suffisamment rapide pour que vous ne remarquiez jamais le coût, et c'est ce que vos outils parlent déjà - certificats TLS, résumés d'images Docker, fichiers de verrouillage de paquet, signatures Webhook. L'énergie mentale consacrée à choisir un algorithme est presque toujours mieux dépensée ailleurs.
La nuance qui vaut la peine d'être conservée : MD5 n'est pas radioactif, c'est étendu. Détecter une corruption accidentelle sur vos propres fichiers ? bien. Quelque chose où un adversaire humain pourrait bénéficier de la constitution d'une collision ? Absolument pas. SHA-1 se trouve dans le même seau avec moins d'excuses - la seule bonne raison de le toucher est la compatibilité avec un système que vous ne contrôlez pas. SHA-512 est un choix idéal et parfois plus rapide sur le matériel moderne 64 bits, mais les résumés de 128 caractères sont difficiles à utiliser dans les journaux et les URL, et la marge de sécurité de SHA-256 dépasse déjà toute attaque réaliste. Et aucun des quatre - répétez, aucun - n'appartient à un champ de mot de passe.
Questions fréquentes
MD5 est-il toujours sûr à utiliser ?
Pour des raisons de sécurité, des attaques de collision pratiques existent depuis 2004, ce qui signifie que les attaquants peuvent créer deux fichiers différents avec le même résumé MD5. Ne l'utilisez jamais pour des signatures, des certificats, un stockage de mots de passe ou un contrôle d'intégrité lorsque la falsification est un problème. Cela reste acceptable pour les emplois non contradictoires - détectant la corruption accidentelle, déduplication de vos propres fichiers, génération de clés de cache - où personne n'essaie de vous tromper. En cas de doute, utilisez SHA-256, cela ne vous coûte rien.
Pouvez-vous inverser un hachage pour obtenir les données d'origine ?
non Les fonctions de hachage sont à sens unique par conception - le résumé contient beaucoup moins d'informations que la plupart des entrées, il est donc mathématiquement impossible d'en faire l'inversion. Ce que font réellement les attaquants, c'est de deviner : hacher des milliards d'entrées candidates et comparer les résumés, en utilisant des tableaux arc-en-ciel ou une force brute GPU. Cela fonctionne terriblement bien contre les entrées courtes et courantes telles que les mots de passe hachés avec des algorithmes rapides, c'est pourquoi les mots de passe ont besoin d'un hachage lent et salé plutôt que de MD5 ou SHA-256.
Quelle est la différence entre le hachage et le cryptage ?
Le cryptage est bidirectionnel : les données sont brouillées avec une clé, et toute personne détenant la bonne clé peut la déchiffrer à l'original. Le hachage est à sens unique : vous pouvez calculer un résumé à partir des données, mais vous ne pouvez pas récupérer les données du résumé, il n'y a pas de clé ni de déchiffrement. Utilisez le cryptage lorsque vous avez besoin de sauvegarder les données, de le hachage lorsque vous n'avez besoin que de vérifier ou de comparer. Base64, pour mémoire, n'est ni l'un ni l'autre - il est encodant, réversible par quiconque.
Quel hachage dois-je utiliser pour les mots de passe ?
Aucun de ceux de cet outil. MD5, SHA-1, SHA-256 et SHA-512 sont tous rapides, et rapide est fatal pour les mots de passe - les GPU peuvent tester des milliards de suppositions par seconde par rapport à une base de données divulguée. Utilisez un algorithme délibérément lent et salé : bcrypt ou argon2. Hash::Make() utilise bcrypt par défaut, et la plupart des frameworks modernes fournissent un équivalent. Si vous écrivez des appels de hachage bruts pour le stockage des mots de passe, arrêtez et accédez à l'API de hachage de mot de passe de votre framework.
Est-il sûr de hacher des données sensibles dans un outil en ligne ?
Uniquement si l'outil est véritablement côté client. Le générateur de hachage Toolz.dev calcule chaque résumé de votre navigateur à l'aide de l'API Web Crypto - votre entrée n'est jamais transmise, enregistrée ou stockée sur n'importe quel serveur. Vous pouvez le confirmer vous-même en regardant l'onglet Réseau pendant que vous hachage. Avec les outils côté serveur, vous faites confiance à un opérateur inconnu avec tout ce que vous collez, ce qui est un mauvais échange pour les secrets, les clés ou les données client d'API. En cas de doute, vérifiez avant de coller.
Pourquoi "bonjour" et "bonjour" produit des hachages complètement différents ?
C'est l'effet d'avalanche, et il est délibéré. Une bonne fonction de hachage inverse environ la moitié de ses bits de sortie lorsqu'un seul bit d'entrée change, de sorte que des entrées similaires produisent des condensés extrêmement différents. La majuscule d'une lettre modifie un seul octet, mais le résumé devient méconnaissable. Il s'agit d'une fonctionnalité : cela signifie que les résumés ne révèlent rien sur la similarité de deux entrées et rendent tout changement, même minuscule, impossible à manquer lorsque vous comparez les hachages.
Quelle est la différence entre SHA-256 et SHA-512 ?
Les deux appartiennent à la famille SHA-2 spécifiée dans les FIPS 180-4, et les deux sont considérées comme sécurisées. SHA-256 produit un résumé de 256 bits en utilisant des opérations 32 bits, SHA-512 produit un résumé de 512 bits en utilisant des opérations 64 bits, ce qui le rend souvent plus rapide sur les processeurs modernes 64 bits. En pratique, le SHA-256 est le défaut de l'écosystème et ses résumés sont la moitié de la longueur, ce qui maintient les journaux et les URL gérables. Choisissez SHA-512 pour une marge de sécurité supplémentaire ou un débit de 64 bits, sinon SHA-256 est suffisant.
Quand ai-je besoin de HMAC au lieu d'un hachage simple ?
Utilisez HMAC chaque fois que vous avez besoin de prouver qui a produit le hachage, pas seulement ce qui a été haché. Un résumé simple peut être calculé par n'importe qui, il vérifie donc l'intégrité mais pas l'origine. HMAC, défini dans RFC 2104, mélange une clé secrète dans le processus de hachage - seules les parties détenant la clé peuvent produire ou vérifier des signatures valides. Il s'agit du mécanisme derrière les signatures Webhook de Stripe, GitHub et des services similaires, presque toujours comme HMAC-SHA256 sur le corps de la requête RAW.
Expédier avec des empreintes digitales, pas la foi
Le hachage est l'outil rare qui est à la fois une science informatique approfondie et une pratique quotidienne simple et morte. Vous n'avez pas besoin de comprendre les constructions Merkle–Damgård pour en bénéficier, vous avez besoin de l'habitude. Hachez vos artefacts de libération. Vérifiez vos téléchargements. Comparez les résumés au lieu de regarder des fichiers. Chacune de ces habitudes est de trente secondes de travail, et chacune m'a, à un moment donné, épargné une nuit que j'aurais autrement passé à m'excuser dans une file d'attente.
le Générateur de hachage Toolz.dev est conçu pour rendre cette habitude sans friction : quatre algorithmes à la fois, texte et fichiers, mode de vérification, tous calculés dans votre navigateur sans rien téléchargé. Si vous travaillez sur les concepts voisins, le Convertisseur de base64 couvre l'encodage (et pourquoi il n'est pas de sécurité), le générateur de mots de passe Gère les secrets que vous ne devriez jamais hacher avec SHA-256, et le Décodeur JWT Complète le côté symbolique de l'histoire.
Pour la vue d'ensemble, mon Guide des outils de codage Parcoure le reste de la boîte à outils du développeur, et Confidentialité des données dans les outils en ligne Explique pourquoi le traitement côté client est la colline que j'ai choisi de mourir. Hash d'abord, déployez ensuite. Votre moi de 2 h 40 vous remerciera.
