Remplacement du mot de passe en texte brut pour l'application

Question

Nous stockons actuellement les mots de passe en texte brut pour une application Web dont nous disposons.

Je continue de préconiser le passage à un hachage de mot de passe, mais un autre développeur a déclaré que ce serait moins sécurisé : davantage de mots de passe pourraient correspondre au hachage et une attaque par dictionnaire/hachage serait plus rapide.

Y a-t-il du vrai dans cet argument ?

Answer 1

Absolument aucun.Mais cela n'a pas d'importance.J'ai déjà posté une réponse similaire :

C'est malheureux, mais les gens, même les programmeurs, sont tout simplement trop émotifs pour se laisser facilement influencer par une dispute.Une fois qu'il a investi dans son poste (et, si vous postez ici, il l'est), vous ne pourrez probablement pas le convaincre uniquement avec des faits.Ce que vous devez faire, c'est inverser la charge de la preuve.Vous devez l’amener à rechercher des données qui, espère-t-il, vous convaincront et, ce faisant, apprendre la vérité.Malheureusement, il bénéficie du statu quo, le chemin est donc difficile.

Answer 2

Depuis Wikipédia

Certains systèmes informatiques stockent les mots de passe des utilisateurs, par rapport auxquels comparer les utilisateurs se connectent aux tentatives, comme ClearText.Si un attaquant a accès à un tel magasin de mots de passe interne, tous les mots de passe et donc tous les comptes d'utilisateurs seront compromis.Si certains utilisateurs utilisent le même mot de passe pour des comptes sur différents systèmes, ceux-ci seront également compromis.

Des systèmes plus sécurisés stockent chaque mot de passe sous un formulaire protégée cryptographiquement, donc l'accès au mot de passe réel sera toujours difficile pour un snooper qui gagne un accès interne au système, tandis que la validation des tentatives d'accès des utilisateurs reste possible.

Une approche commune ne stocke qu'une forme "hachée" du mot de passe en texte clair.Lorsqu'un utilisateur tape dans un mot de passe sur un tel système, le logiciel de gestion de mot de passe passe via un algorithme de hachage cryptographique, et si la valeur de hachage générée à partir de l'entrée de l'utilisateur correspond au hachage stocké dans la base de données de mot de passe, l'utilisateur est autorisé à accéder.La valeur de hachage est créée en appliquant une fonction de hachage cryptographique à une chaîne composée du mot de passe soumis et, généralement, une autre valeur connue sous le nom de sel.Le sel empêche les attaquants de créer une liste de valeurs de hachage pour les mots de passe communs.MD5 et SHA1 sont fréquemment utilisés les fonctions de hachage cryptographique.

Vous pouvez lire beaucoup plus sur le sujet sur cette page.À mon avis, et dans tout ce que j'ai lu et travaillé, le hachage est un meilleur scénario à moins que vous n'utilisiez un très petit algorithme (<256 bits).

Answer 3

Il n'y a absolument aucune excuse pour conserver des mots de passe en texte brut sur l'application Web.Utilisez un algorithme de hachage standard (SHA-1, pas MD5 !) avec une valeur salt, afin que les attaques arc-en-ciel soient impossibles.

Answer 4

Je ne comprends pas comment vos autres développeurs pensent que "plus de mots de passe pourraient correspondre au hachage".

Il existe un argument en faveur d'une « attaque par hachage serait plus rapide », mais seulement si vous ne salez pas les mots de passe au fur et à mesure qu'ils sont hachés.Normalement, les fonctions de hachage vous permettent de fournir un sel qui fait de l'utilisation d'une table de hachage connue une perte de temps.

Personnellement, je dirais « non ».Sur la base de ce qui précède, ainsi que du fait que si vous obtenez d'une manière ou d'une autre une exposition en texte clair, une valeur salée et hachée n'a que peu de valeur pour quelqu'un qui essaie d'entrer.Le hachage offre également l'avantage de donner à tous les mots de passe la même longueur.

c'est-à-dire que si le hachage d'une chaîne aboutit toujours à un hachage de 20 caractères, alors si vous n'avez que le hachage à examiner, vous ne pouvez pas savoir si le mot de passe d'origine était de huit caractères ou seize par exemple.

Answer 5

J'ai rencontré exactement le même problème sur mon lieu de travail.Ce que j'ai fait pour le convaincre que le hachage était plus sécurisé, c'est d'écrire une injection SQL qui renvoyait la liste des utilisateurs et des mots de passe de la section publique de notre site.Cela a été immédiatement signalé comme un problème de sécurité majeur :)

Pour éviter les attaques par dictionnaire/hachage, assurez-vous de hacher un jeton unique à chaque utilisateur et statique (nom d'utilisateur/date d'adhésion/guid d'utilisateur fonctionne bien)

Answer 6

Si vous ne salez pas votre mot de passe, vous êtes suspect d'attaques Rainbow Table (dictionnaires précompilés contenant des entrées valides pour un hachage donné).

L'autre développeur devrait arrêter de parler de sécurité si vous stockez des mots de passe en texte brut et commencer à lire sur la sécurité.

Les collisions sont possibles, mais ne constituent généralement pas un gros problème pour les applications de mot de passe (elles constituent principalement un problème dans les zones où les hachages sont utilisés comme moyen de vérifier l'intégrité des fichiers).

Donc:Salez vos mots de passe (en ajoutant le Salt à droite du mot de passe*) et utilisez un bon algorithme de hachage comme SHA-1 ou de préférence SHA-256 ou SHA-512.

PS :Un peu plus de détails sur les hachages ici.

*Je ne sais pas vraiment si le Salt doit être placé au début ou à la fin de la chaîne.Le problème est que si vous avez une collision (deux entrées avec le même hachage), l'ajout du Salt du "mauvais" côté ne changera pas le hachage résultant.De toute façon, vous n'aurez pas de gros problèmes avec Rainbow Tables, seulement avec les collisions

Answer 7

Il y a un vieux dicton selon lequel les programmeurs se font passer pour des cryptographes :)

Jeff Atwood a un bon article sur le sujet : Vous stockez probablement les mots de passe de manière incorrecte

Pour répondre plus en détail, je suis d'accord avec tout ce qui précède, le hachage facilite les choses en théorie pour obtenir le mot de passe de l'utilisateur puisque plusieurs mots de passe correspondent au même hachage.Cependant, cela est beaucoup moins susceptible de se produire que quelqu'un ayant accès à votre base de données.

Answer 8

Il y a du vrai dans le fait que si vous hachez quelque chose, oui, il y aura des collisions, il sera donc possible que deux mots de passe différents débloquent le même compte.

D'un point de vue pratique cependant, c'est un mauvais argument - une bonne fonction de hachage (md5 ou sha1 conviendrait) peut à peu près garantir que pour toutes les chaînes significatives, en particulier les plus courtes, il n'y aura pas de collisions.Même si c'était le cas, avoir deux mots de passe correspondant pour un seul compte n'est pas un gros problème. Si quelqu'un est en mesure de deviner les mots de passe au hasard assez rapidement pour pouvoir y accéder, vous avez de plus gros problèmes.

Je dirais que le stockage des mots de passe en texte brut représente un risque de sécurité bien plus important que les collisions de hachage lors de la correspondance des mots de passe.

Answer 9

Je ne suis pas un expert en sécurité, mais j'ai le sentiment que si le texte brut était plus sécurisé, le hachage n'existerait pas en premier lieu.

Answer 10

En théorie, oui.Les mots de passe peuvent être plus longs (plus d'informations) qu'un hachage, il existe donc un risque de collision de hachage.Cependant, la plupart des attaques sont basées sur un dictionnaire et la probabilité de collisions est infiniment inférieure à celle d’une correspondance directe réussie.

Answer 11

Cela dépend de ce contre quoi vous vous défendez.S'il s'agit d'un attaquant qui détruit votre base de données (ou incite votre application à afficher la base de données), alors les mots de passe en clair sont inutiles.Il existe de nombreuses attaques qui consistent à convaincre l'application de restituer ses données privées : injection SQL, détournement de session, etc.Il est souvent préférable de ne pas conserver les données du tout, mais de conserver la version hachée afin que les méchants ne puissent pas les utiliser facilement.

Comme le suggère votre collègue, cela peut être évité de manière triviale en exécutant le même algorithme de hachage sur un dictionnaire et en utilisant des tables arc-en-ciel pour extraire les informations.La solution habituelle consiste à utiliser un sel secret ainsi que des informations utilisateur supplémentaires pour rendre les résultats hachés uniques, quelque chose comme :

String hashedPass=CryptUtils.MD5("alsdl;ksahglhkjfsdkjhkjhkfsdlsdf" + user.getCreateDate().toString() +  user.getPassword);

Tant que votre sel est secret ou que votre attaquant ne connaît pas la date précise de création de l'enregistrement de l'utilisateur, une attaque par dictionnaire échouera, même s'il parvient à extraire le champ du mot de passe.

Answer 12

Rien n'est moins sécurisé que le stockage de mots de passe en texte brut.Si vous utilisez un algorithme de hachage décent (au moins SHA-256, mais même SHA-1 vaut mieux que rien), alors oui, des collisions sont possibles, mais cela n'a pas d'importance car étant donné un hachage, il est impossible* de calculer quoi les chaînes sont hachées.Si vous hachez le nom d'utilisateur AVEC le mot de passe, cette possibilité disparaît également.

* - techniquement pas impossible, mais "infaisable sur le plan informatique"

Si le nom d'utilisateur est "graeme" et le mot de passe est "stackoverflow", créez une chaîne "graeme-stackoverflow-1234" où 1234 est un nombre aléatoire, puis hachez-la et stockez "sortie de hachage1234" dans la base de données.Lorsqu'il s'agit de valider un mot de passe, prenez le nom d'utilisateur, le mot de passe fourni et le numéro à la fin de la valeur stockée (le hachage a une longueur fixe, vous pouvez donc toujours le faire) et hachez-les ensemble, puis comparez-le avec le hachage. partie de la valeur stockée.

Answer 13

plus de mots de passe pourraient correspondre au hachage et une attaque par dictionnaire/hachage serait plus rapide.

Oui et non.Utilisez un algorithme de hachage moderne, comme une variante SHA, et cet argument devient très, très hebdomadaire.Avez-vous vraiment besoin de vous inquiéter si cette attaque par force brute ne prend que 352 ans au lieu de 467 ans ?(Blague anecdotique là-bas.) La valeur à gagner (ne pas avoir le mot de passe stocké en texte brut sur le système) dépasse de loin les préoccupations de votre collègue.

Answer 14

J'espère que vous me pardonnerez d'avoir branché une solution que j'ai écrite à ce sujet, en utilisant JavaScript côté client pour hacher le mot de passe avant qu'il ne soit transmis : http://blog.asgeirnilsen.com/2005/11/password-authentication-without.html