Hash, MD5, mots de passe et certificats TLS

Comprendre le mécanisme

Une fonction de hash calcule une empreinte déterministe d’octets. Elle ne chiffre pas une donnée et ne fournit pas une clé de déchiffrement. Préimage, seconde préimage et collision décrivent des objectifs adverses différents. Une empreinte publique peut aider à comparer deux fichiers, mais un adversaire capable de remplacer fichier et empreinte peut recalculer les deux. La provenance de la référence est donc une partie du problème.

Raisonner et vérifier

Choisissez l’outil selon la menace : hash moderne pour comparaison d’octets, MAC avec clé pour authenticité partagée, signature pour une distribution asymétrique, fonction de mot de passe pour vérification d’un secret humain. N’utilisez pas un nom d’algorithme moderne comme justification universelle. Définissez encodage, normalisation et limites avant de comparer des valeurs afin d’éviter de hasher des représentations différentes sans le vouloir.

Déterminisme

Un hash calcule une empreinte déterministe. Une empreinte n’est pas une donnée chiffrée réversible par clé. Le même fichier, octet pour octet, doit fournir la même sortie avec le même algorithme. Une fin de ligne ou un encodage différent change l’entrée même si le texte semble identique à l’écran.

Collision et préimage

Une collision relie deux entrées de même empreinte. Collision et préimage sont des objectifs différents. Une collision cherche deux messages distincts partageant une sortie ; une préimage cherche un message pour une sortie donnée. Une démonstration de la première propriété ne fournit pas automatiquement la seconde attaque.

Référence authentifiée

La provenance d’une empreinte de référence compte. Il peut recalculer une référence non protégée. Si le fichier et son checksum sont téléchargés depuis une source compromise unique, les deux peuvent être remplacés. Établissez la référence par un canal ou une signature dont la confiance est indépendante.

Empreinte et auteur

Un hash public ne prouve pas l’auteur. L’encodage ne crée pas de preuve d’origine. N’importe qui peut calculer SHA-256 sur un document. Pour attribuer sa provenance, vérifiez une signature et la confiance dans sa clé, ou une autre preuve adaptée au modèle de distribution.

Octets couverts

Les octets exacts influencent l’empreinte. La représentation doit être définie et comparée. Définissez si l’empreinte couvre le corps brut ou une représentation canonique. Convertir du JSON en objet puis le sérialiser peut modifier espaces et ordre des propriétés sans conserver les octets d’origine.

Authentification partagée

Un MAC ajoute une clé à une construction d’authenticité. Le secret partagé change le modèle de confiance. Un MAC ajoute une clé secrète connue des participants. Il permet de vérifier une authenticité dans ce groupe, mais chaque détenteur de la clé conserve la capacité de produire une preuve valide.

Signature asymétrique

Une signature sépare des capacités de clé publique et privée. Le calcul public d’empreinte n’est pas une signature. La clé privée signe et la clé publique permet la vérification selon l’algorithme. Distribuez cette clé publique par une référence fiable ; remplacer document et clé ensemble peut tromper une vérification isolée.

Secrets humains

Un mot de passe humain demande une fonction dédiée. Un hash rapide ne règle pas le coût des essais hors ligne. Les mots de passe ont souvent une faible entropie. Utilisez une fonction adaptative dédiée qui ralentit les essais et gère le sel, plutôt qu’un hash rapide prévu pour d’autres usages.

Représentation

L’encodage ne crée pas d’entropie. La même information reçoit une autre représentation. Hexadécimal et base64 changent la représentation des mêmes octets. Une sortie plus longue n’implique pas davantage de hasard ; mesurez l’entropie à partir de la génération du secret initial.

Choisir une propriété

Le choix de primitive dépend de la menace. Authenticité, confidentialité et vérification de mot de passe diffèrent. Pour détection d’erreur, provenance, confidentialité et stockage de mot de passe, les besoins diffèrent. Écrivez l’attaquant et la propriété attendue avant de sélectionner une primitive ou une API.

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

<?php
declare(strict_types=1);
$hash = hash('sha256', 'lab');
echo strlen($hash);

SHA-256 fournit ici 32 octets affichés en hexadécimal, donc 64 caractères. Comparez sortie brute et sortie encodée pour distinguer taille mathématique et représentation. Modifiez ensuite un octet du message. Ce laboratoire vérifie le déterminisme et la sensibilité aux entrées, sans prouver l’auteur du message.

SHA-256 donne 32 octets, représentés ici par 64 caractères hexadécimaux. 32 serait la taille binaire, pas cette représentation par défaut. 256 est un nombre de bits, pas la longueur textuelle. Le hash a une longueur fixée par l’algorithme.

Travail pratique : Modifiez un octet d’un fichier puis comparez son empreinte. Remplacez ensuite simultanément fichier et référence sur un stockage fictif.

Critères de correction : La première comparaison détecte le changement par rapport à une référence conservée. La seconde démontre qu’une référence modifiable par le même adversaire ne fournit pas d’authenticité.

Comprendre le mécanisme

MD5 ne convient plus aux usages exigeant une résistance aux collisions, notamment les signatures numériques. Une collision consiste à produire deux entrées ayant la même empreinte ; cela ne signifie pas que tout mot de passe ou tout fichier arbitraire devient immédiatement récupérable depuis son hash. La faiblesse de MD5 ne doit pas non plus être confondue mécaniquement avec toutes les propriétés de HMAC-MD5. Les nouveaux protocoles doivent choisir des alternatives adaptées.

Raisonner et vérifier

Inventoriez l’usage avant migration. Un checksum de compatibilité historique, une signature de document et un stockage de mot de passe ne demandent pas le même remplacement. Pour un mot de passe, passer de MD5 à un hash rapide moderne conserve un défaut de conception : les essais hors ligne restent peu coûteux. Évitez les collisions prêtes à l’emploi sur des systèmes tiers ; démontrez le raisonnement sur des fixtures et une architecture de laboratoire.

Collision exploitable

MD5 est impropre aux nouvelles signatures exigeant la résistance aux collisions. Les collisions connues excluent ce choix pour cet usage. Une signature qui s’appuie sur une empreinte à collisions faibles peut ne plus distinguer des documents choisis par un attaquant. Pour une nouvelle conception, sélectionnez une construction actuelle adaptée à la propriété recherchée.

Préimage distincte

Une collision n’inverse pas tout hash arbitraire. Les objectifs et difficultés sont distincts. Ne présentez pas une paire de fichiers en collision comme une méthode de récupération de tout original. Le modèle d’attaque et le contrôle permis sur les messages déterminent ce que l’expérience démontre réellement.

Construction HMAC

HMAC-MD5 demande une analyse distincte du hash nu. La construction HMAC possède d’autres propriétés à analyser. Les attaques contre un hash nu et celles contre un MAC à clé ne se transfèrent pas mécaniquement. Analysez la construction et les contraintes héritées, tout en évitant HMAC-MD5 dans un nouveau protocole.

Nouveau protocole

Un nouveau protocole doit préférer des alternatives adaptées. La compatibilité héritée ne justifie pas ce choix nouveau. Privilégiez des API et profils maintenus, avec séparation des clés et formats définis. Remplacer seulement le nom MD5 sans revoir le protocole peut laisser le défaut d’authentification ou de rejeu intact.

Mots de passe

Un mot de passe ne se migre pas simplement vers un hash rapide. La fonction de mot de passe doit gérer un coût approprié. Remplacer MD5 par SHA-256 direct maintient un coût d’essai faible. Une migration doit viser un hash adaptatif de mot de passe, avec politique de vérification et remise à niveau après succès.

Inventaire des usages

La migration dépend du rôle du hash. Leurs menaces et propriétés attendues diffèrent. Une empreinte peut servir de clé de cache, de compatibilité ou de preuve cryptographique. Classez ces usages avant de changer le format : leurs risques et leurs consommateurs ne sont pas interchangeables.

Consommateurs hérités

L’inventaire doit inclure les consommateurs hérités. D’autres composants peuvent encore interpréter l’ancien format. Recherchez exports, API et scripts qui interprètent encore la sortie historique. Versionnez le contrat de transition et vérifiez que l’ancien chemin ne reste pas une possibilité de contournement indéfinie.

Compatibilité annoncée

Une empreinte MD5 de compatibilité ne doit pas être présentée comme preuve forte d’auteur. La provenance et les propriétés cryptographiques manquent. Un ancien checksum peut rester nécessaire pour échanger avec un outil. Marquez clairement sa finalité et fournissez une preuve moderne séparée si une authenticité forte du document est exigée.

Retrait organisé

Les anciens chemins doivent avoir un plan de retrait. Une compatibilité illimitée conserve le risque. Définissez date, propriétaire et métrique de trafic de l’ancien format. Un double support permanent augmente les chemins à maintenir et laisse parfois les clients sélectionner la protection la plus faible.

Laboratoire borné

Les démonstrations doivent rester dans un laboratoire. Le périmètre d’essai doit être maîtrisé. Utilisez des données factices et des fichiers de démonstration connus. Conservez versions et résultats, puis expliquez la propriété observée sans extrapoler vers des systèmes ou documents tiers.

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

<?php
declare(strict_types=1);
echo strlen(md5('lab-document'));

Le programme affiche la longueur de la représentation hexadécimale MD5, soit 32 caractères. Cette mesure ne dit rien sur sa résistance aux collisions. Distinguez la propriété vérifiée par le code de celle requise par un stockage de mot de passe ou une signature de document.

La longueur seule ne donne pas cette garantie. Le type string ne prouve pas la propriété cryptographique. La taille du document ne justifie pas cette conclusion. La représentation de la sortie n’annule pas les faiblesses de collision.

Travail pratique : Classez trois usages hérités : checksum public, vérification de mot de passe et signature d’un document. Proposez un plan pour chacun.

Critères de correction : Documentez la provenance du checksum ; utilisez une fonction de mot de passe adaptée avec migration contrôlée ; remplacez la chaîne de signature et ses dépendances selon les contraintes du système. Gardez des tests de compatibilité limités et un calendrier de retrait.

Comprendre le mécanisme

HMAC combine une fonction de hash et une clé selon une construction définie. Un MAC valide établit une authenticité relative aux détenteurs de cette clé ; il ne cache pas le message et ne distingue pas lequel de plusieurs détenteurs l’a produit. Ne remplacez pas HMAC par une concaténation improvisée de clé et de message. Le format exact des octets authentifiés doit être partagé par les participants.

Raisonner et vérifier

Pour un webhook, documentez corps brut ou représentation canonique, version du protocole, métadonnées couvertes et protection contre le rejeu. Un MAC correct sur un ancien événement ne le rend pas nouveau. Les clés doivent être propres à l’usage et à l’environnement. Vérifiez avec une API adaptée et bornez les entrées avant les opérations coûteuses.

Clé partagée

HMAC utilise une clé secrète partagée. L’authenticité dépend notamment de la protection de cette clé. Émetteur et vérificateur possèdent le même secret. Limitez ce groupe de confiance et distribuez la clé dans un gestionnaire de secrets ; une copie publique dans un dépôt retire la propriété attendue.

Auteur dans le groupe

Tout détenteur de la clé peut calculer un MAC. La capacité symétrique n’est pas séparée. Si deux services connaissent la clé, chacun peut produire le même MAC. La preuve ne permet pas à elle seule d’attribuer l’origine à l’un plutôt qu’à l’autre devant un tiers.

Message visible

HMAC ne chiffre pas le message. Le contenu peut rester lisible. Le corps authentifié reste lisible pour qui le reçoit. Utilisez un canal chiffré ou une construction de chiffrement adaptée lorsqu’une confidentialité est nécessaire, sans confondre secret de clé et secret du contenu.

Octets exacts

Les octets authentifiés doivent être définis. Les octets peuvent changer malgré un sens métier similaire. Pour un webhook, le protocole peut signer timestamp et corps brut. Ne parsez puis resérialisez pas le JSON avant vérification si cela change les octets couverts par la preuve reçue.

Construction dédiée

Une concaténation maison ne remplace pas HMAC. Une construction standard possède des propriétés spécifiques. hash(key . message) n’est pas une définition interchangeable de HMAC. Utilisez hash_hmac ou la bibliothèque du protocole, avec algorithme et représentation explicitement fixés des deux côtés.

Rejeu

Le rejeu demande un contrôle distinct. La preuve d’origine ne garantit pas la nouveauté. Un message ancien peut garder un MAC valide. Vérifiez la fenêtre temporelle prescrite et consommez une identité d’événement de façon durable et atomique pour empêcher la répétition d’un effet métier.

Séparation des clés

Les clés doivent être séparées par usage pertinent. Le partage élargit les capacités affectées. Une clé de signature de webhook ne doit pas servir par commodité de clé de chiffrement ou de session. La séparation limite les interactions entre protocoles et l’impact d’une divulgation.

Comparaison

Une comparaison adaptée doit vérifier la preuve. Une conversion peut confondre des représentations. Calculez la référence avec les octets et la clé attendus puis utilisez une comparaison adaptée, comme hash_equals pour les chaînes de ce contrat. Vérifiez format et taille avant la comparaison.

Métadonnées liées

Les métadonnées couvertes doivent suivre le protocole. Seuls les octets couverts participent à la preuve. Signer le corps sans les métadonnées nécessaires peut laisser une ambiguïté de destination ou d’interprétation. Suivez exactement le profil du fournisseur, y compris version de signature et timestamp lorsqu’ils sont prescrits.

Fixtures publiques

Les fixtures ne doivent pas contenir les clés réelles. Le support ne doit pas exposer une capacité réelle. Les clés répétées dans les exemples servent uniquement au laboratoire. Générez un secret réel adapté dans l’environnement concerné et excluez-le des captures, logs de tests et exports de diagnostic.

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

<?php
declare(strict_types=1);
$key = str_repeat('k', 32); // fixture publique de laboratoire
$a = hash_hmac('sha256', 'amount=10', $key);
$b = hash_hmac('sha256', 'amount=11', $key);
var_dump(hash_equals($a, $b));

Les messages amount=10 et amount=11 sont différents au niveau des octets ; leurs MAC calculés avec la même clé diffèrent. Exécutez le programme puis changez également la clé. Observez que cette preuve ne masque pas le montant et qu’une répétition du premier message garderait sa preuve valide.

HMAC admet ces deux messages. Comparer des preuves n’accorde pas de permission métier. Les octets couverts changent ; les deux MAC calculés sont différents. La clé identique ne rend pas tous les messages équivalents.

Travail pratique : Modifiez les espaces du JSON, rejouez un message valide et testez une autre clé dans un récepteur local.

Critères de correction : Selon le contrat de corps brut, des octets modifiés invalident le MAC. Ajoutez le suivi d’événement et la fenêtre temporelle requis pour refuser le rejeu indépendamment de l’authenticité.

Webhook PSP : preuve, fraîcheur et transition durable

Commencez par conserver le corps brut borné reçu et le timestamp requis par le contrat. Vérifiez le format de signature exact avec la bibliothèque ou construction prescrite. Parser puis resérialiser le JSON avant vérification peut changer les octets et invalider la preuve, ou conduire à vérifier autre chose que le message reçu.

Contrôlez la fraîcheur selon une fenêtre bornée et une horloge maîtrisée. Une signature valide ne prouve pas à elle seule que l’événement est nouveau : le fournisseur peut relivrer et un message ancien peut être rejoué.

Enregistrez durablement l’identité d’événement et appliquez une transition métier autorisée dans une frontière cohérente, ou utilisez une inbox durable avant traitement différé. Acquittez selon ce point de durabilité, puis prévoyez reprise et déduplication. Testez signature incorrecte, timestamp ancien, doublon simultané et panne après effet avant réponse. Chaque scénario doit conserver un seul effet et permettre un diagnostic sans token ni secret dans les traces.

Points de vigilance : La vérification doit suivre le contrat exact du PSP ; la transaction ou l’inbox durable protège ensuite l’effet contre les relectures. La réécriture peut changer les octets signés ; supprimer le contrôle temporel affaiblit la protection contre le rejeu. Un événement authentique peut être relivré légitimement plusieurs fois. L’IP ne remplace pas les contrôles du contrat, et les événements n’annoncent pas tous un succès.

Comprendre le mécanisme

password_hash fournit un format qui inclut les informations nécessaires à la vérification selon l’algorithme. Les sels doivent être gérés par l’API ; un sel public n’est pas un secret partagé. PASSWORD_DEFAULT peut évoluer, ce qui demande un stockage suffisamment large et une stratégie de rehash. Argon2id dépend des capacités de la compilation PHP ; sa disponibilité doit être vérifiée dans l’environnement ciblé.

Raisonner et vérifier

Mesurez coût, mémoire et concurrence sur une machine représentative avant de fixer des paramètres. Une politique trop coûteuse sans limitation d’abus peut épuiser le service ; une politique trop faible accélère les essais hors ligne. Ne journalisez jamais mot de passe ou hash dans les tests d’exploitation. La vérification de mot de passe ne remplace ni les protections contre le credential stuffing ni la sécurité du reset.

API dédiée

password_hash est une API dédiée aux mots de passe. L’encodage réversible ne ralentit pas les essais hors ligne. password_hash produit un format qui contient les informations nécessaires à la vérification. Ne construisez pas manuellement un protocole de stockage autour d’un hash rapide et d’un sel concaténé au hasard.

Sel généré

L’API gère le sel dans son format. Des sels adaptés différencient les calculs. Deux hachages du même mot de passe peuvent différer grâce au sel. Stockez la chaîne complète et utilisez password_verify, plutôt que recalculer une nouvelle chaîne puis rechercher une égalité textuelle.

Rôle du sel

Le sel n’est pas une clé de déchiffrement. Le hash n’est pas un chiffrement réversible. Le sel rend les calculs spécifiques au compte et gêne les précalculs partagés. Il peut être public avec le hash ; il ne transforme pas un mot de passe faible en secret à forte entropie.

Budget concurrent

Le coût doit être mesuré sous concurrence. Plusieurs vérifications consomment simultanément des ressources. Mesurez temps et mémoire avec plusieurs connexions simultanées, pas seulement une requête isolée. Un coût trop élevé peut épuiser les workers et devenir un levier de déni de service.

Évolution de DEFAULT

PASSWORD_DEFAULT peut évoluer. Le stockage et le rehash doivent anticiper les évolutions. Prévoyez une colonne assez longue pour les évolutions de format. Après un succès, comparez le hash stocké à la politique cible afin de remettre progressivement les comptes à niveau.

Disponibilité Argon2id

Argon2id dépend des capacités de la compilation PHP. La disponibilité doit être vérifiée sur la cible. Vérifiez les algorithmes disponibles dans la compilation utilisée en production. Une constante ou un exemple de documentation ne remplace pas ce contrôle sur le runtime web et les outils CLI concernés.

Stockage complet

Le stockage doit accepter la longueur du format. La vérification exige le format complet. Une troncature de colonne peut rendre le hash invérifiable. Testez écriture et relecture réelles, longueur comprise, avec la politique choisie ; n’enregistrez jamais seulement une partie du format.

Vérification

password_verify utilise les informations du hash. Le format stocké porte les paramètres nécessaires. password_verify reçoit le mot de passe présenté et la chaîne stockée. Le format indique le sel et les paramètres ; l’application n’a pas besoin de retrouver ni de déchiffrer le mot de passe initial.

Abus en ligne

La limitation d’abus complète le hash adaptatif. Il peut aussi consommer les ressources de l’authentification. Le hash adaptatif traite surtout le coût des essais hors ligne après fuite. Ajoutez budgets de connexion, détection d’abus et politique d’authentification pour limiter les essais dirigés contre le service actif.

Traces

Les logs doivent exclure le mot de passe. Des valeurs fictives suffisent au laboratoire. Journalisez un résultat d’authentification et un contexte minimisé, sans secret présenté ni hash complet. Contrôlez aussi les outils APM qui peuvent capturer automatiquement les corps de formulaire.

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

<?php
declare(strict_types=1);
$hash = password_hash('lab-secret', PASSWORD_DEFAULT);
var_dump(password_verify('lab-secret', $hash));

Le programme crée un hash puis vérifie le même mot de passe : le résultat est vrai même si un second hachage produirait une autre chaîne. Ajoutez un essai incorrect et contrôlez le résultat faux. Le coût de démonstration ne doit pas être adopté sans mesure sur votre environnement réel.

Le format conserve les informations nécessaires à la vérification. L’API utilise les paramètres du format pour vérifier le même secret. Le programme affiche un booléen, pas le secret. Le sel n’est pas la valeur affichée.

Travail pratique : Mesurez latence et mémoire d’une vérification avec différentes concurrences, puis comparez à votre budget d’authentification.

Critères de correction : Retenez des paramètres justifiés et documentez l’environnement. Vérifiez que le stockage accepte les formats futurs et que l’authentification gère proprement une erreur de ressources.

Vérifier un mot de passe et décider du rehash

Le hash enregistré par password_hash contient algorithme, sel et paramètres. password_verify interprète ce format pour vérifier le secret présenté. Refaire password_hash puis comparer les deux chaînes serait incorrect, car un nouveau sel peut produire une autre représentation pour le même mot de passe.

La séquence est donc lecture du credential, vérification, puis éventuelle décision password_needs_rehash après succès. Si la politique a évolué, calculez un nouveau hash du secret réellement présenté et protégez l’écriture contre un reset concurrent. Une comparaison de version ou de hash précédent peut empêcher d’écraser un nouveau credential légitime.

Testez bon secret, mauvais secret et hash nécessitant une remise à niveau. Le mauvais secret ne doit provoquer ni connexion ni remplacement du hash. Mesurez le coût sous charge et gardez les valeurs présentées hors logs et traces : l’API dédiée ne protège pas une copie en clair produite par l’application.

Points de vigilance : Un nouveau sel peut produire un autre hash pour le même mot de passe. Un SHA-256 brut n’est pas le format du hash de mot de passe stocké. La fonction interprète le format, le sel et le coût enregistrés et réalise la vérification appropriée. Une comparaison faible n’est pas une vérification de mot de passe et introduit des ambiguïtés de types.

Comprendre le mécanisme

password_verify compare un secret présenté au format de hash attendu. Après une authentification réussie, password_needs_rehash permet de décider une mise à jour avec la politique courante. La transition doit résister aux accès concurrents et ne pas remplacer accidentellement un mot de passe changé entre-temps. Le secret en clair ne doit vivre que le temps strictement nécessaire au traitement.

Raisonner et vérifier

Pour un héritage MD5, identifiez le schéma par une métadonnée maîtrisée, pas seulement une supposition sur la longueur. Vérifiez l’ancien schéma dans un chemin limité et retirez-le dès migration ou réinitialisation. Hacher la chaîne MD5 comme si elle était le secret utilisateur n’équivaut pas à retrouver un stockage direct adapté du mot de passe. Une réinitialisation sûre est préférable lorsqu’une vérification héritée ne peut être maintenue correctement.

Succès préalable

Le rehash suit une vérification réussie. Un échec ne prouve pas un secret légitime. Vérifiez d’abord le secret présenté avec le schéma actuel identifié. Rehasher une valeur incorrecte avant cette étape permettrait de remplacer le credential légitime avec une donnée fournie par l’attaquant.

Politique cible

password_needs_rehash compare à une politique. La décision de mise à jour n’est pas une authentification. password_needs_rehash compare algorithme et paramètres du hash à ceux demandés. Il ne valide pas le mot de passe et ne réalise pas lui-même l’écriture de migration dans la base.

Version de schéma

Le schéma hérité doit être identifié explicitement. Des formats peuvent se ressembler et demander une métadonnée. Conservez une indication non ambiguë du format historique. Évitez de deviner plusieurs algorithmes successivement après chaque échec, ce qui rendrait la règle d’acceptation difficile à auditer et à retirer.

Original absent

Hacher un ancien MD5 ne retrouve pas l’original. Les entrées sont différentes. Passer une chaîne MD5 à password_hash protège cette chaîne selon une nouvelle couche ; cela ne retrouve pas le mot de passe. Une migration normale réutilise le secret réellement présenté après vérification réussie.

Reset concurrent

Une écriture conditionnelle peut protéger un reset concurrent. Une autre transition légitime peut avoir modifié le compte. Écrivez le nouveau hash seulement si l’ancien hash ou la version du credential correspond encore à la lecture initiale. Sinon, un reset intervenu entre-temps pourrait être écrasé par la migration tardive.

Retrait par compte

Le chemin hérité doit être retiré pour un compte migré. Le retrait fait partie de l’amélioration recherchée. Quand le format cible est enregistré, ne gardez pas un ancien hash alternatif pour ce compte. Vérifiez que le code de connexion n’accepte plus le chemin hérité après la transition.

Réinitialisation

Une réinitialisation sûre peut remplacer une migration impossible. Une empreinte n’offre pas cette capacité générale. Si le format ou le secret ne peut être vérifié correctement, prévoyez une réinitialisation par un canal maîtrisé. Ne transformez pas une migration impossible en exception d’authentification permanente.

Vie du secret

Le secret présenté doit être conservé le moins longtemps possible. La preuve de migration peut rester expurgée. Gardez le mot de passe présenté seulement pendant la vérification et le rehash nécessaires. Ne l’insérez pas dans une queue de migration, une trace de requête ou un fichier temporaire.

Tests de transition

Les tests doivent couvrir mauvais secret et succès. Le chemin négatif demande une assertion spécifique. Couvrez mauvais secret, succès migré et reset concurrent. Vérifiez à la fois connexion autorisée, hash final et retrait du schéma ancien ; une simple réponse HTTP réussie ne prouve pas la transition.

Compatibilité effective

Le format cible doit être vérifiable dans l’environnement. La cible réelle doit supporter la politique choisie. Le runtime qui vérifie les futurs logins doit supporter le format produit. Vérifiez tous les nœuds lors d’une mise à jour progressive afin qu’un compte migré reste utilisable après changement de serveur.

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

<?php
declare(strict_types=1);
$hash = password_hash('lab', PASSWORD_BCRYPT, ['cost' => 4]);
var_dump(password_needs_rehash($hash, PASSWORD_BCRYPT, ['cost' => 5]));

Dans cet atelier, la politique demandée utilise un coût bcrypt différent de celui du hash stocké. needs_rehash indique donc une différence, sans authentifier le secret. Dans une connexion réelle, placez cette décision après password_verify et protégez l’écriture contre une modification concurrente du credential.

La politique demandée a un coût différent du format actuel. Les paramètres ne correspondent pas. La fonction retourne une décision, pas un secret. Le code ne réalise aucune écriture.

Travail pratique : Simulez connexion correcte, mauvais secret, changement de politique et reset concurrent sur un compte fictif.

Critères de correction : Seul le succès peut déclencher le rehash. L’écriture compare l’état attendu ou utilise une transaction adaptée. Le reset concurrent reste prioritaire et l’ancien chemin est retiré pour le compte migré.

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.

Comprendre le mécanisme

hash_equals compare des chaînes selon une conception visant à limiter les fuites temporelles de comparaison. La référence connue doit être passée comme premier argument et l’entrée utilisateur comme second. Le contrat de longueur et d’encodage reste important ; la fonction ne dérive pas de clé, ne ralentit pas les essais de mot de passe et ne vérifie pas l’origine d’un message par elle-même.

Raisonner et vérifier

Calculez d’abord la valeur attendue avec la primitive adaptée, validez le format reçu puis comparez. Ne convertissez pas des empreintes en nombres et n’utilisez pas une égalité faible qui pourrait mélanger représentations. password_verify reste l’API adaptée aux formats de mots de passe. Les tests de laboratoire doivent vérifier contrat et refus sans prétendre démontrer toute absence de canal auxiliaire sur une machine réelle.

Comparer des chaînes

hash_equals compare des chaînes selon une API adaptée. La comparaison n’effectue pas la dérivation du secret. hash_equals est une API de comparaison, pas une fonction de hachage ou de stockage. Elle reçoit deux chaînes déjà construites selon le contrat ; le calcul préalable de la référence reste votre responsabilité.

Ordre des arguments

La référence connue doit être le premier argument. Le contrat documente l’ordre référence puis entrée. Placez la valeur connue en premier et l’entrée reçue en second. Conservez cet ordre dans un helper commun et vérifiez les cas de longueur inattendue sans exposer la référence dans les erreurs.

Représentation admise

La représentation reçue doit être validée. Format et preuve restent à contrôler. Un MAC hexadécimal et les mêmes octets en base64 sont deux chaînes différentes. Validez alphabet et longueur selon le protocole, puis comparez une représentation déterminée plutôt que plusieurs conversions permissives.

Égalité faible

Une égalité faible peut confondre des représentations. La comparaison doit respecter les chaînes attendues. Une comparaison numérique ou faible peut traiter des chaînes de condensat comme des nombres. Le contrat porte sur les octets de la preuve ; utilisez une comparaison qui ne change pas leur interprétation.

Référence correcte

La valeur attendue doit être calculée par la bonne primitive. Comparer ne crée pas la preuve à vérifier. Une comparaison résistante aux différences de temps ne répare pas un MAC calculé sur le mauvais message. Vérifiez clé, algorithme, octets couverts et métadonnées avant d’évaluer la preuve.

Mots de passe

password_verify reste adapté au format de mot de passe. La vérification de mot de passe interprète ses paramètres. Le format de password_hash contient ses paramètres et son sel. Utilisez password_verify pour cette tâche ; comparer un nouveau hash aléatoirement salé au hash stocké échouerait même avec le bon secret.

Contrat de longueur

La longueur du secret influence le contrat de comparaison. Le traitement doit toujours maîtriser ses ressources. Fixez une taille attendue pour le format choisi et rejetez les entrées malformées. La longueur n’est pas toujours secrète, mais son traitement doit correspondre à l’API et au protocole réellement utilisés.

Canaux auxiliaires

Un test fonctionnel ne prouve pas tous les canaux auxiliaires. L’environnement et le modèle de menace limitent l’assurance. Une mesure de temps sur quelques appels locaux ne certifie pas l’absence de fuite exploitable. L’ensemble de la réponse, du parsing et des accès au stockage peut introduire d’autres différences observables.

Secret de laboratoire

Une clé publique de démonstration ne doit pas devenir un secret réel. Une valeur publiée n’est pas secrète. Une clé illustrative répétée est publique par définition. Employez un secret réel généré et distribué pour le service, en excluant les valeurs de production des tests et des exemples pédagogiques.

Autorisation d’usage

Comparer un token ne définit pas son droit d’usage. Le périmètre et l’état de la capacité restent à vérifier. Même un token correctement comparé peut être expiré ou viser une autre opération. Vérifiez compte, finalité, durée et consommation après ou avec la preuve selon le contrat conçu.

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

<?php
declare(strict_types=1);
$expected = hash_hmac('sha256', 'lab', str_repeat('k', 32));
$provided = $expected; // entrée simulée
var_dump(hash_equals($expected, $provided));

La valeur reçue est ici une copie exacte de la référence et la comparaison réussit. Modifiez un caractère puis testez une longueur différente. Ces essais démontrent le contrat fonctionnel de l’API, sans constituer à eux seuls un audit des canaux auxiliaires du système complet.

La comparaison ne demande pas de clé TLS. Les valeurs comparées sont des chaînes. L’API documente cet ordre pour la référence et la donnée reçue. Cet ordre inverse le contrat recommandé.

Travail pratique : Testez la même valeur, une valeur modifiée, une représentation numérique et une longueur incorrecte.

Critères de correction : Le contrat doit refuser les formats incorrects et ne jamais utiliser une conversion numérique pour établir l’égalité d’un MAC. Vérifiez ensuite le chemin nominal de l’API de mot de passe séparément.

Comprendre le mécanisme

TLS protège un canal avec négociation cryptographique et authentification selon le mode choisi. Un navigateur peut obtenir un canal authentifié vers un nom sans que chaque action applicative soit légitime. La terminaison TLS peut aussi se trouver avant l’application : le trajet interne et la confiance proxy doivent être décrits. Les clés de session et la clé privée du certificat ont des fonctions différentes.

Raisonner et vérifier

Les données précoces 0-RTT de TLS 1.3 présentent des contraintes de rejeu. Ne les traitez pas comme une garantie d’unicité pour une mutation sensible ; les politiques du serveur et du protocole applicatif doivent en tenir compte. Conservez des tests de validation de certificat et des erreurs de transport, puis testez séparément l’autorisation métier sur le canal établi.

Protection du trajet

TLS protège un canal selon un mode d’authentification. La protection du transport n’autorise pas les opérations. TLS protège les échanges entre ses deux terminaisons lorsque l’authentification et les paramètres sont corrects. Il ne remplace ni validation des entrées ni décision de permission sur une opération applicative.

Proxy et application

Une terminaison proxy sépare des trajets. Le trajet suivant demande sa propre configuration. Si TLS termine au reverse proxy, le trajet suivant possède sa propre configuration. Dessinez les deux connexions et vérifiez séparément chiffrement, authentification et réseau entre proxy et application.

Clés de rôles distincts

La clé de certificat et les clés de session ont des rôles différents. Négociation et identité utilisent des éléments distincts. La clé liée au certificat sert à l’authentification selon le protocole. Les secrets de trafic sont issus de l’établissement de session ; évitez de décrire TLS comme un simple chiffrement intégral par la clé du certificat.

Données précoces

Les données précoces 0-RTT demandent une analyse de rejeu. Le protocole prévoit des contraintes de rejeu spécifiques. Le 0-RTT de TLS 1.3 peut être rejoué dans certaines conditions. N’y admettez pas sans analyse une opération qui débite ou déclenche un effet non répétable ; gardez un contrôle applicatif adapté.

Identité attendue

Le client doit vérifier l’identité attendue. Le chiffrement sans confiance correcte ne suffit pas. Le client vérifie la chaîne et le nom de la destination. Un certificat valide pour un autre service ne suffit pas, même si la connexion chiffre effectivement les octets échangés.

Droits applicatifs

Une connexion valide peut porter une demande interdite. Le contrôle de droit reste serveur. Un attaquant peut utiliser HTTPS lui aussi. Contrôlez acteur et ressource pour chaque mutation ; la présence du cadenas ne prouve aucun droit sur la réservation demandée.

Échéance observée

L’expiration du certificat doit être surveillée. Le renouvellement relève d’un cycle d’exploitation. Surveillez le certificat réellement présenté depuis l’extérieur, avec marge avant expiration. Un nouveau fichier sur disque peut ne pas avoir été chargé par le service ou par tous ses nœuds.

Refus conservé

Les pannes de confiance doivent rester des refus. Le contournement supprime la garantie de pair attendu. Ne désactivez pas la validation de pair ou de nom pour contourner une panne. Corrigez chaîne, magasin de confiance ou destination puis testez que le service mal identifié reste refusé.

Tests séparés

Le test doit distinguer transport et métier. Le résultat métier ne décrit pas tous les contrôles de canal. Un test de connexion valide couvre un trajet de transport. Ajoutez des demandes autorisées et interdites sur le même canal pour établir les règles métier indépendamment de la réussite TLS.

Configuration versionnée

Les versions et paramètres font partie du périmètre. Il faut vérifier le service et les hypothèses réels. Inventoriez versions TLS, bibliothèques clientes et politiques de confiance. Un résultat obtenu avec un client récent ne décrit pas forcément un worker ancien ou une autre terminaison de la chaîne.

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

// Extrait de configuration PHP cURL à analyser, non exécuté :
curl_setopt($handle, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($handle, CURLOPT_SSL_VERIFYHOST, 0);

Les deux options cURL de l’extrait désactivent les contrôles de chaîne et de nom. Elles peuvent rendre une connexion possible tout en retirant l’authentification attendue du serveur. Réparez le certificat ou le magasin de confiance dans un laboratoire, puis vérifiez qu’un certificat pour une autre destination reste refusé.

L’encodage ne constitue pas une vérification d’identité. Les options montrées désactivent précisément ces protections. Un nom de client ne vérifie pas le pair. La méthode HTTP ne restaure pas TLS.

Travail pratique : Dessinez une terminaison TLS locale et testez une requête non autorisée sur un canal valide. Étudiez la politique de données précoces du service.

Critères de correction : Le canal peut fonctionner tandis que l’action est refusée. Documentez l’activation ou le refus de 0-RTT et interdisez les conclusions d’unicité fondées uniquement sur TLS.

Comprendre le mécanisme

Un certificat X.509 lie une clé publique et des informations selon une signature d’émetteur. Une chaîne doit atteindre une ancre admise et respecter périodes de validité, contraintes et usages applicables. Posséder un fichier de certificat public ne donne pas le secret correspondant. Une chaîne syntaxiquement complète n’est pas forcément une chaîne de confiance pour le client qui la reçoit.

Raisonner et vérifier

Séparez magasin de confiance du client, certificat serveur, intermédiaires et clé privée. Un intermédiaire manquant peut provoquer un échec selon la construction de chaîne disponible ; télécharger n’importe quel certificat ne doit pas devenir une nouvelle ancre de confiance. Le renouvellement doit conserver la bonne association clé/certificat et les permissions d’accès. L’état de révocation dépend aussi des politiques et capacités du client.

Certificat public

Un certificat porte une clé publique et des informations signées. Le secret correspondant est séparé. Un certificat associe une clé publique et des informations signées. Il peut être partagé ; la clé privée correspondante reste un objet distinct qui doit être protégé contre lecture et export non autorisés.

Ancre de confiance

Une chaîne doit atteindre une ancre admise. La confiance dépend du magasin et de la politique du client. Le client construit une chaîne vers une ancre qu’il admet déjà selon sa politique. Recevoir une racine dans la réponse du serveur ne doit pas rendre cette racine automatiquement digne de confiance.

Validité temporelle

Les périodes de validité doivent être vérifiées. La validation de chemin comporte plusieurs exigences. Vérifiez notBefore et notAfter avec une horloge correcte. Une signature mathématiquement valide peut appartenir à un certificat expiré ou pas encore valable ; ce sont des conditions supplémentaires de validation.

Contraintes

Les contraintes d’usage comptent. Les extensions peuvent limiter les usages. Usages de clé, extended key usage et contraintes d’autorité limitent le rôle des certificats. La présence d’une signature ne suffit pas si un intermédiaire n’est pas admis à signer le certificat présenté.

Intermédiaires

Des intermédiaires manquants peuvent empêcher la validation. Les capacités de construction et données disponibles diffèrent. Un serveur doit fournir les éléments intermédiaires nécessaires au chemin attendu. Le succès sur un navigateur qui dispose d’un cache ne prouve pas que tous les clients construiront la même chaîne.

Représentation PEM

PEM décrit une représentation. Le format de représentation ne fixe pas le type de contenu. PEM est une enveloppe textuelle qui peut contenir différents objets selon son en-tête. Inspectez le type réel et les permissions ; un nom de fichier en .pem ne dit pas qu’il s’agit seulement d’un certificat public.

Magasin client

Le magasin client doit être identifié. Les ancres de confiance varient selon les clients. Navigateur, PHP et Java peuvent utiliser des magasins différents. Identifiez celui du client en échec avant d’importer une autorité ; une confiance ajoutée à un outil ne s’étend pas automatiquement aux autres.

Identité de service

Le nom du service demande aussi une vérification. L’identité de destination reste distincte de la validité du chemin. Après la chaîne, comparez l’identité de référence aux identifiants du certificat selon les règles du client. Une chaîne valide pour api-a ne protège pas une connexion attendue vers api-b.

Révocation

La révocation dépend des politiques et capacités du client. Le comportement doit être décrit et testé. Les mécanismes disponibles et la politique en cas d’indisponibilité varient selon le client. Documentez ce qui est réellement vérifié et le délai de retrait attendu, plutôt que supposer une consultation universelle immédiate.

Clé privée hors public

La clé privée doit être protégée hors du répertoire public. La fuite donne des capacités sensibles. Le document root ne doit jamais permettre de télécharger une clé privée ou sa sauvegarde. Protégez permissions, export, copies temporaires et accès d’exploitation séparément du certificat distribué aux clients.

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

openssl x509 -in lab-server.crt -noout -subject -issuer -dates
# subject=CN=api.example.test
# issuer=CN=Lab CA

La commande affiche sujet, émetteur et dates du certificat. Elle ne démontre ni la possession de la clé privée par un client ni la validation complète de la chaîne. Complétez le diagnostic avec un magasin de confiance identifié et un test du nom de destination attendu.

Le certificat et la clé privée sont des objets distincts. issuer décrit l’émetteur. Le nom n’est pas un secret de signature. Cette commande n’a pas cet objet ni ces paramètres.

Travail pratique : Créez une autorité locale de laboratoire puis testez client avec et sans cette ancre. Retirez un intermédiaire.

Critères de correction : Comparez les erreurs de construction et de confiance, sans désactiver les contrôles. Documentez précisément le magasin utilisé et la portée du laboratoire. Gardez la clé privée hors du répertoire public.

Comprendre le mécanisme

Une chaîne approuvée ne suffit pas si le certificat n’identifie pas le service demandé. La vérification d’identité compare le nom de référence issu du contrat de connexion aux identifiants appropriés du certificat selon les règles applicables, notamment les SAN. Les règles de wildcard sont contraintes ; une simple recherche de sous-chaîne dans le nom n’est pas une validation. Une adresse IP demande également le type d’identifiant correspondant.

Raisonner et vérifier

Ne désactivez pas verify_peer ou la vérification de nom pour résoudre une erreur de certificat. Corrigez le nom, la chaîne ou le magasin de confiance du laboratoire. SNI aide le serveur à sélectionner un certificat mais ne remplace pas la décision du client. Les tests doivent distinguer mauvaise chaîne, mauvais nom et expiration afin de rendre la correction précise.

Référence de destination

Le nom de référence vient de la destination attendue. La vérification doit conserver le contrat du client. Le nom attendu vient de l’URL ou du contrat de connexion maîtrisé par le client. Ne remplacez pas cette attente par le nom que le certificat annonce simplement pour faire réussir la comparaison.

SAN

Les SAN portent des identifiants selon des règles précises. Une comparaison approximative peut accepter un autre service. Les subjectAltName portent des identifiants typés. Appliquez les règles de correspondance du protocole client ; l’affichage convivial du subject ne suffit pas à résumer l’identité utilisable pour la destination.

Adresse IP

Une IP demande l’identifiant de type approprié. La nature de l’identifiant compte. Une connexion attendue vers une adresse IP demande un identifiant IP conforme au profil applicable. Une chaîne DNS contenant des chiffres n’est pas automatiquement équivalente à une identité IP dans un SAN.

SNI et sélection

SNI aide à sélectionner un contexte serveur. La sélection et la vérification sont distinctes. SNI permet au serveur de choisir son contexte et son certificat. Il ne constitue pas la vérification cliente de ce certificat ; les deux étapes ont des responsabilités différentes.

Wildcards limitées

Les wildcards ont une portée contrainte. Les règles ne sont pas une recherche de sous-chaîne. Un certificat générique ne couvre pas arbitrairement tous les sous-domaines et profondeurs. Vérifiez les règles du client et les noms concrets utilisés plutôt que déduire une couverture illimitée du caractère étoile.

Échec fermé

Un mauvais nom doit provoquer un refus. Le pair doit correspondre au service attendu. Le nom api-b ne correspond pas à un certificat qui identifie uniquement api-a. Le bon comportement est un refus, même si l’autorité et les dates du certificat sont valides.

Réparer sans contourner

La correction doit conserver verify_peer et le contrôle de nom. Cela retire précisément la garantie recherchée. Corrigez DNS, URL ou certificat selon la cause puis conservez verify_peer et le contrôle du nom. Une option de désactivation permanente transformerait une erreur visible en faiblesse silencieuse.

Autorité de laboratoire

Un laboratoire peut utiliser une autorité locale maîtrisée. Des clés de test suffisent à vérifier les comportements. Une CA locale maîtrisée permet des tests reproductibles sur des noms de développement. Limitez son périmètre et sa clé privée ; ne l’installez pas partout comme solution universelle aux erreurs de confiance.

Causes distinctes

Une expiration et un mauvais nom sont des causes distinctes. Identifier la cause permet de restaurer le bon contrôle. Testez séparément certificat expiré, autorité inconnue et nom incorrect. Un message générique de connexion échouée ne suffit pas à choisir la bonne réparation ou à démontrer chaque frontière.

Redirection

Une redirection peut demander une nouvelle validation de destination. Chaque connexion doit rejoindre le pair attendu. Une redirection vers une autre destination ouvre une nouvelle connexion et une nouvelle décision de confiance. Réévaluez aussi la politique SSRF et les credentials transmis au lieu de suivre aveuglément la cible.

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

Destination : https://api-b.example.test
Certificat valide, SAN : DNS:api-a.example.test
Vérification de nom : activée

La chaîne du certificat est supposée valide mais son SAN ne désigne pas la destination attendue. Identifiez précisément cette différence puis proposez un certificat ou une URL conforme au contrat. Le fait de désactiver le contrôle de nom ferait disparaître le symptôme en supprimant la garantie recherchée.

La validation du nom complète celle du chemin. Le client ne doit pas réécrire sa confiance vers le nom reçu. Aucun format de corps ne décide de la validation TLS. Le nom attendu n’est pas identifié par ce SAN.

Travail pratique : Présentez au client local un certificat approuvé pour service-a.test alors qu’il demande service-b.test.

Critères de correction : Observez le refus de nom avec une chaîne autrement correcte. Corrigez le certificat ou la destination attendue, puis ajoutez un test de non-régression qui conserve toutes les vérifications.

Comprendre le mécanisme

ACME automatise des échanges entre client et autorité pour l’émission de certificats selon des validations de contrôle. Prouver le contrôle d’un domaine ne prouve pas que toute activité commerciale derrière lui est légitime. Un certificat public n’est donc pas une certification professionnelle ni un audit de code. Le client ACME, ses credentials et les mécanismes de challenge font partie du périmètre d’exploitation.

Raisonner et vérifier

Planifiez renouvellement, propagation, rechargement du service et vérification externe du certificat effectivement servi. Un fichier renouvelé sur disque peut ne pas être chargé par le processus exposé. Les credentials DNS doivent être restreints à leur usage lorsque c’est possible. Testez les échecs avec un environnement de test prévu par le fournisseur et une procédure de reprise, sans épuiser les quotas de production.

Cycle automatisé

ACME automatise un cycle d’émission de certificats. Le protocole de certificat a un autre périmètre. ACME orchestre demande, contrôle et émission selon un protocole. L’automatisation réduit les opérations manuelles mais doit encore gérer stockage des clés, installation et erreurs des dépendances utilisées pour le challenge.

Portée du domaine

Un contrôle de domaine ne prouve pas la légitimité commerciale. Le type de preuve est plus limité. Un contrôle de domaine établit une capacité sur ce domaine dans le périmètre de l’émission. Il ne certifie pas le code de paiement, la qualité du service ou l’absence de fraude commerciale.

Chargement effectif

Le certificat installé doit être réellement chargé. Le processus peut continuer à utiliser l’ancien état. Après émission, le processus doit charger le nouveau certificat. Vérifiez le résultat du rechargement et les différents nœuds ; un fichier neuf sur disque ne modifie pas magiquement toutes les connexions servies.

Observation externe

Une vérification externe observe le service exposé. Les instances peuvent présenter des certificats différents. Comparez numéro de série et échéance vus depuis un client avec les valeurs attendues. Cette mesure détecte aussi un ancien certificat présenté par un proxy situé avant le service que vous venez de modifier.

Droits DNS

Les credentials DNS doivent être limités. Le périmètre de capacité doit être minimal. Un token DNS peut permettre des changements étendus dans la zone. Restreignez ses permissions au besoin de renouvellement lorsque possible et séparez les environnements pour limiter les conséquences d’une fuite.

Surveillance

Les renouvellements doivent être surveillés. Réseau, permissions et rechargement peuvent tomber en panne. Alertez sur échec de renouvellement et sur échéance du service réellement exposé. Une tâche cron réussie ne prouve pas que tous les certificats nécessaires ont été renouvelés et déployés.

Environnement de test

Un environnement de test évite des essais risqués sur les quotas réels. Le laboratoire doit limiter les impacts. Utilisez le staging de l’autorité pour les répétitions de configuration. Il permet de tester le cycle sans épuiser les quotas réels ; sa confiance doit rester distincte de celle du service public.

Reprise opérable

La procédure de reprise doit avoir un propriétaire. L’exploitation demande une capacité d’intervention. Assignez un responsable et documentez les accès nécessaires, la réparation et les contrôles de validation après incident. Une alerte sans personne capable d’agir peut laisser expirer un certificat pourtant surveillé correctement.

Challenge maîtrisé

Le challenge doit rester dans un périmètre maîtrisé. Le contrôle de domaine doit suivre les règles de validation. Vérifiez quel composant sert le challenge et quels chemins ou zones il peut modifier. La délégation nécessaire à l’émission ne doit pas devenir une capacité générale d’écriture dans l’application.

Certifications distinctes

Un certificat technique n’est pas un diplôme professionnel. Les deux notions de certification ont des objets différents. Un certificat TLS est un objet technique de confiance de canal. Une certification professionnelle évalue des compétences selon un programme et des règles propres ; aucun des deux ne remplace l’autre.

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

fichier_installe:
  serial: new-42
service_observe_depuis_client:
  serial: old-11
rechargement:
  status: failed

Le fichier annonce new-42 alors que le client observe old-11 et que le rechargement a échoué. Le renouvellement n’est donc pas terminé du point de vue du service. Réparez le chargement puis contrôlez de nouveau depuis l’extérieur, y compris les autres nœuds exposés.

Ce contrôle ne porte pas sur le certificat actif. Un statut applicatif ne montre pas le numéro de certificat. Le service continue de présenter l’ancienne version malgré le fichier neuf. Le disque ne prouve pas le chargement du processus.

Travail pratique : Simulez un renouvellement local dont le rechargement échoue et écrivez une alerte distinguant disque et service.

Critères de correction : Mesurez le certificat réellement servi et sa date. Déclenchez l’alerte puis restaurez le rechargement ; documentez propriétaire, délai d’intervention et traitement des credentials de challenge.

Comprendre le mécanisme

Une clé a un propriétaire, un usage, un périmètre, une période d’activité et un mode de stockage. Séparez environnements et finalités ; une clé de signature ne doit pas devenir un secret universel. Rotation normale, compromission, restauration et destruction ont des objectifs différents. Changer la valeur ne suffit pas si les anciennes copies, sauvegardes et consommateurs restent inconnus.

Raisonner et vérifier

Pour préparer une évaluation professionnelle de développement sécurisé, constituez un dossier qui explique les décisions et leurs preuves : inventaire, menace, exigences, tests et incident simulé. Ce travail complète la révision des domaines publics d’une certification ; il ne remplace pas ses conditions officielles. Les preuves techniques doivent être expurgées et reproductibles, sans clés privées dans les supports de formation.

Inventaire et propriétaire

Une clé doit avoir un propriétaire et un usage. La gouvernance fait partie du cycle de secret. Enregistrez finalité, détenteurs, environnement, date de création et procédure de retrait. Une clé sans propriétaire rend difficiles la rotation, l’investigation d’incident et la justification de son maintien.

Séparation

Séparer les environnements limite l’impact d’un incident. La réutilisation élargit le périmètre affecté. Utilisez des clés distinctes entre test et production, ainsi qu’entre fonctions qui n’exigent pas de partage. La compromission d’un environnement de démonstration ne doit pas permettre de signer des demandes de production.

Compromission

Rotation normale et compromission ont des objectifs distincts. Le risque peut exiger un retrait plus rapide. Une rotation planifiée peut accepter une période de chevauchement. Une clé compromise peut demander un rejet immédiat et une révocation ; la politique doit annoncer le délai et les effets sur les clients.

Copies connues

Les copies et sauvegardes doivent être inventoriées. D’autres stockages et consommateurs peuvent conserver l’ancienne clé. Inventoriez coffre, variables CI, fichiers, images de conteneur et sauvegardes. Changer la valeur active ne retire pas les anciennes copies ni les capacités déjà distribuées aux consommateurs.

Restauration

Une restauration ne doit pas réintroduire un secret retiré. Le cycle de retrait doit rester cohérent après reprise. Testez une restauration ancienne avec la procédure actuelle de secrets. Elle doit récupérer la configuration admise sans réintroduire une clé révoquée simplement parce qu’elle figurait dans une sauvegarde historique.

Conservation

La destruction demande une politique de conservation. Les besoins et risques de copie doivent être maîtrisés. Définissez quand garder ou détruire une ancienne clé selon son usage. Une clé de déchiffrement nécessaire à des archives et une clé de signature compromise posent des besoins différents.

Preuves expurgées

Les preuves d’exercice doivent être expurgées. La décision et les tests suffisent sans capacité réelle. Un dossier peut montrer identifiants, versions et résultats de test sans révéler les secrets. Vérifiez captures, archives et rapports avant partage ; une preuve de sécurité ne doit pas créer une nouvelle fuite.

Limites du dossier

Un dossier doit annoncer ses limites. La connaissance et l’assurance d’implémentation diffèrent. Indiquez les consommateurs et environnements effectivement vérifiés. Une rotation testée sur un service ne démontre pas le retrait chez tous les partenaires ou dans toutes les copies historiques.

Délai de retrait

Le délai de retrait doit être observé chez les consommateurs. La propagation doit être vérifiée. Mesurez quand chaque vérificateur cesse d’accepter l’ancienne clé. Les caches et processus longs peuvent retarder la décision ; définissez un mécanisme d’invalidation compatible avec le délai requis.

Finalité conservée

Les clés doivent rester liées à leur finalité. Les protocoles et risques demandent une séparation adaptée. Une clé ne doit pas être réutilisée pour résoudre un besoin sans rapport simplement parce qu’elle est déjà disponible. La séparation des usages aide à raisonner sur les capacités et à limiter l’impact des incidents.

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

emission:
  active_key: K2
validation:
  accepted_keys: [K1, K2]
incident:
  compromised_key: K1
  required_action: reject_K1

La configuration émet avec K2 mais accepte encore K1 alors que l’incident exige son rejet. Testez un objet signé par K1 et vérifiez le refus sur chaque consommateur. La nouvelle clé active ne suffit pas à prouver que l’ancienne capacité a disparu du système.

Le nom ne définit pas les clés acceptées. La configuration de validation contredit l’action requise. Changer l’émission ne retire pas la capacité admise côté réception. Aucune donnée ne démontre une compromission de K2.

Travail pratique : Réalisez un exercice de compromission fictive : identifiez les consommateurs, remplacez une clé de test et mesurez le délai de retrait.

Critères de correction : Vérifiez que les anciens usages sont refusés selon la politique et que la restauration ne réintroduit pas un secret retiré. Joignez les limites du test et reliez les décisions aux compétences du parcours.

PCI DSS côté marchand : ne pas retenir le CVV après autorisation

Dans le cas marchand posé, le CVV appartient aux données d’authentification sensibles. Sa conservation après autorisation est interdite, y compris sous forme chiffrée. Un besoin de support ou de paiement ultérieur ne transforme pas cette rétention en usage admissible.

Concevez la collecte pour qu’elle ne laisse pas de copie durable dans base, queue, logs, traces ou exports. Un champ retiré de la table principale peut encore subsister dans une capture automatique de requête. Vérifiez donc le chemin complet avec des données factices.

Les paiements futurs doivent utiliser l’intégration et les références du prestataire prévues pour ce besoin, sans conserver le CVV comme raccourci. La revue d’un système réel doit préciser son périmètre et les responsabilités applicables ; cet atelier enseigne la règle ciblée du cas présenté, sans prétendre réaliser à lui seul une évaluation PCI complète.

Points de vigilance : Le chiffrement n’autorise pas la conservation post-autorisation du CVV dans ce cas marchand. Le CVV est une donnée d’authentification sensible dont la rétention post-autorisation est interdite ici. Le consentement du client ne crée pas cette exception PCI DSS. La localisation géographique ne lève pas l’interdiction.

Clé PSP exposée : retirer la capacité et examiner les usages

Une clé committée puis intégrée à une image déployée doit être traitée comme compromise. Supprimer la ligne du dernier commit ne retire ni l’historique, ni les couches, ni les copies déjà tirées, et ne change pas la capacité chez le prestataire.

Déclenchez la procédure d’incident : confinement, révocation ou rotation selon les capacités PSP, investigation des usages et vérification des opérations. Distribuez une nouvelle clé par un mécanisme contrôlé et vérifiez les consommateurs réels. Distinguez la continuité de service nécessaire d’un maintien indéfini de l’ancienne clé.

Remplacez les artefacts et corrigez la chaîne de build pour éviter une nouvelle exposition. Inventoriez caches, logs et sauvegardes selon la procédure de traitement ; le nettoyage de visibilité est complémentaire au retrait de la capacité. Un exercice avec clé factice doit démontrer que l’ancienne valeur est refusée et que les services autorisés utilisent la nouvelle sans la recopier dans des images ou diagnostics.

Points de vigilance : Les copies et l’historique peuvent toujours contenir une clé active. La réécriture Git ne révoque pas la clé et ne supprime pas les images déjà distribuées. Changer l’emplacement ne change pas le fait que la clé est connue d’un tiers potentiel. L’incident nécessite confinement, rotation contrôlée, vérification des opérations et prévention des nouvelles fuites.