Encodage, hachage et chiffrement : trois choses différentes
Presque tous les malentendus sur cette page viennent du fait qu'on les traite comme interchangeables ; ils méritent donc d'être bien distingués.
L'encodage est réversible et ne contient aucun secret. Le Base64 sert à faire passer des données binaires par des canaux qui n'acceptent que du texte — pièces jointes d'e-mail, URI de données, chaînes JSON — en représentant chaque groupe de trois octets par quatre caractères, d'où un résultat toujours environ un tiers plus gros. Il n'y a pas de clé. Quiconque voit la chaîne peut la décoder en une étape, y compris sur ce site. Le Base64 n'est pas une protection, pas une obfuscation digne de ce nom, et pas un moyen de cacher quoi que ce soit à qui prend la peine de regarder. L'encodage-pourcent est le même genre de chose pour les URL, et c'est là que se trouve l'autre bug courant : encoder une valeur destinée à une chaîne de requête n'est pas la même opération que nettoyer une URL complète déjà assemblée, car seule la première échappe les &, =, ? et / qui donnent sa structure à une URL. Si vous vous trompez, « Dupont & Fils » arrive au serveur sous forme de deux paramètres au lieu d'une seule valeur.
Le hachage est à sens unique et n'a pas de clé non plus. Un hash prend n'importe quelle entrée et produit une empreinte de longueur fixe, et il n'y a pas de retour arrière — non parce qu'elle est chiffrée, mais parce que l'information a disparu. Ce que l'on peut faire, c'est deviner des entrées et comparer, et c'est exactement ce qui rend MD5, SHA-1 et SHA-256 inadaptés au stockage des mots de passe : ils sont rapides, une carte graphique en calcule des milliards par seconde, et une table volée se casse à cette vitesse. Les mots de passe exigent une fonction volontairement lente et salée — bcrypt, scrypt ou Argon2. Par ailleurs, MD5 et SHA-1 sont cassés pour une autre raison : on sait désormais fabriquer délibérément deux fichiers différents ayant le même hash, si bien qu'aucun des deux ne peut prouver qu'un fichier est bien celui que vous attendiez, même s'ils restent valables pour repérer un téléchargement corrompu par accident.
Le chiffrement est le seul qui utilise une clé, et aucun de ces outils n'en fait. Ce n'est pas un oubli. Bien chiffrer suppose de gérer des clés, et une page web n'est pas l'endroit où mettre une clé.
Un JWT est signé, pas chiffré, et cela piège constamment les gens. L'en-tête et la charge utile d'un jeton sont en Base64URL — lisibles par quiconque détient le jeton, sans clé. La signature empêche quelqu'un de modifier le jeton ; elle n'empêche en rien de le lire, donc rien de confidentiel n'a sa place dans une charge utile. Il s'ensuit que décoder un jeton ne prouve absolument rien à son sujet : n'importe qui peut écrire les claims de son choix et les passer en Base64. Vérifier signifie recalculer la signature avec la clé de l'émetteur, ce que fait votre serveur et qu'un site web ne doit jamais demander. Notre décodeur refuse donc de laisser croire à une vérification, et signale les formes révélatrices d'un problème — un jeton expiré, un jeton sans aucune expiration, et un algorithme « none », qui est un contournement d'authentification documenté plutôt qu'une curiosité.
Le JSON a une limite de précision des nombres dans laquelle la plupart des formateurs tombent sans prévenir. Le JSON lui-même ne limite pas la taille d'un nombre, mais un nombre JavaScript est un flottant 64 bits : les entiers ne restent exacts que jusqu'à 9 007 199 254 740 991. Un identifiant de publication Twitter, un snowflake Discord, une clé de base de données 64 bits ou un numéro de compte bancaire dépasse cette valeur, et le faire passer dans le formateur habituel en une ligne — parse, puis stringify — modifie ses derniers chiffres. Le résultat ressemble toujours à un nombre plausible, et c'est ce qui le rend dangereux : 7205759403792793600 devient discrètement 7205759403792793000. Nos outils JSON resérialisent les chiffres exacts que vous avez collés et vous indiquent combien de nombres ils ont dû protéger.
La version d'un UUID décrit sa fabrication, pas ce qu'il garantit. Rien n'enregistre un UUID ni n'impose son unicité ; l'unicité est probabiliste, et la version vous dit d'où viennent les bits. La version 4, ce sont 122 bits d'aléa issus du générateur cryptographique du navigateur, ce qui la rend impossible à deviner et donc adaptée aux liens de réinitialisation, aux codes d'invitation et à tout ce qui est secret — mais inadaptée comme clé de base de données, car des clés aléatoires s'éparpillent dans un index trié et le fragmentent. La version 7 place en tête un horodatage de 48 bits à la milliseconde, si bien que les clés s'ajoutent à la fin de l'index comme un entier auto-incrémenté tout en restant uniques au niveau mondial. La contrepartie : un UUID v7 révèle clairement sa date de création, à la milliseconde près, à quiconque le détient.
Quand un navigateur n'est vraiment pas le bon outil
Aucun de ces treize outils n'envoie quoi que ce soit nulle part. Aucune requête n'est émise, rien n'est journalisé, et les pages continuent de fonctionner réseau déconnecté — c'est justement pour cela qu'on peut les utiliser sur une réponse d'API remplie de données clients ou sur un jeton que vous n'enverriez à personne par e-mail. Voilà les arguments honnêtes en leur faveur. Voici les arguments honnêtes contre.
Coller un secret de production en service dans une page web est une habitude à ne pas prendre — y compris sur celle-ci. Notre engagement de confidentialité est vrai, mais ce n'est pas une promesse qui vous protège ; c'est le comportement du code, et la seule attitude raisonnable face à n'importe quelle page web est de vérifier plutôt que de faire confiance. La vérification ne coûte rien : déconnectez-vous d'internet une fois la page chargée et regardez ces outils continuer à fonctionner. Un outil qui aurait besoin d'un serveur s'arrêterait. Et si un identifiant est encore valide et que vous l'avez déjà collé quelque part que vous ne pouvez pas auditer, la bonne réaction est de le renouveler, pas de s'interroger. Pour un jeton actif en ce moment même, le décoder en local — avec la fonction Base64 de votre langage, ou deux lignes dans un terminal — est une meilleure pratique que n'importe quel site web, le nôtre compris.
La validation par schéma. Nos outils JSON et XML vérifient qu'un document est bien formé, ce qui est une autre question que sa conformité à un schéma. Valider selon un JSON Schema ou un XSD suppose de récupérer et d'appliquer un fichier de schéma, c'est-à-dire une requête réseau que ces pages s'interdisent délibérément. Utilisez ajv pour JSON Schema et xmllint pour XSD et DTD ; tous deux sont gratuits et font ce travail mieux qu'une page web ne le pourrait.
Tout ce qui est vraiment volumineux, ou en flux. Les documents sont gardés entiers en mémoire, parfois en double pendant le formatage, donc la limite est l'onglet. Quelques mégaoctets, c'est instantané ; quelques centaines, non. jq traite en flux un fichier JSON de plusieurs gigaoctets qu'aucun navigateur n'ouvrira, et ripgrep parcourt tout un dépôt plus vite que vous ne collez un seul fichier. Le hachage connaît une version plus stricte de cette limite : la cryptographie du navigateur n'offre pas de condensé incrémental, donc le fichier entier doit tenir en mémoire d'un coup — une image de DVD échouera, là où sha256sum, shasum ou certutil la liront en flux sans broncher.
L'automatisation et la CI. Ces outils s'exécutent quand quelqu'un clique. Formater tous les fichiers d'un dépôt, générer dix mille UUID dans une fixture ou vérifier du JSON dans un pipeline relève d'un script : jq, xmllint, uuidgen, openssl et la commande base64 sont déjà installés sur la plupart des machines.
Vérifier tout ce qui est signé. La vérification de signatures, les chaînes de certificats et tout ce qui exige une clé privée doivent se faire sur votre serveur, avec une bibliothèque maintenue. Cette page vous dira ce qu'un jeton affirme ; elle ne vous dira jamais qu'un jeton est authentique, et vous devriez vous méfier de tout site qui prétend le pouvoir sans votre clé.
Choisir entre des outils aux noms proches
Formateur JSON ou Validateur JSON ? Même analyseur, question différente. Le formateur sert à lire et remettre en forme un document qui s'analyse déjà — l'indenter, le minifier, préserver les grands nombres. Le validateur sert à un document qui ne s'analyse pas, et il vous donne la ligne, la colonne, le caractère fautif avec un accent circonflexe en dessous, et laquelle des quatre causes habituelles est en jeu. Si vous avez sous les yeux « Unexpected token », c'est le validateur qu'il vous faut. La même répartition vaut pour le Formateur XML et le Validateur XML.
Décoder du Base64 ou Décodeur JWT ? Un JWT se compose de trois sections en Base64URL, donc le décodeur généraliste vous en montrera les morceaux. La page JWT les sépare pour vous, formate le JSON, convertit les claims d'expiration, d'émission et de début de validité — des horodatages Unix — en vraies dates dans votre fuseau horaire, nomme les claims enregistrés, et vous avertit en cas d'expiration ou d'algorithme « none ». Utilisez le décodeur généraliste pour un bloc Base64 et la page JWT pour un jeton.
Encoder en Base64 ou Encoder une URL ? Deux tâches différentes qui produisent toutes deux du texte « sûr ». Le Base64 transforme des octets quelconques en texte au prix de 33 % de taille en plus, et le Base64 standard n'est pas du tout sûr dans une URL — ses +, / et = y ont tous un sens, d'où l'existence du Base64URL. L'encodage-pourcent laisse lisible un texte lisible et n'échappe que ce qui casserait l'URL, ce qu'il vous faut pour un terme de recherche, une adresse e-mail ou une cible de redirection. Encoder un fichier entier pour une chaîne de requête est généralement le signe qu'il aurait dû être le corps de la requête.
Générateur de hash ou Générateur d'UUID ? Un hash est dérivé de son entrée : la même entrée donne toujours la même valeur — c'est ce qui en fait une empreinte, utile pour vérifier un téléchargement ou dédoublonner un contenu identique. Un UUID est de l'aléa tout neuf, sans lien avec quoi que ce soit, donc il ne se répète jamais. Si vous voulez le même identifiant pour le même contenu, hachez-le. Si vous voulez un nouvel identifiant, générez un UUID.
Générateur de QR code ou Générateur de code-barres ? Un QR code est une grille à deux dimensions qui contient un texte quelconque — une URL, des identifiants Wi-Fi, un numéro de téléphone — et se lit avec l'appareil photo d'un téléphone. La page code-barres crée les codes à une dimension du commerce et de la logistique : EAN-13, EAN-8, UPC-A, ITF-14, Code 128 et Code 39, avec la clé de contrôle commerciale calculée, et un numéro erroné ou trop court refusé plutôt que complété en douce en un code-barres valide pour un autre produit.