Outils de développement · Générateur UUID
Un UUID aléatoire est-il sûr comme réinitialisation de mot de passe ou jeton de session ?
· Pourquoi c'est important
uuid cryptographie API du navigateur
Un UUID v4 d'un CSPRNG a beaucoup d'entropie, alors pourquoi les examinateurs de sécurité désapprouvent-ils toujours les jetons UUID ? Cet article sépare la question d'entropie de la question de conception.
Le lien de réinitialisation qui utilise le UUID de la ligne — un raccourci courant et les deux raisons très différentes pour lesquelles il peut être dangereux
Un raccourci courant : utilisez l'identifiant de ligne UUID de l'utilisateur comme jeton de réinitialisation du mot de passe. Le tableau a une colonne uuid ; c'est unique; c'est difficile à deviner (s'il s'agit d'une v4). L'URL est /reset? token=550e8400-e29b-41d4-a716-446655440000. Un évaluateur de sécurité le rejette immédiatement, non pas parce que le UUID est faible, mais parce qu'il associe deux préoccupations qui devraient être indépendantes. La ligne UUID est stable et généralement visible publiquement (dans les URL, les API, les journaux). Le jeton de réinitialisation doit être à usage unique et secret. La réutilisation de la ligne UUID comme jeton signifie que l'identité de l'utilisateur et son identifiant réinitialisé ont la même valeur, et que l'identifiant dure éternellement au lieu d'expirer. Un attaquant connaissant l'ID de l'utilisateur peut effectuer une réinitialisation. Un utilisateur qui a copié-collé un lien de réinitialisation il y a cinq ans peut toujours l'utiliser. Ce sont des défauts de conception, pas des défauts d’entropie.
Contrôle d'entropie : 122 bits aléatoires – pourquoi une v4 générée par CSPRNG n'est pas devinable par force brute
Le contrôle du caractère aléatoire est nécessaire mais pas suffisant. La version 4 réserve quatre bits de version et deux bits de variante, laissant 128 - 4 - 2 = 122 positions aléatoires lorsque l'implémentation remplit les autres champs de manière aléatoire. Cette dérivation ne dit rien sur l'expiration, le stockage ou l'autorisation. La vérification du générateur demande si ces champs proviennent d'un CSPRNG plutôt que de Math.random ou d'un horodatage. ToolAcre satisfait à cette limite du générateur. La vérification de la conception reste spécifique à l'application : un identifiant réinitialisé nécessite un cycle de vie distinct, une représentation stockée unidirectionnelle, une invalidation après une utilisation réussie et une expiration choisie dans la politique de risque du service. La réutilisation de l'ID d'enregistrement permanent de l'utilisateur échoue à cette séparation, même lorsque l'ID a été généré de manière sécurisée.
Vérification du générateur : où les jetons UUID échouent réellement – Génération basée sur Math.random, horodatages v1 et adresses MAC, et graines prévisibles
Un exemple concret : un système de réinitialisation de mot de passe qui échoue, puis réussit les trois vérifications. Échec du contrôle d'entropie : le serveur émet un jeton de réinitialisation via Math.random(), emballé sous forme de v4 UUID. Un attaquant observe trois jetons et prédit le quatrième. Échec de la vérification du générateur : le serveur utilise un v1 UUID comme jeton de réinitialisation, y compris l'horodatage de création et l'adresse MAC dans la valeur. Un attaquant lit l'horodatage, apprend quand la réinitialisation a été effectuée et réduit la fenêtre de recherche. Réussit le contrôle d'entropie mais échoue au contrôle de conception : le serveur utilise un UUID v4 de crypto.getRandomValues, mais le stocke en texte brut dans la base de données et ne définit pas d'expiration. Un attaquant qui viole la base de données lit les jetons de réinitialisation et les utilise pour réinitialiser les comptes des semaines plus tard. Les trois contrôles sont indépendants ; vous devez réussir les trois.
Vérification de la conception : identifiant par rapport aux informations d'identification – pourquoi la réutilisation de la clé primaire d'un enregistrement en tant que secret associe deux éléments qui doivent tourner indépendamment
Un schéma de jeton de réinitialisation qui réussit les vérifications d'entropie et du générateur mais échoue au contrôle de conception (pas de hachage, pas d'expiration, pas d'invalidation par utilisation) est toujours vulnérable. Gestion du jeton côté serveur : lorsqu'un utilisateur demande une réinitialisation du mot de passe, générez un nouveau jeton aléatoire (pas la ligne UUID) à partir de crypto.getRandomValues. Stockez une représentation unidirectionnelle plutôt que la valeur présentée, définissez une expiration spécifique à la stratégie et invalidez l'enregistrement après une utilisation réussie. Lorsque l'utilisateur clique sur le lien, recherchez l'utilisateur par e-mail, récupérez le hachage stocké, comparez le jeton fourni avec le hachage, vérifiez l'expiration et exécutez la réinitialisation uniquement si le jeton est valide et n'a pas encore expiré. Invalidez immédiatement le jeton (supprimez-le ou marquez-le comme utilisé) afin qu'il ne puisse pas être réutilisé. N'enregistrez jamais le jeton brut ; enregistrez uniquement l’ID utilisateur et l’action.
Gestion du jeton côté serveur : stockez un hachage, définissez une expiration, invalidez lors de l'utilisation et n'enregistrez jamais la valeur brute
Le jeton ne doit jamais apparaître dans les messages d'erreur ou dans la base de données à moins qu'il ne soit haché. La conception d'une authentification complète dépasse la portée d'un article UUID, mais les principes sont valables : un jeton aléatoire 122 bits n'est pas en soi un jeton d'accès. Le hasard est la partie la plus facile ; le générateur ToolAcre vous donne des UUID pris en charge par CSPRNG. La partie la plus difficile est la conception : hacher avant le stockage, définir des délais d'expiration, invalider lors de l'utilisation, empêcher la réutilisation des identifiants permanents comme secrets temporaires, vérifier qui a accédé à quoi et quand. Un examinateur de sécurité qui approuve un schéma de réinitialisation de lien basé uniquement sur l'entropie du jeton ignore le reste de l'analyse. Un développeur qui pense qu'un UUID soutenu par CSPRNG est suffisant pour un lien de réinitialisation de mot de passe sans hachage, expiration et invalidation sous-estime la menace. Le hasard défend contre les suppositions ; la conception protège contre la relecture, l’expiration et l’utilisation abusive.
Exemple concret : examiner un schéma de réinitialisation de lien pour chaque vérification et réécrire les parties faibles
Le générateur ToolAcre fait correctement la partie aléatoire ; l'application doit faire correctement la partie conception. Testez votre propre code de lien de réinitialisation par rapport aux trois vérifications : utilise-t-il un CSPRNG (crypto.getRandomValues, crypto.randomUUID ou une bibliothèque de cryptographie), et non Math.random ? Le token a-t-il une date d'expiration ? Le jeton est-il haché avant le stockage ? Le token est-il invalidé après utilisation ? Le code évite-t-il de réutiliser l’identifiant permanent de l’utilisateur comme jeton temporaire ? Si vous répondez oui à toutes ces questions, la conception de votre lien de réinitialisation est valable. Le générateur ToolAcre est la partie CSPRNG ; le reste est du code d’application que vous devez examiner attentivement. Comprendre les trois couches de sécurité vous aide à auditer les bibliothèques et les frameworks UUID tiers. Lorsque vous évaluez une bibliothèque, vérifiez qu'elle utilise un CSPRNG (vérification d'entropie), et non une source aléatoire faible. Vérifiez qu'il documente les sources qu'il utilise et pourquoi (vérification du générateur).
Ce que cela ne couvre pas : conception d'authentification complète, MFA et limitation de débit, qui comptent autant que l'entropie des jetons
Vérifiez que l'exemple de code et la documentation mettent l'accent sur les principes de conception : hachage, expiration, invalidation (contrôle de conception). Les bibliothèques qui réussissent les trois contrôles sont rares ; la plupart se concentrent uniquement sur l’entropie. Le générateur ToolAcre réussit les vérifications d'entropie et du générateur en utilisant crypto.getRandomValues. Le contrôle de conception relève de votre responsabilité ; la bibliothèque ne peut pas connaître vos exigences d'expiration ou votre stratégie de hachage. Le débogage d'un système de réinitialisation de lien défectueux révèle généralement l'un des trois échecs. Si les utilisateurs signalent avoir reçu des liens de réinitialisation qui ne fonctionnent plus, le problème est probablement celui de l'expiration : le jeton a été émis mais a expiré avant que l'utilisateur ne clique sur le lien. Si les jetons sont réutilisés plusieurs fois, l’invalidation est interrompue. Si des jetons apparaissent dans les messages d’erreur ou dans la sortie de débogage, la journalisation les divulgue. Si les liens de réinitialisation fonctionnent pour un utilisateur mais pas pour un autre, il peut y avoir un décalage de réplication de la base de données ou des problèmes de fuseau horaire avec le calcul de l'expiration. Si les demandes de réinitialisation légitimes échouent de manière aléatoire, le CSPRNG peut être interrompu (rare).
À retenir : le caractère aléatoire est la partie la plus facile : le générateur ToolAcre vous donne des UUID pris en charge par CSPRNG ; le reste est une discipline de conception
Commencez par la journalisation : activez les journaux d'audit détaillés pour la génération et la vérification du lien de réinitialisation, puis reproduisez le problème et suivez le flux. Le générateur ToolAcre garantit la réussite des deux premiers contrôles ; le dépannage des problèmes de réinitialisation du lien entre presque toujours dans la catégorie de la conception. Les meilleures pratiques pour les systèmes de réinitialisation de lien de production incluent : générer un nouveau jeton aléatoire pour chaque demande de réinitialisation, sans réutiliser les anciens jetons. Stockez une représentation unidirectionnelle à côté des métadonnées du compte et de la création, puis choisissez une expiration dans la politique de risque documentée du service. Invalidez le jeton immédiatement après une vérification réussie. Enregistrez les demandes de réinitialisation et les réussites pour l’audit. Implémentez une limitation de débit pour empêcher les attaques par force brute. Envoyez des liens de réinitialisation par e-mail uniquement, pas par SMS ou via des canaux non cryptés. Avertissez l'utilisateur des tentatives de réinitialisation du mot de passe (afin qu'il puisse détecter les réinitialisations non autorisées). Le générateur ToolAcre vous donne le caractère aléatoire ; suivre ces pratiques vous donne la sécurité.