07. Comparaison et représentation des secrets

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.