Stocker les mots de passe en toute sécurité
Comment une application doit-elle conserver les mots de passe de ses utilisateurs ? La réponse (hachage, sel, poivre, itérations) fait toute la différence entre une fuite anodine et une catastrophe le jour où la base est dérobée.
Pourquoi ne jamais stocker en clair ?
Conserver les mots de passe « en clair » est la pire des pratiques : le jour où la base fuite, tous les comptes sont immédiatement compromis, et, par effet de réutilisation, souvent bien au-delà de votre service. Or les fuites de bases de données sont fréquentes, ne serait-ce que via une injection SQL.
L'objectif d'un bon stockage : faire en sorte que, même si la base est volée, les mots de passe restent très coûteux à retrouver. C'est un pilier de la lutte contre le vol de compte et un marqueur de sérieux de toute application.
Les briques d'un stockage robuste
Le hachage
On ne stocke jamais le mot de passe, mais son empreinte (hash) via une fonction à sens unique, impossible à « inverser » directement.
Le sel (salt)
Une valeur aléatoire unique par mot de passe, qui empêche les attaques par tables précalculées (rainbow tables).
Le poivre (pepper)
Un secret commun, stocké séparément de la base, qui ajoute une barrière supplémentaire en cas de fuite de la base seule.
Les itérations (coût)
Répéter le calcul rend chaque tentative de cassage lente et coûteuse, décourageant les attaques par force brute.
Toutes les fonctions de hachage ne se valent pas
Un hachage « rapide » (conçu pour la vitesse) est justement ce qu'il ne faut pas pour des mots de passe : il permet à l'attaquant de tester des milliards de combinaisons par seconde. On privilégie des fonctions dédiées, lentes et paramétrables, conçues pour résister au cassage et adaptables dans le temps à mesure que le matériel progresse. Le choix et le réglage de cette fonction sont au cœur d'une démarche de sécurité applicative.
Au-delà du stockage
Bien stocker les mots de passe est nécessaire, mais s'inscrit dans un ensemble : une politique de mots de passe robustes (longueur avant tout), la double authentification (MFA) pour que le mot de passe ne soit pas l'unique rempart, une limitation des tentatives (rate limiting), et la surveillance des fuites connues. Autant de mesures complémentaires détaillées dans notre page sur le vol de compte.
Sécuriser le stockage, étape par étape
Bannir le clair (et le chiffrement réversible)
Ne jamais stocker un mot de passe en clair ni de façon simplement déchiffrable.
Choisir une fonction dédiée
Utiliser une fonction de hachage de mots de passe lente et éprouvée, et non un hash « rapide ».
Saler chaque mot de passe
Générer un sel aléatoire unique par utilisateur, stocké avec l'empreinte.
Régler le coût
Calibrer le nombre d'itérations pour rester lent à casser, sans dégrader l'expérience.
Ajouter un poivre
Conserver un secret séparé de la base pour renforcer la protection en cas de fuite isolée.
Compléter par la MFA
Déployer la double authentification pour que le mot de passe ne soit jamais l'unique barrière.
Pourquoi se faire accompagner par BCIT ?
Un audit des pratiques
Lors d'un test d'intrusion, nous vérifions comment vos applications stockent et protègent réellement les secrets.
Des choix techniques sûrs
Fonction, sel, poivre, coût : nous vous orientons vers des réglages robustes et durables.
Une approche d'ensemble
Du stockage à la protection des comptes, nous couvrons toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Vos mots de passe résisteraient-ils à une fuite ?
Prenons 15 minutes pour auditer la façon dont vos applications stockent les mots de passe et renforcer la protection des comptes.
Stocker les mots de passe en toute sécurité
Comment une application doit-elle conserver les mots de passe de ses utilisateurs ? La réponse (hachage, sel, poivre, itérations) fait toute la différence entre une fuite anodine et une catastrophe le jour où la base est dérobée.
Pourquoi ne jamais stocker en clair ?
Conserver les mots de passe « en clair » est la pire des pratiques : le jour où la base fuite, tous les comptes sont immédiatement compromis, et, par effet de réutilisation, souvent bien au-delà de votre service. Or les fuites de bases de données sont fréquentes, ne serait-ce que via une injection SQL.
L'objectif d'un bon stockage : faire en sorte que, même si la base est volée, les mots de passe restent très coûteux à retrouver. C'est un pilier de la lutte contre le vol de compte et un marqueur de sérieux de toute application.
Les briques d'un stockage robuste
Le hachage
On ne stocke jamais le mot de passe, mais son empreinte (hash) via une fonction à sens unique, impossible à « inverser » directement.
Le sel (salt)
Une valeur aléatoire unique par mot de passe, qui empêche les attaques par tables précalculées (rainbow tables).
Le poivre (pepper)
Un secret commun, stocké séparément de la base, qui ajoute une barrière supplémentaire en cas de fuite de la base seule.
Les itérations (coût)
Répéter le calcul rend chaque tentative de cassage lente et coûteuse, décourageant les attaques par force brute.
Toutes les fonctions de hachage ne se valent pas
Un hachage « rapide » (conçu pour la vitesse) est justement ce qu'il ne faut pas pour des mots de passe : il permet à l'attaquant de tester des milliards de combinaisons par seconde. On privilégie des fonctions dédiées, lentes et paramétrables, conçues pour résister au cassage et adaptables dans le temps à mesure que le matériel progresse. Le choix et le réglage de cette fonction sont au cœur d'une démarche de sécurité applicative.
Au-delà du stockage
Bien stocker les mots de passe est nécessaire, mais s'inscrit dans un ensemble : une politique de mots de passe robustes (longueur avant tout), la double authentification (MFA) pour que le mot de passe ne soit pas l'unique rempart, une limitation des tentatives (rate limiting), et la surveillance des fuites connues. Autant de mesures complémentaires détaillées dans notre page sur le vol de compte.
Sécuriser le stockage, étape par étape
Bannir le clair (et le chiffrement réversible)
Ne jamais stocker un mot de passe en clair ni de façon simplement déchiffrable.
Choisir une fonction dédiée
Utiliser une fonction de hachage de mots de passe lente et éprouvée, et non un hash « rapide ».
Saler chaque mot de passe
Générer un sel aléatoire unique par utilisateur, stocké avec l'empreinte.
Régler le coût
Calibrer le nombre d'itérations pour rester lent à casser, sans dégrader l'expérience.
Ajouter un poivre
Conserver un secret séparé de la base pour renforcer la protection en cas de fuite isolée.
Compléter par la MFA
Déployer la double authentification pour que le mot de passe ne soit jamais l'unique barrière.
Pourquoi se faire accompagner par BCIT ?
Un audit des pratiques
Lors d'un test d'intrusion, nous vérifions comment vos applications stockent et protègent réellement les secrets.
Des choix techniques sûrs
Fonction, sel, poivre, coût : nous vous orientons vers des réglages robustes et durables.
Une approche d'ensemble
Du stockage à la protection des comptes, nous couvrons toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Vos mots de passe résisteraient-ils à une fuite ?
Prenons 15 minutes pour auditer la façon dont vos applications stockent les mots de passe et renforcer la protection des comptes.