Mot de passe vs UUID vs Hash vs Token : Guide des 8 types de chaînes aléatoires

En développement logiciel, on croise sans cesse des chaînes comme 550e8400-e29b-41d4-a716-446655440000 ou eyJhbGciOiJIUzI1NiJ9... — des suites de caractères d’apparence aléatoire. UUID, mots de passe, hachages, jetons, clés API… ils se ressemblent tous, mais leur intention de conception et leur finalité sont fondamentalement différentes.

Cet article décompose les 8 types les plus courants de chaînes d’apparence aléatoire sous l’angle du « pourquoi elles existent » et du « ce qu’elles protègent ». Une fois que vous comprenez ce qu’est réellement chacune, choisir la bonne selon la situation devient un réflexe.

Comparaison des 8 types

Commençons par la vue d’ensemble.

Type	Usage principal	Secret ?	Réversible ?	Génération	Trait clé
UUID	Identification unique	Non	—	Aléatoire / temps	ID sans collision
Mot de passe	Authentification utilisateur	Oui	Propriétaire seul	Créé par l’humain	Secret mémorisé
Hachage	Vérification d’intégrité	Non	Irréversible	Fonction mathématique	Empreinte numérique
Jeton	Authentification / autorisation	Oui	Selon le cas	CSPRNG	Expire
Clé API	Authentification de service	Oui	—	CSPRNG	Mot de passe machine
Sel (Salt)	Renforcement du hachage	Non	—	CSPRNG	Défense anti rainbow table
Nonce	Identification à usage unique	Non	—	CSPRNG	Prévention du rejeu
Signature	Détection d’altération	Non	Irréversible	Calcul crypto	HMAC, signature RSA

L’idée essentielle : classez selon la finalité de conception, pas selon l’apparence. La même chaîne aléatoire de 32 caractères peut n’être qu’une étiquette quand elle sert d’UUID, ou une clé d’authentification quand elle sert de jeton.

UUID — Une étiquette sans collision

Un UUID (Universally Unique Identifier) existe pour générer des identifiants qui n’entreront pas en collision — partout dans le monde, sans coordination. Il n’a rien à voir avec la sécurité ; son unique rôle est l’identification.

La variante la plus utilisée, l’UUID v4, est générée aléatoirement avec 122 bits d’entropie. Cela représente environ 5,3 × 10³⁶ valeurs possibles — même en en générant un milliard par seconde, il faudrait attendre plus de 10 milliards d’années pour une collision.

Cas d’usage courants :

• Clés primaires de base de données (alternative à l’auto-incrément)
• Identifiants d’objets uniques dans les systèmes distribués
• Noms de fichiers sans collision pour les téléversements
• Identifiants de requête pour le traçage et la journalisation

→ Essayez et apprenez avec notre générateur d’UUID gratuit

Mot de passe — Le seul secret géré par l’humain

Parmi les 8 types, les mots de passe sont les seuls conçus pour la mémorisation humaine. Leur entropie dépend donc intrinsèquement de la mémoire humaine — et reste de ce fait plus faible que les alternatives générées par machine.

C’est précisément pourquoi les mots de passe exigent un traitement particulier pour leur stockage. Les stocker en clair est inacceptable. Ils doivent être hachés, et pas avec n’importe quel hachage — la bonne pratique moderne impose des algorithmes volontairement lents comme bcrypt, Argon2 ou scrypt.

Pourquoi « lent » importe-t-il ? Lorsqu’un attaquant tente des milliards de calculs de hachage par seconde par force brute, un algorithme qui prend 0,1 seconde par calcul augmente le coût de l’attaque de plusieurs ordres de grandeur.

Cas d’usage courants :

• Authentification de connexion aux services web
• Identifiants d’accès SSH et base de données
• Phrases de passe de chiffrement pour les fichiers

→ Essayez et apprenez avec notre générateur de mots de passe gratuit

Hachage — Une empreinte numérique

Une fonction de hachage prend une entrée de longueur quelconque et produit une sortie de longueur fixe — une transformation à sens unique. La même entrée donne toujours la même sortie, mais on ne peut pas revenir en arrière. Voyez-la comme l’empreinte digitale d’une donnée.

Par exemple, SHA-256 compresse aussi bien un « hello » de 5 caractères qu’un fichier de 1 Go en une valeur de 256 bits (64 caractères hexadécimaux). Changez ne serait-ce qu’un bit de la donnée d’origine, et le hachage change complètement.

Cas d’usage courants :

• Stockage de mots de passe — Stocker le hachage au lieu du texte en clair
• Contrôles d’intégrité de fichiers — Vérifier que les téléchargements n’ont pas été altérés (sommes de contrôle)
• Identifiants de commit Git — Git gère chaque commit avec des hachages SHA-1
• Blockchain — Les chaînes de transactions sont sécurisées par des hachages

→ Essayez et apprenez avec notre générateur de hachage gratuit

Jeton — Un laissez-passer temporaire

Un jeton prouve que « cette personne est authentifiée » — temporairement. Après une connexion réussie, le serveur émet un jeton ; les requêtes suivantes incluent ce jeton pour affirmer « je suis déjà authentifié ».

L’exemple le plus connu est le JWT (JSON Web Token), composé de trois parties encodées en Base64 : l’en-tête, la charge utile (payload) et la signature. La charge utile contient l’identifiant utilisateur et l’expiration, et la signature détecte toute altération.

Cas d’usage courants :

• Gestion de session des applications web
• Jetons d’accès et de rafraîchissement OAuth 2.0
• Liens à usage unique pour la vérification d’e-mail et la réinitialisation de mot de passe
• Authentification sans état (stateless) dans les SPA

→ Essayez et apprenez avec notre générateur de jetons gratuit

Clé API — Un mot de passe pour les machines

Une clé API est une chaîne qui permet à une application ou à un service de dire « je suis un utilisateur autorisé ». Elle n’est pas saisie par un humain — elle est intégrée au code et jointe aux requêtes.

La plus grande différence avec les mots de passe : personne n’a besoin de la retenir. Cela permet de générer des chaînes aléatoires suffisamment longues (128–256 bits), bien plus robustes. La contrepartie : elles sont souvent laissées en clair dans le code source ou les fichiers de configuration, créant un risque de fuite élevé.

Cas d’usage courants :

• Authentification d’API externes (Google Maps, OpenAI, Stripe)
• Authentification interne de service à service dans les microservices
• Identification pour la facturation et la limitation de débit

→ Essayez et apprenez avec notre générateur de clés API et de jetons gratuit

Sel, Nonce et Signature — Les spécialistes de l’ombre

Ces trois-là apparaissent rarement seuls — ce sont des composants qui renforcent d’autres mécanismes.

Sel (Salt)

Un sel est une valeur aléatoire ajoutée par utilisateur lors du hachage des mots de passe. Même si deux utilisateurs partagent le mot de passe « password123 », des sels différents produisent des hachages différents. Cela déjoue les attaques par rainbow table — des dictionnaires de hachages pré-calculés.

Les sels n’ont pas besoin d’être secrets — ils sont stockés à côté du hachage dans la base de données. Les algorithmes modernes comme bcrypt et Argon2 gèrent la génération et la gestion du sel en interne, si bien que les développeurs ont rarement à les manipuler manuellement.

Nonce

Nonce signifie « Number used ONCE » — une valeur jetable. Son objectif principal est la prévention des attaques par rejeu. Si un attaquant intercepte puis renvoie une requête, le serveur reconnaît que le nonce a déjà été utilisé et la rejette.

En développement web, les nonces servent aussi de jetons de protection CSRF (Cross-Site Request Forgery). La fonction wp_nonce_field() de WordPress en est un exemple bien connu.

Signature

Une signature prouve que des données n’ont pas été altérées. Le HMAC (Hash-based Message Authentication Code) combine une clé secrète avec un message pour calculer un hachage. Sans la clé secrète, un tiers ne peut pas produire de signature valide — le destinataire peut donc confirmer que les données proviennent d’un expéditeur légitime.

Le alg: HS256 dans un en-tête JWT signifie « signé avec HMAC-SHA256 ». Les webhooks d’API (Stripe, GitHub, etc.) utilisent eux aussi des signatures HMAC pour détecter l’altération du corps des requêtes.

Organiser selon les axes de conception

Plutôt que de mémoriser chaque type individuellement, organisez-les selon 5 axes.

Type	Secret ?	Récupérable ?	Unicité critique ?	Expire ?	Usage humain ?
UUID	×	×	◎	×	×
Mot de passe	◎	◎ (propriétaire seul)	△	×	◎
Hachage	×	× (irréversible)	△	×	×
Jeton	◎	△	◎	◎	×
Clé API	◎	×	◎	△	×
Sel	×	×	△	×	×
Nonce	×	×	◎	◎	×
Signature	×	× (irréversible)	—	—	×

Remarquez que seuls les mots de passe ont ◎ en « Usage humain ». Cela souligne à quel point les mots de passe constituent un cas fondamentalement particulier parmi tous ces types de chaînes.

Raisonner en modèles d’attaque

En conception de sécurité, la question directrice n’est pas « que protégeons-nous ? » mais « quelle attaque empêchons-nous ? ». Chaque type de chaîne fait face à une menace différente.

Type	Attaque à prévenir	Stratégie de défense
UUID	Collision (ID en double)	Assez d’entropie pour rendre les collisions négligeables
Mot de passe	Force brute / dictionnaire	Hachage lent + sel + mots de passe longs
Hachage	Attaque par préimage / collision	Utiliser des algorithmes sûrs (SHA-256+)
Jeton	Rejeu / interception	TTL court + HTTPS + rotation des refresh
Clé API	Fuite	Variables d’env + rotation + restrictions d’IP
Nonce	Rejeu	Usage unique + suivi côté serveur
Signature	Altération	Gestion stricte de la clé secrète

Vous n’avez pas besoin de résistance à la force brute pour les UUID, et vous vous souciez rarement de la résistance aux collisions pour les mots de passe. Des menaces différentes exigent des conceptions différentes.

Un arbre de décision pratique

Quand vous hésitez sur le type à utiliser, suivez ce cheminement :

1. Définissez la finalité — Identification ? Authentification ? Vérification ? Temporaire ?
2. Identifiez la menace — Collision ? Devinette ? Fuite ? Rejeu ? Altération ?
3. Déterminez l’entropie requise — 122 bits pour un UUID, 256 bits pour un jeton
4. Choisissez la méthode de génération — Math.random() n’est jamais acceptable ; utilisez les modules crypto
5. Décidez du stockage — En clair ? Haché ? Chiffré ? Variable d’environnement ?

Le point 4 est crucial. Les générateurs aléatoires standard (Math.random(), random.random()) ne sont pas cryptographiquement sûrs. Pour toute chaîne liée à la sécurité, utilisez toujours un CSPRNG (générateur de nombres pseudo-aléatoires cryptographiquement sûr). En Python, c’est le module secrets ; en Node.js, crypto.randomBytes().

En résumé

Regroupés par finalité de conception, les 8 types se répartissent en 4 catégories :

• Identification : UUID
• Authentification : Mot de passe, Clé API
• Vérification : Hachage, Signature
• Authentification temporaire / défense : Jeton, Nonce, Sel

Ils peuvent sembler identiques, mais leur finalité de conception est entièrement différente — c’est le message central de cet article.

En tant que développeur, adoptez ce principe : « Ne regardez pas la chaîne — regardez la finalité. » Que vous conceviez une nouvelle chaîne aléatoire ou que vous manipuliez une chaîne existante, demandez-vous toujours d’abord « qu’est-ce que cela protège ? ». La bonne méthode de génération, la bonne approche de stockage et la bonne politique d’expiration en découleront naturellement.