05. Vérification et migration après succès

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é.