0 bits d'entropie
Longueur de clé
Encodage
Des clés de signature HMAC pour HS256, HS384 et HS512, générées dans votre navigateur. Aucun réseau, aucun journal, aucun envoi.
Appuyez sur Espace pour regénérer, C pour copier. Généré par crypto.getRandomValues sur votre appareil ; la page ne charge aucune ressource externe.
Un jeton signé en HS256, HS384 ou HS512 se vérifie avec le secret même qui l'a signé. Ce secret n'est pas un mot de passe : personne ne le saisit, personne n'a à le retenir, et il n'a aucune raison d'être lisible ou prononçable. C'est un bloc d'octets aléatoires rangé dans une variable d'environnement ou un gestionnaire de secrets, dont la seule fonction est d'être impossible à deviner.
Les octets proviennent directement de crypto.getRandomValues, le générateur de nombres aléatoires cryptographiquement sûr du navigateur, puis sont écrits en hexadécimal ou en Base64. Aucun horodatage, aucun compteur, aucun Math.random n'intervient dans ce chemin. Choisir 256 bits donne 32 octets aléatoires, 384 en donne 48 et 512 en donne 64 : la longueur correspond au condensat utilisé par l'algorithme.
Tout se passe sur votre appareil. La page n'émet aucune requête réseau une fois chargée : le secret affiché n'a donc jamais existé ailleurs et ne circule nulle part. Rechargez la page et il disparaît définitivement.
Au moins celle du condensat de l'algorithme qui signe le jeton : 32 octets (256 bits) pour HS256, 48 octets pour HS384, 64 octets pour HS512. HMAC réduit par hachage toute clé plus longue que sa taille de bloc, si bien que 200 octets ne sont pas réellement plus robustes que 64. Le vrai danger est de descendre en dessous.
Ni l'un ni l'autre. Ce sont les mêmes octets aléatoires écrits de deux façons : 32 octets font 64 caractères en hexadécimal et environ 44 en Base64, pour une robustesse identique. Prenez le format attendu par votre bibliothèque. Si la valeur doit traverser un fichier de configuration ou un script shell, l'hexadécimal est plus sûr puisqu'il ne contient que 0-9 et a-f.
Le Base64URL remplace + et / par - et _ et supprime le remplissage, ce qui permet de placer la valeur dans une URL, une chaîne de requête ou un nom de fichier sans l'échapper. Partout ailleurs, le Base64 standard suffit. Les JWT eux-mêmes sont encodés en Base64URL, mais cela concerne le jeton, pas le secret qui le signe.
Vous le pouvez, et c'est la façon la plus courante de casser une signature HMAC. Une phrase mémorisable porte bien moins d'entropie que sa longueur ne le laisse croire, et un attaquant disposant d'un seul jeton valide peut tester des candidats hors ligne à la vitesse que permet son matériel. Aucune limitation du nombre d'essais ne s'y oppose. Utilisez des octets aléatoires.
Tout dépend de la capacité de la page à l'envoyer quelque part, et c'est une chose que vous pouvez vérifier plutôt que croire. Ouvrez les outils de développement, placez-vous sur l'onglet Réseau et générez autant de secrets que vous voulez : cette page n'émet aucune requête après son chargement. Il n'y a aucun traitement côté serveur derrière, parce qu'il n'y en a pas à avoir.
Dans une variable d'environnement, ou dans un gestionnaire de secrets si vous en avez un. Jamais dans le dépôt : un secret validé dans git reste dans l'historique même après suppression, et un historique se clone, se duplique et se sauvegarde. Si cela s'est déjà produit, le remplacer est la seule correction qui vaille.
Selon un rythme que vous tiendrez vraiment, et sans délai après toute suspicion de fuite. L'obstacle pratique est que le renouvellement invalide tous les jetons signés avec l'ancien secret. Les systèmes qui doivent tourner sans déconnecter tout le monde acceptent en général deux secrets pendant une fenêtre : signature avec le nouveau, vérification avec les deux, puis retrait de l'ancien.
Non. Ces algorithmes sont asymétriques : ils signent avec une clé privée et vérifient avec la clé publique correspondante, ce qu'il vous faut est donc une paire de clés et non un secret partagé. Cette page produit des secrets HMAC symétriques, ceux qu'utilise la famille HS. Si l'émetteur et le vérificateur sont deux parties distinctes, l'asymétrique est généralement le bon choix.
Non, et rien ne le pourrait. Cette page est un unique fichier HTML statique dont les styles et le script sont intégrés ; une fois arrivée dans votre navigateur, elle ne charge rien et n'envoie rien. Pas de mesure d'audience, pas de police distante, pas de script tiers, et aucun serveur susceptible d'en garder trace.