L'utilisation du nom d'utilisateur chiffré avec le mot de passe comme clé est-elle un bon schéma de stockage de mot de passe?
Sur les applications Web que je crée, je ne hache pas les mots de passe. Au lieu de cela, je crypte symétriquement le nom d'utilisateur en utilisant le mot de passe de l'utilisateur et stocke le résultat dans le champ du mot de passe. J'utilise RijndaelManaged sur dotnet.
Lors de la connexion, je le fais à nouveau et vérifie s'il y a une correspondance.
Ma question est, comment est-ce sécurisé maintenant quand de plus en plus de bases de données sont piratées? Je ne connais à aucun moment le vrai mot de passe de l'utilisateur. Ce que le pirate obtiendrait de db, c'est le nom d'utilisateur chiffré avec un mot de passe inconnu. Avec le hachage, il y a le problème des tables Rainbow, mais pas avec cette méthode.
Connaître déjà la valeur déchiffrée (nom d'utilisateur) facilite la recherche du mot de passe?
Ce que vous faites vraiment c'est du hachage: vous avez construit une fonction de hachage à partir d'un chiffrement par bloc. Par ailleurs, "le cryptage d'une valeur connue avec le mot de passe comme clé" est la façon dont le traditionnel schéma de cryptage basé sur DES pour Unix a été conçu.
Sur le plan positif, votre construction inclut le nom d'utilisateur, qui fournit partiellement l'effet d'un sel: le craquage parallèle est déconseillé car deux utilisateurs utilisant le même mot de passe se retrouveront avec deux sorties de hachage distinctes. "En partie", car lors du changement de mot de passe, l'utilisateur conserve son nom d'utilisateur, donc une certaine forme de parallélisme est toujours possible ici; et, peut-être plus important encore, le même nom d'utilisateur peut être utilisé dans plusieurs applications Web (par exemple, `` admin ''), ce qui rend les tables précalculées intéressantes (et le but du sel est d'empêcher le parallélisme, en particulier l'utilisation efficace des tables précalculées).
Du côté négatif:
Il s'agit d'une construction faite maison. 50 ans de recherche en cryptographie nous ont appris que la crypto maison est très rarement bonne. En fait, nous pouvons "savoir" qu'un algorithme donné n'est correct que grâce à des années de révision par d'autres chercheurs qualifiés, et les schémas maison, par définition, n'ont jamais reçu beaucoup de révision.
C'est limité. Rijndael est un chiffrement par bloc qui peut accepter des clés jusqu'à 256 bits; ainsi, si vous utilisez le mot de passe comme clé, il doit tenir sur 256 bits. Cela empêche d'utiliser ce que l'on appelle des "mots de passe" qui peuvent être forts mais faciles à mémoriser des mots de passe en utilisant beaucoup d'espace pour son entropie (les cerveaux humains n'aiment pas l'entropie concentrée, mais sont satisfaits de l'entropie diluée).
C'est beaucoup trop rapide, et ceci est le plus gros problème immédiat de votre schéma. Avec un PC de base, un attaquant peut essayer beaucoup de mots de passe par seconde, en particulier depuis que les PC modernes ont opcodes dédiés pour AES. Avec un PC quad-core, on devrait pouvoir essayer jusqu'à environ un demi-milliard de mots de passe par seconde. Peu de mots de passe choisis par l'utilisateur peuvent survivre longtemps à une telle attaque.
Si vous êtes intéressé par le fonctionnement du hachage de mot de passe, lisez this . La réponse courte, cependant, est toujours la même: n'utilisez pas un schéma fait maison; utilisez bcrypt .
Les autres réponses disent déjà No, "roll your own" is rarely a good password storage scheme and yours is no exception.
Je voudrais ajouter: Ce n'est pas non plus un bon schéma pour stocker/communiquer le nom d'utilisateur.
Vous hachez essentiellement. Rien de mal à cela, sauf:
- Vous utilisez une fonction non conçue comme une fonction de hachage sécurisée. Étant un chiffre, il est sûrement sur la fin "sécurisée" de l'échelle, mais le hachage implique également d'éviter les collisions de hachage. Un chiffrement n'est généralement pas optimisé pour ne pas avoir de collision. Les tampons à usage unique sont connus pour être incassables, car ils ont le nombre maximal de collisions. Un chiffrement fort fait donc un mauvais hachage en termes de collisions.
- Si vous stockez un nom d'utilisateur et un nom d'utilisateur chiffré avec mot de passe, il y a plus de vulnérabilités:
- Dans ce cas, si votre base de données est piratée, l'attaquant ne seulement get
the username encrypted with an unknown password. Il obtient également le texte clair aka. Nom d'utilisateur. Il s'agit donc d'une analyse de texte claire, qui pour certains chiffres est beaucoup plus facile que la force brute. - Collisions de hachage: l'attaquant n'a pas besoin de connaître le mot de passe mais n'importe lequel qui produit le même cryptage pour un texte clair court et donné. Cela pourrait être encore plus facile que l'analyse de texte clair.
- Dans ce cas, si votre base de données est piratée, l'attaquant ne seulement get
- Si vous ne stockez pas le nom d'utilisateur mais que vous comptez sur une seule valeur transmise combinée, il y a toujours des inconvénients:
- Dans ce cas, vous n'avez probablement pas envisagé les collisions de hachage. Qu'en est-il de deux utilisateurs, qui ont le même nom d'utilisateur? Qu'en est-il de deux idiots, qui ont le même nom d'utilisateur et le même mot de passe? Qu'en est-il des collisions de hachage de différents noms d'utilisateur et mots de passe par pur hasard (rappelez-vous: les chiffres ne sont pas optimisés pour éviter les collisions!)?
- Dans tous les cas, il y a l'attaque "Passer le hachage": Un attaquant qui renifle la communication réseau peut simplement émuler votre application pour transmettre les mêmes données que l'utilisateur. Avez-vous fait quelque chose à ce sujet? Sinon, c'est pourquoi vous ne devriez pas "rouler le vôtre".
Souvent, le protocole de transmission est aussi important pour la sécurité qu'une fonction cryptographique puissante, indépendante du hachage par rapport au cryptage. Un mauvais protocole peut exposer votre fonction à des attaques pour lesquelles il n'est pas adapté, en particulier les "attaques par canal latéral" comme "passer le hachage" ou "l'homme au milieu" qui contournent la crypto-analyse réelle du côté de l'attaquant.
Votre système de stockage de mot de passe peut être sujet à de telles attaques, car vous n'avez pas spécifié si le nom d'utilisateur est également stocké en texte clair. Cela expose votre schéma aux attaques décrites ci-dessus. Ne pas le stocker en texte clair peut nécessiter un protocole de transmission sujet aux attaques comme décrit ci-dessus.
Voici quelques réflexions supplémentaires sur les protocoles de transmission dans votre cas, légèrement généralisées:
Si vous n'avez rien fait contre l'attaque "passer le hachage", alors votre plan est pire que beaucoup d'autres. Un attaquant n'a pas besoin de pirater votre base de données ni de déchiffrer votre chiffre. Il obtient ce dont il a besoin gratuitement en reniflant le trafic réseau.
HTTPS peut suffire, bien qu'il puisse être contourné par "l'homme au milieu": les utilisateurs ne vérifient pas les certificats d'authentification, n'est-ce pas? Un attaquant ouvre simplement une connexion non authentifiée mais cryptée à votre utilisateur et à la connexion attendue.
Un schéma Challenge-Response supplémentaire peut ajouter de la sécurité. Avant de se connecter, le client reçoit une chaîne aléatoire unique (défi) qu'il doit intégrer dans le hachage (réponse). Un attaquant ne pourrait pas réutiliser un hachage reniflé, car le défi n'est pas non plus réutilisé.
Mais encore une fois, pas besoin de "rouler vous-même".
TL; DR: utilisez scrypt. Pourquoi rouler le vôtre alors qu'il existe un standard parfaitement bon?
(Je considère que scrypt est supérieur à bcrypt, mais bcrypt est toujours bien meilleur que Grow-your-own.)
Une chose qui vous manque jusqu'à présent est l'étirement. Imaginez que vous soyez piraté et que votre base de données soit vidée sur Pastebin - cela peut arriver à le meilleur d'entre nous .
Les personnes qui utilisent 123456 ou l'un des 20 autres mots de passe les plus importants découvriront quoi que vous fassiez, et elles ne méritent pas mieux. Pour les personnes qui ont choisi des mots de passe moyennement bons, cela fait une différence si le temps que l'attaquant doit passer par entrée est de l'ordre des microsecondes ou des secondes.
Vous ne saluez pas non plus - imaginez que deux de vos applications Web soient piratées et qu'une personne possède des comptes sous le même nom d'utilisateur avec le même mot de passe pour les deux. Il me semble que l'attaquant obtiendra des textes chiffrés identiques dans les deux vidages, leur disant qu'il existe une offre crack-one-get-one-free.