Les mauvais mots de passe produisent-ils de mauvais hachages salés?
Lorsque vous avez un mot de passe stocké dans une base de données fortement hachée et salée, est-ce vraiment important si le mot de passe utilisateur sous-jacent est faible?
Si vous configurez des fonctionnalités telles que la limitation de la conjecture de connexion et utilisez des captchas pour arrêter la conjecture automatisée, pouvez-vous efficacement compenser un mot de passe faible tel que "password"?
Je suppose que ma question est l'utilisation d'un mot de passe comme "mot de passe" rend le hachage salé plus faible que l'utilisation d'un mot de passe plus long tel que "fish&*n0d1cTionaRYatt@ck "? - Tous les hachages salés sont-ils aussi sécurisés ou cela dépend-il du bon mot de passe?
Les hachages salés sont conçus pour se protéger contre les attaquants pouvant attaquer plusieurs hachages simultanément ou créer des tableaux Rainbow de valeurs de hachage pré-calculées. C'est tout. Ils ne font rien pour améliorer la force sous-jacente du mot de passe lui-même, faible ou fort.
Cela signifie également qu'ils ne sont pas conçus pour se défendre contre les attaques en ligne, ils n'ont donc aucun impact sur la capacité d'un attaquant à manipuler votre formulaire de connexion, où le sel n'est pas pertinent, car un attaquant ne calcule pas directement les hachages, mais saisit les mots de passe candidats sous une forme qui peut être (comme vous l'avez dit) à taux limité ou protégé par un captcha.
Les mots de passe faibles sont faibles. Les mots de passe forts sont forts. Les sels n'affectent en rien cette équation.
Vous devez considérer deux vecteurs d'attaque:
- Attaque en ligne
- Attaque hors ligne
Limiter la conjecture de connexion aide contre les attaques en ligne.
Disons que c'est trois fois, cela signifie qu'un attaquant peut tester TOUS les comptes pour les trois mots de passe les plus courants qui correspondent à votre politique de mot de passe (que diriez-vous de "mot de passe", "12345678" et "12345"?).
Le salage aide contre les attaques hors ligne
Les mêmes hachages non salés sont le même mot de passe en texte clair. Chaque hachage doit donc être calculé une fois, pas une fois pour chaque sel. Même avec un sel, l'attaquant peut toujours essayer une attaque par dictionnaire, et personne (sauf sa limite de puissance de calcul) ne l'arrêtera, car votre règle des "trois coups" ne s'appliquera pas ici.
Les mots de passe faibles réduisent la sécurité dans les deux cas
Attaque en ligne : Si vous autorisez les mots de passe courants (comme "mot de passe" ou "12345"), les attaquants pourront pénétrer en 5 % de vos comptes en trois hypothèses.
Attaque hors ligne : Ici, ils essaieront également les mots de passe les plus courants en premier, bien sûr. Donc s'ils calculent 3 hachages par utilisateur, ils ont déjà cassé 5% des comptes ...
Le salage/hachage est idéal si votre base de données est volée, mais cela n'a rien à voir avec les attaques par dictionnaire qui pourraient avoir lieu via la procédure de connexion normale.
Comme vous l'avez mentionné, la limitation du nombre de tentatives de connexion et l'utilisation de CAPTCHA peuvent rendre les attaques par dictionnaire qui ont lieu via la procédure de connexion normale inefficaces, mais le salage (ou non) n'aura aucun effet sur ce type d'attaque.
Même avec les tentatives de connexion limitées et CAPTCHA en place, autoriser des mots de passe super faibles n'est pas une bonne idée, et si un utilisateur malveillant est suffisamment déterminé ou voit suffisamment de valeur, il peut trouver des moyens d'exploiter cette faiblesse.
Non, un point de hachage salé est d'obtenir un bon caractère aléatoire dans le hachage quel que soit le matériau de départ.
Cependant, cela ne nous libère pas de l'utilisation de mauvais mots de passe. Un bon hachage ne protège que contre un seul vecteur d'attaque: celui où l'intrus vole le fichier avec les hachages. Il existe tellement d'autres vecteurs d'attaque sur les mots de passe ... surf sur l'épaule, forçage brutal, forçage brutal modifié (avec des hypothèses de démarrage intelligentes, etc.) ... que les bons mots de passe sont toujours importants.
Le hachage salé protégera les bons mots de passe mais ne vous sauvera pas des mauvais.
Généralement, la chose la plus importante est la longueur du mot de passe. Mais il est vrai qu'un mot de passe simple pourrait être décomposé plus facilement qu'un mot de passe aléatoire. Par exemple, lorsque vous essayez de deviner un hachage en utilisant Rainbow tables . S'il s'agit d'un mot normalement utilisé comme "chat", il est plus probable que vous puissiez l'avoir dans ce tableau que "07OFmy3HOY3l9e1gCNww7nNpd5lQ8I9an"; D
En théorie:
Si l'attaquant n'a pas construit de table Rainbow, si un mot de passe d'une certaine force peut être piraté en 1 unité de temps, alors N mots de passe de cette force peuvent être piratés en O(1) fois sans sel et O(N) fois avec du sel. C'est ce que fait le sel. Aucun avantage sur un mot de passe fixe; montre l'avantage sur plusieurs mots de passe.
Si l'attaquant a une table Rainbow, sans sel, un mot de passe faible - dans ce cas "faible" signifie "déjà dans la table Rainbow" - est aussi bon que nu. Avec du sel, il faudra encore le craquer en quelques secondes.
En pratique: la force du mot de passe est bien plus importante que tout cela. Parfois, les tables Rainbow sont simplement pratiques; si vous avez un million de mots de passe aussi faibles, ils sont perméables, même salés.
Si vous avez choisi l'un des trois mots de passe faibles "amour", "chien" et "vache", et qu'une base de données de mots de passe a été perdue: Sans sels, je peux essayer ces trois mots de passe et trouver immédiatement tout le monde dans le base de données entière utilisant ces trois mots de passe faibles. Avec le salage, je dois essayer l'amour + votre sel, votre chien + votre sel, votre vache + votre sel à casser votre mot de passe s'il était ridiculement faible, puis répéter la même chose avec tout le monde dans la base de données.
Si un pirate vous attaque spécifiquement, le salage n'aide pas. Il aide uniquement en rendant impossible d'attaquer la base de données entière, exigeant plutôt une attaque contre chaque utilisateur individuel dans la base de données.