Authentification moderne : mots de passe, MFA et passkeys, ce qui protège vraiment vos utilisateurs

Lorsqu'une application est compromise, l'attaque ne passe pas toujours par une faille technique sophistiquée. Très souvent, l'attaquant se contente de se connecter avec des identifiants volés, devinés ou obtenus par hameçonnage. L'authentification est donc l'un des premiers remparts de votre application, et l'un des plus exposés.

Cet article présente les pratiques que nous considérons aujourd'hui comme indispensables, des fondamentaux aux approches les plus récentes.

Comprendre les menaces

• Le hameçonnage (phishing) : un faux site ou un faux message incite l'utilisateur à saisir ses identifiants.
• Le bourrage d'identifiants (credential stuffing) : des robots testent massivement des couples e-mail / mot de passe issus de fuites d'autres sites, en misant sur la réutilisation des mots de passe.
• Les attaques par force brute : tentatives répétées sur un même compte.
• Le vol de session : l'attaquant récupère un jeton de session valide et n'a plus besoin du mot de passe.

Stocker les mots de passe correctement

Un mot de passe ne doit jamais être stocké en clair, ni chiffré de manière réversible, ni haché avec un algorithme rapide comme MD5 ou SHA-1. Il doit être haché avec un algorithme conçu pour être lent et résistant aux attaques matérielles : Argon2id en priorité, ou bcrypt.

En PHP, les fonctions natives gèrent automatiquement le sel et les paramètres :

// Inscription
$hash = password_hash($motDePasse, PASSWORD_ARGON2ID);

// Connexion
if (password_verify($saisie, $hash)) {
    // Mise à niveau automatique si l'algorithme ou ses paramètres ont évolué
    if (password_needs_rehash($hash, PASSWORD_ARGON2ID)) {
        $nouveauHash = password_hash($saisie, PASSWORD_ARGON2ID);
        // enregistrer $nouveauHash en base
    }
}

Si Argon2 n'est pas disponible sur votre serveur, PASSWORD_DEFAULT (bcrypt) reste un choix sûr.

Une politique de mots de passe qui aide réellement

Les recommandations ont évolué. Les règles de complexité rigides et les changements forcés à intervalle régulier poussent les utilisateurs vers des mots de passe prévisibles. Les recommandations actuelles, notamment celles du NIST américain, privilégient :

• la longueur plutôt que la complexité : accepter et encourager les phrases de passe longues ;
• la vérification contre des listes de mots de passe compromis ou trop courants ;
• l'absence de renouvellement forcé, sauf en cas de suspicion de compromission ;
• la compatibilité avec les gestionnaires de mots de passe : autoriser le copier-coller et les longs mots de passe.

La double authentification (MFA)

Ajouter un second facteur est la mesure la plus efficace contre le vol d'identifiants. Toutes les méthodes n'offrent cependant pas le même niveau de protection :

Pour les comptes à privilèges (administrateurs, comptabilité, accès aux données sensibles), la double authentification doit être obligatoire.

Les passkeys : vers la fin du mot de passe

Les passkeys reposent sur les standards FIDO2 et WebAuthn, pris en charge par les principaux systèmes d'exploitation et navigateurs. Lors de l'inscription, l'appareil de l'utilisateur crée une paire de clés : la clé privée reste sur l'appareil, protégée par l'empreinte digitale, la reconnaissance faciale ou le code de déverrouillage ; le serveur ne conserve que la clé publique.

Les avantages sont considérables :

• aucun secret à voler côté serveur : une fuite de la base de données n'expose aucun mot de passe ;
• résistance native au hameçonnage : la clé est liée au domaine du site et ne fonctionne pas sur une imitation ;
• une connexion plus rapide pour l'utilisateur, sans saisie.

Nous recommandons de proposer les passkeys en complément du mot de passe dans un premier temps, puis d'encourager progressivement leur adoption.

Sécuriser les sessions

Une authentification robuste ne sert à rien si la session qui suit est mal protégée :

• Cookies de session avec les attributs HttpOnly, Secure et SameSite.
• Régénération de l'identifiant de session après la connexion, pour empêcher la fixation de session.
• Expiration après une période d'inactivité, plus courte pour les espaces sensibles.
• Possibilité pour l'utilisateur de voir ses sessions actives et de les révoquer.
• Pour les API utilisant des jetons (JWT), durée de vie courte, jetons de rafraîchissement révocables, et vérification systématique de la signature et de l'algorithme.
• Réauthentification demandée avant les actions critiques : changement d'e-mail, de mot de passe ou de coordonnées bancaires.

Résister aux attaques automatisées

• Limitation du débit des tentatives de connexion, par compte et par adresse IP.
• Ralentissement progressif après plusieurs échecs, plutôt qu'un blocage définitif qui permettrait à un attaquant de verrouiller des comptes légitimes.
• Messages d'erreur neutres : « identifiants incorrects », sans préciser si l'e-mail existe.
• Détection des connexions inhabituelles : nouvel appareil, nouveau pays, et notification à l'utilisateur.

Centraliser et limiter les accès

Dans les organisations qui utilisent plusieurs applications, l'authentification unique (SSO) basée sur les standards OpenID Connect ou SAML simplifie la vie des utilisateurs et renforce la sécurité : un départ de collaborateur se traite en un seul endroit. Côté autorisations, appliquez le principe du moindre privilège : chaque rôle ne dispose que des droits strictement nécessaires, et ces droits sont revus régulièrement.

Liste de contrôle

• Mots de passe hachés avec Argon2id ou bcrypt.
• Vérification contre les mots de passe compromis, longueur minimale suffisante.
• Double authentification disponible pour tous, obligatoire pour les comptes sensibles.
• Passkeys proposées.
• Cookies de session sécurisés, régénération à la connexion, expiration.
• Limitation des tentatives et messages d'erreur neutres.
• Journalisation des connexions et alertes en cas d'activité suspecte.
• Revue périodique des droits d'accès.

Ces mesures sont intégrées dès la conception de chacune de nos applications. Si vous souhaitez évaluer le niveau de sécurité d'une application existante, un audit ciblé sur l'authentification et les accès est souvent un excellent point de départ.