06. Aléatoire cryptographique et tokens opaques

Comprendre le mécanisme

Un token de reset ou de lien sensible doit être imprévisible, limité dans le temps et lié à un usage précis. random_bytes fournit des octets adaptés à la cryptographie ; leur encodage change la représentation, pas l’entropie. Seize octets et seize caractères hexadécimaux ne représentent pas la même quantité d’aléatoire. Un identifiant séquentiel ou un horodatage n’est pas un secret.

Raisonner et vérifier

Stockez si possible une empreinte du token côté serveur et comparez après recherche maîtrisée, afin de réduire l’exposition de la valeur utilisable en cas de fuite de stockage. Fixez unicité d’usage, expiration et transition atomique. L’envoi et les logs ne doivent pas publier la capacité. Un générateur solide ne compense pas une absence d’autorisation ou une réutilisation illimitée.

Source de hasard

random_bytes fournit des octets adaptés à la cryptographie. La précision temporelle ne remplace pas une source aléatoire adaptée. random_bytes utilise une source adaptée aux secrets cryptographiques. Un timestamp ou un identifiant séquentiel reste prévisible même après encodage ; il ne constitue pas un bon secret de réinitialisation.

Longueur et entropie

32 octets donnent 64 caractères hexadécimaux. Il augmente la longueur de représentation sans nouvelle information. Chaque octet devient deux caractères hexadécimaux. Trente-deux octets aléatoires donnent 64 caractères sans doubler l’entropie ; conservez cette distinction pour dimensionner génération, stockage et format des URL.

Finalité

Un token doit être lié à son usage. La capacité doit garder un périmètre précis. Liez le token au compte et à une opération précise, par exemple reset du mot de passe. Un token de confirmation d’adresse ne doit pas devenir implicitement une autorisation générale de connexion.

Expiration serveur

Une expiration doit être appliquée côté serveur. Le serveur doit décider de la validité. Enregistrez et vérifiez la borne temporelle côté serveur. Masquer le bouton après dix minutes ne bloque ni une requête rejouée ni un client qui conserve l’ancienne URL.

Consommation atomique

Un usage unique demande une transition atomique. Les appels directs peuvent contourner l’interface. Une mise à jour conditionnelle peut marquer utilisé seulement si le token est encore valide et inutilisé. Deux demandes concurrentes doivent produire un seul gagnant et une seule transition autorisée.

Empreinte stockée

Une empreinte du token peut réduire l’exposition du stockage. La valeur brute peut constituer une capacité rejouable. Pour un token opaque à forte entropie, stocker son empreinte peut limiter l’usage d’une fuite de base. Le token brut reste nécessaire au destinataire mais doit être absent des journaux ordinaires.

Remise du token

Le canal de remise doit être contrôlé. L’aléatoire n’aide plus face à une valeur divulguée. Le canal de remise et l’URL finale doivent être maîtrisés. Une fuite par referer, capture d’écran ou historique peut donner la capacité au porteur ; minimisez les données et la durée d’usage.

Limitation d’essais

Une limite d’essais complète l’entropie choisie. Le nom ne fournit pas les bits d’aléatoire. Ajoutez des budgets par compte et contexte afin de réduire les tentatives et l’abus d’envoi de messages. Cette mesure complète une entropie suffisante sans justifier une génération prévisible.

Échec de génération

Les erreurs de génération doivent être traitées. Ce remplacement retire l’imprévisibilité attendue. Si la source cryptographique échoue, refusez l’opération avec une erreur explicite et observable. Ne basculez pas vers rand, une date ou un UUID choisi sans analyse simplement pour préserver l’apparence de disponibilité.

Course concurrente

Les tests doivent essayer deux consommations simultanées. La course doit être vérifiée explicitement. Lancez deux consommations synchronisées dans un test d’intégration. Vérifiez le nombre de lignes modifiées et l’état final ; deux appels séquentiels ne reproduisent pas nécessairement la fenêtre de concurrence critique.

Atelier guidé : lire, expliquer et vérifier le code

<?php
declare(strict_types=1);
$token = bin2hex(random_bytes(16));
echo strlen($token);

L’extrait génère seize octets, puis les encode en 32 caractères hexadécimaux. Comparez cette représentation à celle de trente-deux octets. Ajoutez une table de tokens de laboratoire avec expiration et usage unique, puis vérifiez la consommation concurrente ; la génération seule n’implémente pas tout le parcours de reset.

16 est le nombre d’octets avant encodage. 128 correspond aux bits de ces 16 octets. L’aléatoire porte sur le contenu, pas sur cette longueur. Chaque octet est représenté par deux caractères hexadécimaux.

Travail pratique : Concevez un reset local et envoyez deux demandes simultanées avec le même token.

Critères de correction : Une seule transition doit réussir selon une écriture atomique. Testez token expiré, usage différent et token absent, avec réponses publiques et journaux minimisés.