Identifier le format d'une chaîne de hachage : une procédure pratique

Il arrive souvent de tomber sur une chaîne comme 5f4dcc3b5aa765d61d8327deb882cf99 ou $2b$12$... laissée dans des logs ou une base de données, et de vouloir déterminer « de quel type de hachage s’agit-il ? ». Lors de la migration de systèmes existants, de l’investigation des méthodes d’authentification, de l’analyse de logs ou de l’intégration avec des systèmes tiers, il n’est pas rare de rester bloqué précisément à ce stade.

Mais ce qui est dangereux ici, c’est de tirer une conclusion hâtive en se basant uniquement sur la longueur. Regarder une chaîne hexadécimale de 64 caractères et affirmer « c’est du SHA-256 » est prématuré. SHA3-256, SHA-512/256, BLAKE2s-256 et la sortie par défaut de 32 octets de BLAKE3 peuvent tous produire la même longueur. À l’inverse, les formats de stockage qui incluent un préfixe et des paramètres, comme $2b$ ou $argon2id$, peuvent être identifiés avec une assez grande précision à partir de la seule chaîne.

Dans cet article, nous utilisons le terme hash au sens large, en englobant non seulement les digests de type MD5 / SHA-2 / SHA-3, mais aussi les représentations en chaîne utilisées pour le stockage des mots de passe, comme bcrypt / scrypt / Argon2 / PBKDF2. Le contenu est organisé à partir des RFC, des publications du NIST, de crypt(5) sous Linux, ainsi que de la documentation officielle d’Apache, Django, Spring Security et d’autres sources, disponibles publiquement en avril 2026.

Table des matières

1. La conclusion d’abord
2. Tableaux d’identification en un coup d’œil
3. La procédure pratique d’identification
4. Erreurs d’identification courantes
5. L’ordre de vérification pour une certitude à 100 %
6. Résumé
7. Services liés à cette thématique
8. Références

1. La conclusion d’abord

Voici d’abord la version courte.

• Les formats de stockage avec préfixe ou séparateurs sont assez faciles à identifier à partir de la seule chaîne. Exemples : $argon2id$..., $2b$..., $5$..., $6$..., {SHA}..., pbkdf2_sha256$...

• Un simple hexadécimal ou du Base64 nu ne permettent généralement que de « restreindre les candidats ». Exemple : 32 hex = peut-être du MD5, mais peut aussi provenir de MD4 / NTLM

• Le jeu de caractères est aussi important que la longueur. Si l’on voit + / =, cela ressemble à du Base64 selon la RFC 4648 ; si la chaîne contient un . et qu’elle est délimitée par des $, cela ressemble à la famille crypt(3) — ce genre de distinction est vraiment efficace.

• Pour une certitude à 100 %, il faut le contexte. Que la chaîne se trouve dans /etc/shadow, .htpasswd, auth_user de Django ou dans Spring Security change la donne.

En résumé, « les formats identifiables à partir de la seule chaîne » et « les formats pour lesquels la chaîne ne donne qu’un ensemble de candidats » sont deux choses différentes. Le simple fait de bien les distinguer change la façon dont progresse une investigation.

2. Tableaux d’identification en un coup d’œil

2.1 Formats presque totalement identifiables par un préfixe ou un marqueur de format

Dans ce tableau, la « confiance » s’entend ainsi.

• Forte : quasiment identifiable à partir de la seule chaîne
• Moyenne : les candidats se restreignent nettement, mais il faut faire attention aux différences d’implémentation
• Faible : impossible à déterminer à partir de la seule longueur ou de la seule apparence

Ce que montre ce tableau, c’est que les formats dont les premiers caractères ont un sens sont « forts ». Les chaînes délimitées par $...$ en particulier appartiennent très probablement à la famille Unix crypt(3) / MCF / PHC, et il est plus rapide de regarder le préfixe avant la longueur.

2.2 Restreindre les candidats par la longueur pour l’hexadécimal / Base64 en clair

Ce tableau concerne les chaînes de digest nues, sans préfixe. Pour les représentations contenant :, - ou des espaces, il faut d’abord retirer les séparateurs, puis compter la longueur.

Ce qu’il faut retenir ici, c’est qu’une longueur identique ne détermine pas le format de façon unique. Les chaînes hexadécimales de 32, 64 ou 128 caractères en particulier ont de nombreux candidats, et trancher uniquement sur cette base conduit souvent à une erreur.

2.3 Exemples classiques qui induisent en erreur

3. La procédure pratique d’identification

À partir d’ici, voyons dans l’ordre comment examiner concrètement une chaîne. L’ordre recommandé est préfixe → séparateurs → jeu de caractères → longueur → contexte.

3.1 Regarder d’abord les premiers caractères

Les 1 à 10 premiers caractères permettent déjà de beaucoup restreindre le champ des possibles.

• $argon2id$ / $argon2i$ / $argon2d$ Fortement suspecter le format PHC string d’Argon2. Les composants sont faciles à suivre dans la colonne « Exemple » de la section 2.1.

• $2a$ / $2b$ / $2y$ Fortement suspecter bcrypt.

• $1$ / $5$ / $6$ / $7$ / $y$ Suspecter un hachage de mot de passe de la famille Unix crypt(3).

• {SHA} / {SSHA} / {MD5} / {SMD5} Suspecter une représentation de la famille LDAP / Apache.

• {bcrypt} / {pbkdf2} / {scrypt} Suspecter un format de stockage étiqueté par l’implémentation, comme celui de Spring Security.

L’astuce ici consiste à ne pas regarder uniquement l’algorithme sous-jacent, mais aussi le format de stockage. Par exemple, $6$ n’est pas « un digest SHA-512 » — c’est « une chaîne de hachage de mot de passe qui utilise SHA-512 ». Confondre les deux fausse la suite de l’investigation.

3.2 Regarder le nombre de séparateurs

Ensuite, on regarde les séparateurs tels que $, :, {}, , et =.

• Plusieurs caractères $ Suspecter un format qui porte ensemble des paramètres, un sel et un hash. Argon2, bcrypt, sha256crypt et sha512crypt en sont des exemples typiques.

• Commence par {nom} Suspecter une enveloppe qui nomme explicitement le format, comme dans LDAP / Spring Security.

• Formes telles que algo:salt:hash ou algo$iterations$salt$hash Suspecter un format propre à un framework ou une application. Le pbkdf2_sha256$iterations$salt$hash de Django en est l’exemple classique.

Plus une chaîne comporte de séparateurs, plus le format est facile à identifier. À l’inverse, un simple bloc d’hexadécimal ou de Base64 reste assez ambigu.

3.3 Regarder le jeu de caractères

Le jeu de caractères est aussi important que la longueur.

Représentation hexadécimale

Si la chaîne n’est composée que de [0-9a-fA-F], il faut d’abord suspecter une représentation hexadécimale. Dans ce cas, nombre de caractères ÷ 2 = longueur en octets bruts.

• 32 hex → 16 octets
• 40 hex → 20 octets
• 64 hex → 32 octets
• 128 hex → 64 octets

Base64 / Base64url selon la RFC 4648

Si l’on voit + / =, il faut d’abord suspecter du Base64 classique. Si l’on voit - _, suspecter du Base64url. Le padding = pouvant être omis, les longueurs se présentent par paires « l’une ou l’autre est possible », comme 43 / 44 et 86 / 88.

Le radix64 de la famille crypt

Si l’on voit apparaître . et /, et que la chaîne est délimitée par $...$, il est plus naturel de suspecter un alphabet de la famille crypt plutôt que du Base64 classique. bcrypt, sha256crypt, sha512crypt, md5crypt, yescrypt, scrypt et consorts utilisent cette famille de jeux de caractères.

C’est un point discret, mais très efficace. Si l’on se dit « il y a un ., donc c’est du Base64 cassé », on risque fort de passer à côté de bcrypt et de la famille crypt(3).

3.4 Compter la longueur

Après le jeu de caractères, on regarde la longueur. Le raisonnement est simple.

• Pour l’hexadécimal : longueur en octets bruts = nombre de caractères / 2
• Pour Base64 : nombre de caractères ≈ 4 × plafond(longueur en octets bruts / 3) Notez que l’omission du padding = raccourcit la chaîne de 0 à 2 caractères

À ce stade, on restreint les candidats. Mais il est plus prudent de ne pas faire le raccourci « 64 hex, donc SHA-256 confirmé ».

3.5 Confirmer par le contexte

Ce qui tranche finalement, c’est le contexte. C’est là qu’on se rapproche des 100 %.

• Trouvé dans /etc/shadow Suspecter des formats de hachage de mot de passe Linux tels que $y$, $6$, $5$, $1$

• Trouvé dans .htpasswd Suspecter des formats de la famille Apache tels que $apr1$, {SHA}, bcrypt

• Trouvé dans la configuration de Django ou dans auth_user.password Suspecter des formats Django tels que pbkdf2_sha256$... ou argon2$...

• Trouvé dans une table d’authentification Spring Security Suspecter des formats préfixés par {id} tels que {bcrypt}... ou {pbkdf2}...

• 32 hex trouvé autour d’une intégration SMB / AD Envisager sérieusement la famille NTLM / MD4

En pratique, regarder le produit, le framework ou le fichier de configuration d’où provient la chaîne est souvent plus rapide que de fixer la chaîne elle-même.

4. Erreurs d’identification courantes

4.1 Poser en dur « 64 hex = SHA-256 »

C’est une erreur très courante. SHA-256 est bien sûr un candidat solide, mais plusieurs formats produisent la même sortie de 32 octets. SHA3-256, SHA-512/256, BLAKE2s-256 et la sortie par défaut de BLAKE3 ont tous la même longueur.

La longueur est une matière première pour constituer un ensemble de candidats, pas pour rendre un verdict.

4.2 Confondre $6$ avec du SHA-512 en clair

$6$... est le préfixe de sha512crypt. Ce n’est pas « un digest SHA-512 en hexadécimal » — c’est une chaîne de hachage de mot de passe qui inclut un sel et un nombre d’itérations.

De même :

• $5$ est du sha256crypt
• $1$ est du md5crypt

Dès qu’un préfixe est présent, ce n’est plus « un simple digest ».

4.3 Lire {SHA} comme « SHA-256 ou SHA-512, l’un ou l’autre »

Dans les contextes Apache ou LDAP, {SHA} ne signifie pas vaguement « la famille SHA ». Dans la plupart des cas, il désigne un digest SHA-1 encodé en Base64. {SSHA} est un SHA-1 salé.

Si l’on traite {SHA} de façon approximative comme « une sorte de SHA » d’après son apparence, on se trompe dans le code de vérification et la logique de migration.

4.4 Traiter les hachages de mots de passe et les hachages de contenu comme une seule et même chose

Ce sont toutes deux des « chaînes de hachage », mais leurs finalités diffèrent.

• Digests pour la vérification d’intégrité de fichiers
• Digests pour la signature d’API
• Chaînes de hachage / KDF pour le stockage de mots de passe

Ces trois usages se ressemblent en apparence, mais se traitent différemment. Les hachages de mots de passe en particulier intègrent souvent dans la chaîne le sel, le nombre d’itérations, le coût mémoire, le degré de parallélisme, etc., si bien que l’approche « comparer les digests bruts » ne permet pas de les percer à jour.

4.5 Oublier les XOF et les digests de longueur variable

SHAKE128 / SHAKE256 sont des XOF, si bien que la longueur de sortie peut être choisie librement. BLAKE2 permet également de configurer la longueur du digest, et BLAKE3 dispose lui aussi d’une sortie extensible.

Autrement dit, le raisonnement « cette longueur, donc ce format » échoue dès qu’il s’appuie trop fortement sur l’hypothèse d’un digest classique à longueur fixe.

5. L’ordre de vérification pour une certitude à 100 %

Les migrations et les intégrations d’authentification finissent toujours par exiger une certitude. Dans ce cas, vérifier dans l’ordre suivant permet d’éviter les mauvaises surprises.

5.1 Identifier la source de stockage

D’abord, il faut établir d’où provient la chaîne.

• Un shadow Linux ?
• L’authentification de base d’Apache / Nginx ?
• LDAP ?
• Django / Spring Security ?
• La base de données d’une application maison ?

La spécification de la source de stockage constitue souvent une preuve plus solide que la chaîne elle-même.

5.2 Rechercher le « format de stockage » dans la documentation officielle

Ensuite, on recherche le format de stockage, et non le nom de l’algorithme.

• Django password format
• Spring Security password storage format
• crypt(5) sha512crypt format
• Apache htpasswd password formats

Utiliser format / storage / encoding comme mots-clés de recherche permet de les trouver facilement.

5.3 Si un texte en clair connu est disponible, le vérifier réellement avec les formats candidats

Si l’on dispose d’un compte de test ou d’un texte en clair connu, le plus rapide est de calculer avec les formats candidats et de comparer. Pour les hachages de mots de passe, cela signifie qu’il faut extraire le sel et le nombre d’itérations de la chaîne, puis recalculer.

5.4 Vérifier le code d’implémentation ou la configuration

Si le système étudié est le vôtre, examiner le code et la configuration reste, en définitive, la méthode la plus fiable.

• La bibliothèque utilisée
• La configuration du framework
• Les options utilisées au moment de la génération
• L’encodage de sortie (hex / Base64 / Base64url / alphabet crypt)

Regarder ici permet généralement de trancher la question.

5.5 Pour l’avenir, stocker avec une étiquette de format

Si c’est vous qui concevez le système à l’avenir, choisir un format qui intègre le format de hachage dans la chaîne elle-même facilite grandement les migrations futures.

• Le format PHC string d’Argon2
• Le {id}encodedPassword de Spring Security
• Le algo$iterations$salt$hash de Django
• Les formats préfixés de la famille Unix crypt(3)

Fait ainsi, quiconque examinera la chose plus tard aura rarement de doute. À l’inverse, une conception qui se contente de placer « 64 hex tout nu » en base de données ne rend pas service à votre futur vous-même.

6. Résumé

Pour identifier le format derrière la représentation en chaîne d’un hachage, il est utile de regarder dans cet ordre.

1. Y a-t-il un préfixe ?
2. Quels sont les séparateurs ?
3. Quel est le jeu de caractères ?
4. À combien d’octets correspond la longueur ?
5. Quel est le contexte de la source de stockage ?

Les deux points les plus importants sont les suivants :

• Les formats de stockage avec préfixe sont assez faciles à identifier avec précision
• L’hexadécimal ou le Base64 en clair ne permettent souvent que d’obtenir un ensemble de candidats

Le jugement pratique s’établit donc ainsi.

• Avec $argon2id$..., $2b$..., $6$..., {SHA}..., pbkdf2_sha256$..., la seule chaîne permet déjà d’avancer bien loin
• Avec seulement 32, 40, 64 ou 128 chiffres hexadécimaux, il faut penser « restreindre les candidats », pas « rendre un verdict »
• Si une véritable certitude est nécessaire, il faut aller regarder le produit source, la configuration et l’implémentation

Suivre cet ordre accélère considérablement une investigation. À l’inverse, les jugements hâtifs fondés sur la seule longueur vous font discrètement prendre le chemin le plus long.

7. Services liés à cette thématique

Conseil technique et revue de conception

Identifier le format des hachages de mots de passe laissés dans une base de données existante, migrer une plateforme d’authentification, ou investiguer des logs dans des systèmes mixtes Windows / Web, nécessite d’organiser non seulement l’apparence des chaînes, mais aussi l’implémentation de la source de stockage et la politique de migration. Considérer l’ensemble d’un seul tenant, de l’identification du format jusqu’à la conception de la migration, permet de réduire les risques d’erreur.

Investigation de dysfonctionnements et analyse des causes

Il n’est pas rare qu’une investigation reste bloquée sur « on n’arrive pas à avancer dans la vérification parce qu’on ne sait pas ce qu’est cette chaîne ». Déterminer précisément où le format est décidé — logs, fichiers de configuration, schéma de base de données ou implémentation applicative — accélère considérablement l’identification de la cause racine.

8. Références

1. RFC 1321 - The MD5 Message-Digest Algorithm
2. NIST FIPS 180-4 - Secure Hash Standard (SHA-1, SHA-2, SHA-512/224, SHA-512/256)
3. NIST FIPS 202 - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
4. PHC string format specification
5. Argon2 reference implementation
6. RFC 7693 - The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)
7. BLAKE3 C README - default output length and extendable output
8. crypt(5) - prefixes and hashed passphrase formats
9. Apache HTTP Server 2.4 - Password Formats
10. slappasswd(8) - RFC 2307 schemes such as {SHA} and {SSHA}
11. Django documentation - example of pbkdf2_sha256$...
12. Spring Security - DelegatingPasswordEncoder storage format {id}encodedPassword

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Comment savoir quel algorithme de hachage a produit une chaîne de caractères ?

Il faut regarder, dans cet ordre : le préfixe, les séparateurs, le jeu de caractères, la longueur, puis enfin le contexte de la source de stockage. Les formats de stockage avec préfixe, comme $argon2id$, $2b$ (bcrypt), $6$ (sha512crypt), {SHA} ou pbkdf2_sha256$, peuvent être identifiés avec une assez grande précision à partir de la seule chaîne. Un simple hexadécimal ou du Base64 nu ne permettent généralement que de restreindre les candidats, et ce qui tranche en dernier lieu, c'est le contexte : la chaîne se trouve-t-elle dans /etc/shadow, dans .htpasswd, dans la table auth_user de Django, ou dans une table Spring Security ?

Une chaîne hexadécimale de 64 caractères est-elle toujours du SHA-256 ?

Non — affirmer qu'il s'agit de SHA-256 en se basant uniquement sur la longueur est prématuré. SHA3-256, SHA-512/256, BLAKE2s-256 et la sortie par défaut de 32 octets de BLAKE3 produisent tous la même longueur hexadécimale de 64 caractères. La longueur est une matière première pour constituer un ensemble de candidats, pas pour rendre un verdict. Les XOF comme SHAKE128 et SHAKE256 permettent en outre de choisir librement la longueur de sortie, si bien que le raisonnement « cette longueur, donc ce format » échoue dès qu'il s'appuie sur l'hypothèse d'un digest classique à longueur fixe.

Que signifie le préfixe $6$ au début d'une chaîne de hachage ?

C'est le préfixe de sha512crypt — une chaîne de hachage de mot de passe de la famille crypt d'Unix qui inclut un sel et un nombre d'itérations, et non un digest SHA-512 en hexadécimal. De même, $5$ correspond à sha256crypt, $1$ à md5crypt, $2a$/$2b$/$2y$ à bcrypt, $7$ à scrypt et $y$ à yescrypt. Dès qu'un préfixe est présent, la chaîne relève d'un format de stockage et non d'un simple digest, et confondre les deux fausse la suite de l'investigation.

Que signifie le préfixe {SHA} dans Apache ou LDAP ?

Dans les contextes Apache et LDAP, {SHA} ne désigne pas vaguement « la famille SHA » — dans la plupart des cas, il s'agit d'un digest SHA-1 encodé en Base64, et {SSHA} est un SHA-1 salé. De même, {MD5} et {SMD5} sont les équivalents pour MD5, et des préfixes comme {bcrypt} ou {pbkdf2} sont des enveloppes étiquetées par l'implémentation, utilisées par exemple par Spring Security. Traiter {SHA} de façon approximative comme « une sorte de SHA » d'après sa seule apparence conduit à des erreurs dans le code de vérification et la logique de migration.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.