Votre mot de passe n'est pas qu'une simple chaîne : pourquoi l'authentification en C# nécessite une approche particulière
\n\nImaginez : vous avez écrit une application C# parfaite — avec une belle interface, des requêtes rapides et une architecture propre. Mais si l'authentification y est défaillante, tout votre travail est réduit à néant. Les hackers ne forcent pas les portes — ils essaient les clés. Et dans le monde moderne, l'authentification sécurisée en C# n'est pas une option, mais une hygiène de code de base.
\n\nDans cet article, nous aborderons non seulement la théorie, mais aussi des méthodes de protection concrètes : du hachage correct des mots de passe à l'implémentation de JWT et OAuth. Vous découvrirez pourquoi SHA256 sans sel est un danger, comment ne pas tomber dans le piège des attaques par force brute et que faire si votre projet a déjà dépassé les méthodes d'authentification "pour débutants". C'est parti !
\n\nLes trois piliers de la sécurité : hachage, sel et algorithmes lents
\n\nL'anti-patron le plus courant chez les débutants est de stocker les mots de passe en clair ou d'utiliser un simple MD5. Même si vous avez "juste un projet d'apprentissage", l'habitude s'installe. L'authentification sécurisée en C# commence par trois règles :
\n\n- \n
- Ne stockez jamais les mots de passe en texte clair. Même dans une base de données locale. \n
- Utilisez un sel (salt) — une chaîne aléatoire pour chaque utilisateur. \n
- Choisissez des algorithmes lents — BCrypt, PBKDF2, Argon2. \n
Pourquoi "lents" ? Parce qu'un hacker doit essayer des milliards de combinaisons par seconde. Si le hachage prend 0,1 seconde, l'attaque devient économiquement non rentable.
\n\nHachage correct des mots de passe en C# avec BCrypt
\n\nBCrypt est la référence pour les développeurs .NET. Il génère lui-même le sel et l'intègre dans le hachage. Vous n'avez pas besoin de stocker le sel séparément.
\n\nInstallez le package via NuGet :
\nInstall-Package BCrypt.Net-Next\n\nVoici un exemple d'inscription d'utilisateur :
\n\nusing BCrypt.Net;\n\npublic class AuthService\n{\n public string HashPassword(string plainPassword)\n {\n // Work factor = 12 — équilibre optimal entre vitesse et sécurité\n return BCrypt.HashPassword(plainPassword, workFactor: 12);\n }\n\n public bool VerifyPassword(string plainPassword, string hashedPassword)\n {\n return BCrypt.Verify(plainPassword, hashedPassword);\n }\n}\n\n// Utilisation :\nvar auth = new AuthService();\nstring hash = auth.HashPassword("MyS3cur3P@ss!");\nbool isValid = auth.VerifyPassword("MyS3cur3P@ss!", hash); // true\n\nNotez que workFactor (facteur de coût) détermine le nombre d'itérations de hachage effectuées. 12 est une bonne valeur pour 2024. Si votre serveur est puissant, vous pouvez monter à 13-14.
PBKDF2 — un outil intégré à .NET
\n\nSi vous ne voulez pas de bibliothèques externes, utilisez Rfc2898DeriveBytes — l'implémentation intégrée de PBKDF2 dans .NET. Exemple :
using System.Security.Cryptography;\n\npublic static string HashWithPBKDF2(string password, byte[] salt, int iterations = 100_000)\n{\n using var deriveBytes = new Rfc2898DeriveBytes(password, salt, iterations, HashAlgorithmName.SHA256);\n byte[] hash = deriveBytes.GetBytes(32); // 32 octets = 256 bits\n return Convert.ToBase64String(salt) + ":" + Convert.ToBase64String(hash);\n}\n\n// Génération du sel (16 octets)\nbyte[] salt = RandomNumberGenerator.GetBytes(16);\nstring result = HashWithPBKDF2("userPassword", salt);\n\nImportant : n'utilisez pas moins de 100 000 itérations. Les GPU modernes peuvent facilement essayer des millions de hachages par seconde.
\n\nJWT — l'authentification moderne sans sessions
\n\nLorsque votre application C# évolue vers des microservices ou un SPA (React, Vue), stocker les sessions sur le serveur devient peu pratique. Les JSON Web Tokens (JWT) viennent à la rescousse — des jetons d'accès compacts et autonomes.
\n\nL'authentification sécurisée en C# avec JWT repose sur trois principes :
\n- \n
- T