04. Hash adaptatif et budget de calcul

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.