Mots de passe hachés expliqués : sécurité simple des mots de passe pour fondateurs

Pourquoi la sécurité des mots de passe devient votre problème

Si vous gérez une application avec des comptes, vous êtes dans le business des mots de passe. Dès que vous collectez un mot de passe, vous détenez quelque chose que les attaquants veulent et que les utilisateurs s'attendent à ce que vous protégiez.

Les petites applications se font attaquer aussi. Des bots scannent l'internet en continu pour des cibles faciles : bases de données exposées, configurations admin faibles, variables d'environnement fuitées ou logs de debug qui ont accidentellement capturé des données sensibles. Être en phase early-stage ne veut pas dire être plus sûr. En général, cela signifie moins de monde pour remarquer un problème rapidement, et moins d'heures pour le réparer.

Si des mots de passe fuient, les dégâts dépassent votre appli. Les gens réutilisent des mots de passe, donc une fuite peut mener à des compromissions d'email, de comptes bancaires et d'autres services. Vous pouvez aussi perdre la confiance du public du jour au lendemain, subir des rétrofacturations et passer des semaines à nettoyer au lieu de construire.

L'objectif est simple : vous ne devriez jamais pouvoir lire le mot de passe d'un utilisateur. Ni dans votre base de données, ni dans un tableau d'admin, ni dans un ticket de support, ni dans un email. C'est pourquoi les applications stockent des mots de passe hachés : une version unidirectionnelle qu'on peut vérifier lors de la connexion mais qu'on ne peut pas reconvertir en mot de passe original.

La gestion des mots de passe tourne souvent mal de façons très ordinaires :

• Stocker des mots de passe en clair, même « temporairement » lors de l'inscription
• Envoyer des mots de passe par email aux utilisateurs ou à votre équipe pour le support
• Logger des requêtes d'inscription ou de connexion (avec les mots de passe) pendant le debug
• Copier des mots de passe dans des outils d'analytics, des tableurs ou des messages de chat
• Livrer un prototype généré par IA qui « fonctionne » mais saute les protections de base

Un scénario courant : un fondateur teste un prototype construit par IA et demande aux utilisateurs de « répondre avec le mot de passe utilisé » quand la connexion échoue. Même si vous supprimez l'email ensuite, il peut rester dans des boîtes de réception, des sauvegardes et des outils de support. La correction consiste généralement à reconstruire le flux d'auth pour que les mots de passe ne quittent jamais l'endroit approprié.

Des équipes comme FixMyMess observent souvent ce schéma dans des builds précipités. Le gain le plus rapide est de supprimer chaque chemin où un mot de passe pourrait être consulté, copié ou rejoué.

Ce que signifie « mots de passe hachés » en clair

Un mot de passe haché, c'est ce que vous obtenez quand vous passez un mot de passe dans une fonction spéciale qui le transforme en une longue chaîne d'apparence aléatoire. Pensez-y comme mettre des ingrédients dans un blender et obtenir un smoothie. On peut comparer des smoothies, mais on ne peut pas ressortir les fraises entières.

Donc quand on dit « nous stockons des mots de passe hachés », ça signifie que la base de données garde le smoothie, pas les ingrédients.

Ce qui est enregistré est généralement un enregistrement qui inclut la sortie du hash, la méthode utilisée et un peu d'aléa ajouté pendant le hachage (souvent stocké à côté).

Le hashing est volontairement unidirectionnel. Si quelqu'un vole votre base de données, il ne devrait pas pouvoir inverser les valeurs stockées en mots de passe réels. Même vous, en tant que propriétaire de l'application, ne devriez pas pouvoir lire les mots de passe utilisateur.

C'est aussi pourquoi l'envoi de mots de passe par email est un signal d'alerte sérieux. Si vous pouvez l'envoyer, c'est que vous l'avez quelque part en clair.

Comment la connexion fonctionne-t-elle si vous ne stockez pas le mot de passe ? Quand un utilisateur se connecte, votre application hache le mot de passe qu'il a tapé en utilisant la même méthode, puis compare ce résultat au hash stocké.

S'ils correspondent, le mot de passe est correct. Sinon, l'accès est refusé. Personne n'a besoin de « retrouver » le mot de passe.

Si vous avez hérité d'une application générée par IA qui stocke les mots de passe en clair ou les envoie par email lors de l'inscription, c'est généralement rapide à corriger et enlève un énorme risque avant le lancement.

Hachage vs chiffrement vs encodage (comparaison rapide)

Les gens confondent parce que tous « transforment » des données. Mais ils sont conçus pour des usages différents, et les mots de passe ont une règle claire : on ne doit pas pouvoir récupérer le mot de passe original à partir de ce qu'on stocke.

Le hachage est unidirectionnel. Le chiffrement est réversible. L'encodage est juste un changement de format.

• Hachage : transforme un mot de passe en une chaîne qu'on ne peut pas renverser. Lors de la connexion, vous hachez ce que tape l'utilisateur et comparez au hash stocké.
• Chiffrement : brouille des données de façon réversible avec une clé. Si un attaquant obtient la clé, il peut déchiffrer les données.
• Encodage (Base64, encodage d'URL, etc.) : rend les données plus faciles à stocker ou transmettre. N'importe qui peut décoder. Cela n'apporte aucune sécurité.

Si votre système dit « nous pouvons déchiffrer plus tard », c'est le mauvais modèle pour les mots de passe. La capacité à déchiffrer devient une responsabilité et un point de défaillance.

Où le chiffrement reste utile

Le chiffrement est important, mais pas pour stocker les mots de passe. Utilisez-le pour des éléments que votre appli doit relire plus tard, comme des clés API, des tokens d'accès, des données utilisateur sensibles, des sauvegardes et les données en transit entre systèmes.

Un test simple : si votre appli envoie aux utilisateurs « votre mot de passe est… », cela signifie que vous l'avez stocké de façon réversible quelque part. Corrigez-le avant le lancement. Un système correct ne connaît jamais le mot de passe original après l'inscription.

Comment l'inscription et la connexion devraient fonctionner (pas à pas)

Un système de connexion sécurisé revient à une règle : votre appli ne devrait jamais avoir besoin de se souvenir du mot de passe réel de l'utilisateur après l'instant où il le tape.

Flux d'inscription et de connexion (version sûre)

La plupart des applications modernes suivent un schéma ennuyeusement fiable :

• Inscription : l'utilisateur saisit un mot de passe, votre serveur le hache, et vous ne stockez que le hash.
• Connexion : l'utilisateur saisit un mot de passe, votre serveur hache ce qu'il a tapé de la même façon, puis compare au hash stocké.
• Résultat : si les hashes correspondent, la connexion réussit. Sinon, elle échoue. Rien n'est déchiffré.

Gardez les messages d'erreur génériques. Évitez de dire « email introuvable » vs « mot de passe incorrect » car cela aide les attaquants à deviner quels comptes existent.

Ce qui ne doit jamais apparaître dans les logs ou l'analytics

Beaucoup de violations commencent par des logs « utiles ». Ne consignez pas de secrets. Cela inclut les mots de passe, les password hashes, les tokens de réinitialisation, les magic links, les tokens de session, les en-têtes d'auth et les corps de requêtes complets des endpoints d'auth.

Après une connexion réussie, vous ne devriez plus continuer à envoyer le mot de passe. Le serveur doit créer un token de session (une chaîne aléatoire qui prouve que l'utilisateur s'est déjà authentifié) et le renvoyer à l'application. L'application utilise ce token pour les requêtes futures.

Si vous avez hérité d'un code d'auth généré par IA, vérifiez qu'il suit exactement ce flux. Il est courant de trouver des mots de passe loggés, stockés en clair ou envoyés à des outils d'analytics « pour le debug ». Ce sont des corrections à haut risque mais souvent rapides à faire.

Choisir la bonne méthode de hachage pour les mots de passe

Si votre base de données fuit, les attaquants ne doivent pas pouvoir transformer rapidement des hashes volés en mots de passe réels.

L'idée clé est le « hachage lent ». Un bon hash de mot de passe est volontairement coûteux à calculer. Votre serveur vérifie une connexion à la fois. Un attaquant essaie des milliards de suppositions. Le hachage lent pénalise beaucoup plus l'attaquant que vous.

Bonnes options (et pourquoi elles sont courantes)

La plupart des équipes choisissent une méthode de hachage bien connue :

• Argon2id : un choix moderne conçu pour être difficile à attaquer avec des GPU.
• bcrypt : plus ancien, largement utilisé et bien compris.
• scrypt : également memory-hard et une option raisonnable quand Argon2 n'est pas disponible.

Si vous n'êtes pas expert en sécurité, une valeur par défaut sensée est : choisissez Argon2id si c'est disponible, sinon bcrypt. Commencez avec les paramètres recommandés de la bibliothèque et ne les ajustez que si vous avez une raison claire.

Pourquoi SHA-256 est un mauvais choix par défaut pour les mots de passe

Les fonctions de hachage généralistes comme SHA-256 sont conçues pour être rapides. C'est bien pour des checksums et des signatures, mais dangereux pour les mots de passe. Les hachages rapides permettent aux attaquants de tester un grand nombre de suppositions par seconde. Même si vous « hachez deux fois », c'est généralement encore trop rapide.

Une règle pratique : ne réinventez pas la roue. Utilisez une bibliothèque d'auth bien connue ou une fonctionnalité éprouvée du framework.

Salts et peppers sans le jargon

Si vous ne retenez qu'une chose sur les mots de passe hachés, retenez ceci : le même mot de passe ne doit pas produire la même valeur stockée pour chaque utilisateur.

Salt : un « extra » unique par utilisateur

Un salt est une valeur aléatoire générée pour chaque compte quand le mot de passe est défini. Le système mélange le salt avec le mot de passe avant de hacher, puis stocke le salt à côté du hash.

Ceci compte en cas de fuite de base : sans salts, deux utilisateurs ayant choisi « Summer2026! » obtiendraient le même hash. Les attaquants repèrent les répétitions et devinent plus vite les mots de passe communs.

Avec des salts uniques, même si 1 000 personnes réutilisent le même mot de passe, leurs hashes stockés paraissent tous différents.

Pepper : un secret hors de la base de données

Un pepper est une autre valeur mélangée avant le hachage, mais contrairement au salt, elle n'est pas stockée dans la base de données. Elle vit dans la configuration serveur pour rester secrète même si la base est exposée.

Les peppers n'ont d'intérêt que si vous pouvez protéger et faire pivoter correctement vos secrets applicatifs. C'est une couche supplémentaire, pas un substitut aux fondamentaux.

Une checklist simple pour fondateurs :

• Le salt doit être aléatoire et unique par utilisateur, généré automatiquement.
• Le salt peut être stocké dans la base de données avec le hash.
• Le pepper, si utilisé, doit être stocké hors de la base et traité comme un secret à haute valeur.

Un problème courant dans le code d'auth généré par IA est un « salt » codé en dur partagé par tous les utilisateurs. Ça ressemble à du salage, mais ça annule l'effet recherché.

Erreurs courantes qui créent une dette de sécurité instantanée

La plupart des catastrophes autour des mots de passe ne sont pas de la « magie de hacker ». Elles commencent par des raccourcis pendant un build précipité, puis s'enracinent dans le produit et les habitudes de support.

Le plus gros signal d'alerte est le stockage des mots de passe en clair n'importe où : base de données, tableurs, panels admin, notes ou tables « temporaires ». Si quelqu'un peut les lire, ils finiront par fuir.

Une autre erreur courante est l'envoi de mots de passe par email ou DM, même si vous les appelez temporaires. Les boîtes mail sont transférées, partagées et synchronisées sur des appareils. Cela habitue aussi les utilisateurs à accepter des messages risqués qui semblent venir de votre marque.

Le debugging peut discrètement créer le même problème. Si votre appli logge les corps de requêtes complets pendant l'inscription ou la connexion, vous pouvez sauvegarder des mots de passe dans des logs serveurs, des outils analytics, des rapports de crash ou des tickets de support. Ces systèmes ont souvent un accès large dans l'équipe.

Les patterns qui créent rapidement de la dette : stockage lisible des mots de passe, fonctionnalités « admin peut voir le mot de passe », affichage des mots de passe dans les logs pendant les tests, copier des mots de passe dans des chats de support, ou demander aux utilisateurs d'envoyer leur mot de passe « pour vérifier ».

Une règle simple aide : votre appli ne devrait jamais pouvoir afficher le mot de passe original d'un utilisateur, car elle ne devrait stocker que des mots de passe hachés.

Si vous devez aider un utilisateur, privilégiez des outils de support qui ne nécessitent pas d'accès au mot de passe : liens de réinitialisation, logs et tickets rédigés, actions comme révoquer des sessions ou renvoyer une réinitialisation.

Réinitialisations et protections basiques qui fonctionnent vraiment

Un flux « mot de passe oublié » ne consiste pas à renvoyer l'ancien mot de passe. Avec des mots de passe hachés, le serveur ne peut que vérifier un mot de passe, pas le récupérer.

Une réinitialisation sûre utilise un token à usage unique et limité dans le temps. L'utilisateur prouve qu'il contrôle l'email (ou le téléphone) lié au compte, puis définit un nouveau mot de passe.

Un flux standard ressemble à ceci :

• L'utilisateur saisit son email et demande une réinitialisation.
• Votre appli génère un token aléatoire, ne stocke qu'une version hachée de ce token et fixe une expiration (par exemple 15–60 minutes).
• Vous envoyez un message de réinitialisation contenant le token.
• Quand l'utilisateur l'ouvre, vous vérifiez le token et l'expiration, puis vous lui permettez de définir un nouveau mot de passe.
• Vous invalidez le token après usage et, optionnellement, déconnectez les autres sessions.

Ne divulguez pas si un compte existe. Montrez toujours le même message, par exemple : « Si un compte existe pour cet email, vous recevrez un lien de réinitialisation. » Cela empêche les attaques d'énumération de comptes.

Des protections basiques n'ont pas besoin d'être sophistiquées pour être efficaces. Le rate limiting, de courtes verrouillages après plusieurs échecs, des alertes utilisateur pour réinitialisations ou nouvelles connexions, et l'expiration des sessions après une réinitialisation empêchent beaucoup d'abus.

Dans les applications générées par IA, un bug courant est un token qui n'expire jamais, peut être réutilisé ou est loggé en clair. De petites corrections ici peuvent prévenir un incident majeur.

Exemple réaliste : corriger un système d'auth cassé avant le lancement

Un fondateur solo livre une appli générée par IA avec un formulaire de connexion qui « fonctionne ». En coulisses, la table de la base a une colonne password contenant le texte exact du mot de passe. L'appli envoie même le mot de passe par email lors de l'inscription « pour que les utilisateurs n'oublient pas ». Ça semble utile, mais c'est dangereux.

Le risque apparaît de façons banales. Un utilisateur demande au support « Pouvez-vous me dire mon mot de passe ? » Quelqu'un ouvre un panneau admin et voit des mots de passe en clair. Ou un snapshot de la base est partagé avec un prestataire, et soudain plus de gens ont accès aux vrais mots de passe. Parfois c'est pire : des mots de passe apparaissent dans les logs serveurs pendant le debug.

La solution n'est pas de « cacher la colonne ». La solution est de passer aux mots de passe hachés pour que le système ne stocke qu'une empreinte unidirectionnelle du mot de passe. Concrètement, cela signifie ajouter un champ password_hash, mettre à jour l'inscription pour hacher avant de sauvegarder, mettre à jour la connexion pour vérifier le hash, supprimer tout code qui envoie des mots de passe par email, et nettoyer les logs qui pourraient en contenir.

Gérer les utilisateurs existants est la partie délicate. La plupart des équipes choisissent une de ces options :

• Réinitialisation forcée : marquer tous les comptes comme devant être réinitialisés, envoyer un lien de réinitialisation et refuser les anciens mots de passe.
• Migration progressive : garder le champ ancien temporairement, puis quand un utilisateur se connecte avec succès, le remplacer par un hash et supprimer le mot de passe en clair.
• Hybride : forcer la réinitialisation pour les admins et comptes à risque, mettre à niveau les autres lors de la connexion.

Après avoir choisi, testez les parcours utilisateurs réels (inscription, connexion, réinitialisation, déconnexion) et confirmez que rien ne casse.

Un état final sûr ressemble à ceci :

• Aucun mot de passe en clair nulle part (base, logs, vues admin, emails).
• Les nouveaux comptes stockent uniquement des hashes, et la connexion les vérifie en toute sécurité.
• Le flux de réinitialisation fonctionne et ne révèle pas si un email existe.
• Les anciennes données de mot de passe sont supprimées après la migration.
• Des protections basiques sont en place (rate limits, verrouillages et messages d'erreur sûrs).

Checklist rapide avant le lancement

Exécutez ces vérifications une fois avant vos premiers vrais utilisateurs. Elles détectent la plupart des problèmes « on devait corriger ça plus tard », surtout dans des applis construites vite ou avec des outils IA.

• Base de données : confirmez que vous ne stockez que des mots de passe hachés (avec un salt unique). Il ne doit pas y avoir de backup, table « temporaire » ou colonne résiduelle gardant des mots de passe en clair.
• Logs et rapports d'erreur : provoquez volontairement une connexion ratée et une erreur d'inscription, puis inspectez les logs de requêtes et les rapports de crash. Les champs mot de passe doivent être rédigés.
• Réinitialisation de mot de passe : testez le flux complet. Les tokens doivent expirer, être à usage unique et invalidés après le changement de mot de passe.
• Outils admin et support : assurez-vous qu'aucune UI interne ne peut révéler ou exporter des mots de passe. Si un écran support montre « mot de passe actuel », considérez ça comme un bug critique.
• Secrets et clés : scannez votre repo et vos paramètres de déploiement pour des clés API exposées, des URLs de base de données ou des secrets JWT. Ils doivent vivre dans des variables d'environnement, pas dans le code ou des dashboards partagés avec des prestataires.

Une manière pratique de commencer : cherchez dans le code password, reset, token, log et debug. Si vous voyez l'application stocker une valeur de mot de passe, l'envoyer par email ou la logger, traitez-le comme un blocage avant le lancement.

Si l'auth vous semble fragile (réinitialisations cassées, secrets exposés, comportement de session étrange), un audit ciblé peut vous éviter un incident le jour du lancement.

Étapes suivantes si votre appli a été construite vite (ou par IA)

Si votre appli a été montée rapidement, partez du principe que l'auth et la gestion des mots de passe peuvent être erronées jusqu'à preuve du contraire. C'est particulièrement vrai pour le code généré par IA, où il est courant de voir des mots de passe loggés, stockés en clair ou copiés dans des emails lors des tests. Même si vous utilisez déjà des hashes, des erreurs autour des réinitialisations, des sessions et des secrets peuvent toujours mettre les utilisateurs en danger.

Un bon moment pour une revue externe est juste avant d'inviter de vrais utilisateurs, d'activer les paiements ou de lancer sur un domaine public. Un autre déclencheur est du code d'auth confus : plusieurs routes de connexion, crypto maison ou backdoors admin « temporaires » jamais supprimés.

Un audit de sécurité pratique couvre généralement :

• Inscription, connexion, sessions, déconnexion et réinitialisation de mot de passe
• Scan de secrets (clés API, URLs de base, tokens, commits accidentels)
• Durcissement (rate limits, verrouillages, messages d'erreur sûrs, protections CSRF si nécessaire)
• Gestion des données (ce qui est loggé, envoyé par email ou stocké dans l'analytics)
• Une liste de corrections courte, classée par risque et effort

Si vous avez hérité d'un prototype généré par IA, FixMyMess à fixmymess.ai se concentre sur le diagnostic du code et la correction de problèmes comme le stockage non sécurisé des mots de passe, les secrets exposés et les flux d'auth fragiles pour rendre l'application prête pour la production.

Les délais peuvent être plus courts que vous ne le pensez. Beaucoup de projets peuvent être diagnostiqués et corrigés en 48–72 heures, selon l'entrelacement du code d'auth et la présence de problèmes cachés comme des secrets exposés ou des contrôles d'autorisation défaillants.

Si vous hésitez entre patcher et reconstruire, appliquez une règle simple : patcher quand la structure de l'app est saine, reconstruire quand les fondations sont instables.

Signes qu'une reconstruction est préférable :

• La logique d'auth est dispersée dans de nombreux fichiers avec des règles incohérentes
• Les flux de réinitialisation sont faits maison et difficiles à comprendre
• Des secrets sont intégrés au frontend ou à l'historique du repo
• Il n'y a pas de séparation claire entre utilisateurs, rôles et permissions
• Les correctifs provoquent des bugs dans des parties non liées de l'application