Formater du JSON
Mettre en forme, valider et replier du JSON.
Développement
Identifier un type de hachage par son format.
La longueur est l'indice principal, mais elle n'est pas décisive.
| Longueur (hex) | Algorithme probable |
|---|---|
| 32 caractères | MD5 ou NTLM |
| 40 caractères | SHA-1 |
| 56 caractères | SHA-224 |
| 64 caractères | SHA-256 |
| 96 caractères | SHA-384 |
| 128 caractères | SHA-512 |
Une valeur hexadécimale de 32 caractères peut être du MD5 ou du NTLM issu de l'environnement Windows. La longueur seule ne tranche pas ; le contexte si.
Certains formats sont en revanche sans ambiguïté car ils portent un préfixe. Une valeur commençant par $2y$ est du bcrypt, $argon2id$ de l'Argon2, et $6$ indique du SHA-512-Crypt, employé sur les systèmes Unix.
Ces préfixes contiennent généralement aussi le facteur de coût et le sel, ce qui les rend très reconnaissables.
Pour des empreintes encodées en Base64, la longueur change, et il faut alors raisonner sur le nombre d'octets.
C'est ici que l'identification devient utile.
Si vous trouvez dans une base des mots de passe stockés en MD5 ou SHA-1, c'est un problème sérieux. Ces algorithmes sont extrêmement rapides, et c'est précisément ce qui les rend impropres aux mots de passe : une carte graphique ordinaire teste des milliards de combinaisons par seconde.
SHA-256 lui-même est inadapté au hachage de mots de passe bien qu'il ne soit pas cassé sur le plan cryptographique. La raison est la même : il est trop rapide.
Les mots de passe exigent des algorithmes volontairement lents, avec un facteur de coût réglable. Les recommandations, y compris celles de l'ANSSI, citent Argon2, bcrypt et scrypt, ainsi que PBKDF2 avec un nombre élevé d'itérations là où les autres ne sont pas disponibles.
Argon2id est aujourd'hui considéré comme le meilleur choix pour un développement nouveau.
Et un sel est toujours indispensable : une valeur aléatoire par mot de passe qui empêche des mots de passe identiques de produire des empreintes identiques et rend inopérantes les tables précalculées. Les algorithmes cités le génèrent eux-mêmes.
Si vous trouvez des empreintes MD5 dans un système existant, la démarche habituelle consiste à rehacher à la prochaine connexion réussie et à remplacer progressivement les anciennes valeurs.
Le RGPD impose par ailleurs des mesures techniques appropriées : stocker des mots de passe avec un algorithme obsolète est difficile à défendre après une violation de données.
Quelques mises au point nécessaires à répétition.
Une empreinte n'est pas du chiffrement. Elle n'est pas réversible : il n'existe aucune clé pour revenir en arrière.
Pour autant, les empreintes faibles peuvent être « cassées », non par inversion mais par essais. Pour des mots de passe courts ou courants, une simple consultation dans une table précalculée suffit souvent.
Une empreinte ne dit rien non plus de la longueur de l'entrée : une lettre et un livre entier produisent une valeur de même taille.
Pour les sommes de contrôle de fichiers, les empreintes sont en revanche idéales, et SHA-256 y est le bon choix. Administrations et éditeurs publient des sommes de contrôle avec leurs téléchargements.
Pour un fichier téléchargé, la comparaison vaut vraiment la peine : elle prend quelques secondes et détecte aussi bien les erreurs de transfert que les téléchargements manipulés.
Cet outil fonctionne localement dans votre navigateur.
Seulement de façon probable. Mais les préfixes comme $2y$ sont sans ambiguïté.
Non. Ils sont bien trop rapides et permettent des essais massifs.
Argon2id, bcrypt ou scrypt, et PBKDF2 à forte itération si rien d'autre n'est possible.
Il empêche des mots de passe identiques de donner la même empreinte et neutralise les tables précalculées.
Non, mais les empreintes faibles se cassent par essais successifs.
Non.