Sécuriser l'authentification applicative

1. Pourquoi soigner l’authentification

Une application qui gère ses propres comptes est responsable de tout ce qui les protège : stockage des mots de passe, session, essais répétés, oubli du mot de passe, droits. Une seule erreur suffit à ouvrir la porte. Ce chapitre construit chaque maillon, code PHP à l’appui.

Mardi 20 octobre 2026. Anaïs Lecoq, responsable du pôle développement de Vellacor, confie à Sarah Cherif, alternante SLAM, l’audit de l’authentification de KerMaint, l’application de maintenance des bâtiments de Kervanet (ticket VEL-2026-4498). Deux raisons à cette demande :

KerMaint a ses propres comptes (table utilisateur, B3SLAM-02), indépendants de l’annuaire. Sarah relève l’existant : empreintes produites depuis 2022 par password_hash() avec le réglage par défaut de PHP (bcrypt, coût 10) ; session expirant après 4 heures d’inactivité depuis le 12 octobre (B1-06) ; ni limitation des essais, ni second facteur, ni procédure de mot de passe oublié ; droits contrôlés page par page, de façon inégale. Ses tests sont faits sur la machine de laboratoire LAB-UBU01 (Ubuntu 24.04 LTS, PHP 8.3), avec une copie fictive des tables dans SQLite.