Pourquoi PHP crypt() ajouter le sel à la table de hachage?

Je suis à la recherche dans la construction d'un système de connexion et après avoir lu le manuel php lorsque vous passez à 2 chiffres de sel à la crypt() la fonction retourne une chaîne de hash, et les 2 premiers chiffres de la chaîne sont le sel que vous avez utilisé.

exemple:

$salt = "kr";
echo crypt("mysecret",$salt); //returns "kreOI.F7eOQMY"

Ma première pensée a été, ne serait-ce pas aider quelqu'un qui est en train d'essayer d'inverser votre hash?

J'ai regardé sel sur wikipédia qui dit:

Pour une sécurité optimale, le sel de la valeur est gardée secrète.

Donc je ne comprends pas pourquoi la fonction crypt (), le retour de tous les hachages de préfixer avec le sel de la valeur utilisée?

Est-il une raison pour cela? Cela devrait-il être un problème de sécurité?

C'est pourquoi je vous recommande deux sel de la partie. L'un dans un fichier de config qui est secret, mais la même pour tous les utilisateurs, et une partie enregistrée ensemble avec le mot de passe qui est différent pour chaque utilisateur/généré de façon aléatoire.
en fait, je suis en train de mettre à niveau un que j'ai hérité.
Wikipédia ne doit pas être pris comme parole d'évangile. Les sels ne sont pas secrètes.

OriginalL'auteur JD Isaacks | 2011-01-26

  1. 1

    La fonction crypt() est obsolète. Il a été utilisé pour le hachage des mots de passe pour les anciens de style Unix systèmes, avant d'ombre de mot de passe. Le sel était là pour augmenter la complexité de brute forcer le mot de passe. Cependant, car le sel a été généré de façon aléatoire par le mot de passe de sous-système, il a dû être stockés en clair, toute le mot de passe d'actions permettraient de travailler. Si le sel a été intégrée dans le mot de passe de cryptage, il n'y aurait pas de moyen pratique pour vérifier un mot de passe que vous avez à essayer tous les possibles de sel à chaque fois qu'un mot a été fait - très peu pratique. Donc, le sel a été ajouté à la crypté mot de passe, de sorte que vous pourriez tirer de nouveau pour une utilisation future.

    crypted password: xxabcdefghijklmn
                  ^^- salt
                    ^^^^^^^^^^^^^^-- crypted pw

if ('xx' + crypt('xx' + password) == 'crypted string') then
     password is ok
endif

    Ces jours-ci, crypt() est la sécurité de l'équivalent d'une boîte de céréales anneau de décodeur. Il y à des fins historiques, de faible et de la sécurité "qui se soucie si il est fissuré dans" stockage. Pour toute moderne du mot de passe d'utilisation, vous seriez mieux avec plus modernes de tables de hachage, comme sha1 et sha256/md5. Et même md5 est considéré comme rompu à ces jours, sha1 a des fissures sur les bords, et (le dernier que j'ai vérifié) sha256 est toujours sécurisé.

    Cela a un sens, donc, si je devais déjà avoir une base de données complète des utilisateurs avec des mots de passe hachés stockées. Est-il de toute façon pour moi de les convertir à autre chose, sha256, ou devrais-je "convertir" la prochaine fois que l'utilisateur se connecte? puisque de toute évidence je pourrais avoir le mot de passe brut à l'époque. Merci.
    Le sel est pas pour augmenter la force brute de la complexité. Il est là pour empêcher l'espace-temps du trade-off d'un arc-en-ciel de la table.
    crypt() n'est pas "obsolète", certainement le plus âgé DES hachages sont de valeur douteuse à ce point, mais le MD5, Blowfish et (dans de nouveaux PHPs) SHA-fondé de hachages fonctionnent très bien pour moderne hachage de mot de passe.
    La manière dont j'ai géré le problème de la conversion est simplement de hachage hachage. Il ajoute une étape à la vérification du mot de passe, mais c'est négligeable. J'ai lu les mathématiques suggèrent que cela pourrait augmenter le risque d'une collision, mais pas de manière significative et même ainsi, les collisions ne sont pas mon vrai souci dans un mécanisme d'authentification. et @TML - Pourquoi défendre crypt()? Tout le monde peut simplement déplacer et d'utiliser bcrypt et nous allons tous être mieux pour elle.
    SHA* et les sels sont les pommes et les bananes. SHA* sans sel est pire que tout ancien algorithme avec le sel. En tant que tel, ce n'est pas vraiment répondre à la question.

    OriginalL'auteur Marc B

  2. 29

    L'auteur de l'article de Wikipédia est l'amalgame entre le sel avec l'idée de l'espace de recherche, ce qui implique le sel est un moyen de dissuader les attaques par force brute. La sécurité n'est pas améliorée par la confusion de ces idées; quelqu'un qui ne peut pas reconnaître et de délimiter ces deux questions n'est pas crédible guide.

    Le but de sel est de contrecarrer les pré-calculé des tables de recherche (comme un arc-en-ciel de la table). Le sel empêche un attaquant de la négociation d'un "espace" pour "les temps". Tous les bits de sel double des besoins de stockage pour une table; un de deux octets de sel fait une grosse (65536 fois) différence, mais huit octets nécessiterait inexistante "yottabyte" périphériques de stockage pour les tables de recherche.

    Le sel doit être stockée quelque part. Si vous aviez un moyen efficace de maintenir un "secret", pourquoi ne pas l'utiliser pour stocker le mot de passe et oublier de hachage en tout? Non; si vous voulez vraiment de la sécurité, vous avez besoin pour concevoir le système à l'abri d'une attaque par force brute, même si l'attaquant sait que le sel. L'article de la présomption que le sel peut être gardé secret doivent être traités comme des faux.

    Les attaques par force Brute sont les meilleurs empêché par la clé de renforcement (en appliquant la fonction de hachage des milliers de fois), et le mot de passe des règles de sélection (un minimum de longueur, chiffres, caractères spéciaux).

    En supposant que le sel ne peut pas être gardé secret encourage une meilleure clé-le renforcement et la sélection du mot de passe, ce qui conduit à plus de sécuriser le système.

    Voir une réponse de here.

    OriginalL'auteur erickson

  3. 9

    Je devrais commenter cette Crypte n'est pas aussi mauvais que Marc B rend le son, et peut en fait être la façon la plus simple de bonne hache, aussi longtemps que vous ne comptez pas sur ses plus faibles régimes tels que MD5.

    Voir:

    Comment utilisez-vous bcrypt pour le hachage des mots de passe en PHP?

    http://uk.php.net/manual/en/function.crypt.php

    http://www.openwall.com/phpass/

    OriginalL'auteur nucc1

  4. 3

    Oui, le sel est censé rester secret, mais alors il en est le hachage de mot de passe. Il est parfaitement acceptable pour qu'elles restent tout aussi secret au même endroit. Pour vérifier un mot de passe contre la table de hachage, vous devez combiner le sel avec le mot de passe, puis de la comparer à la valeur de hachage. Ainsi, un utilisateur ou un processus avec le droit de voir le hachage de mot de passe doivent également avoir le droit de voir le sel, car le hachage de mot de passe en lui-même n'est pas utile pour la vérification des mots de passe (sauf si vous allez à la force brute du sel).

    Le but de le sel de sorte que si deux utilisateurs ont le même mot de passe, ils vous hachage à des choses différentes. Cela signifie également que les attaques par dictionnaire sont beaucoup plus complexes parce que vous ne pouvez pas simplement de hachage probablement tous les mots de passe et ensuite de les vérifier par rapport à une liste d'utilisateur, des mots de passe pour rechercher plusieurs mots de passe utilisateur. Au lieu de cela, vous devez essayer les mots de passe pour un individu de sel de trouver un mot de passe utilisateur ou d'essayer toutes les combinaisons de chances de mots de passe avec plusieurs sels afin de trouver des hits. Mais la connaissance de la sel, par lui-même, ne signifie pas que vous pouvez inverser le hachage de mot de passe. Il signifie simplement que vous pouvez faire une attaque de dictionnaire sur le hachage de mot de passe.

    Si vous pouvez trouver un moyen de garder le sel de plus sûr que la valeur de hachage, il a certainement ne serait pas une mauvaise chose, mais il est difficile de voir comment cela est possible quand tout programme qui a besoin d'accéder à un besoin de l'accès à la fois.

    OriginalL'auteur Keith Irwin

  5. 1

    Le sel est ajouté à l'est de sorte que vous savez ce qui le sel à utiliser lorsque vous obtenez le mot de passe et que vous voulez voir si elle correspond à la valeur de hachage. L'idée ici est d'utiliser un autre sel pour chaque mot de passe afin que personne ne peut précalculer une table de hachage.

    Vous pouvez également ajouter un second sel pour chaque mot de passe (le même pour tous) et ne parler à personne de ce qu'il est.

    OriginalL'auteur Joseph Stine

  6. 1

    PHP crypte hérite de ce comportement de la UNIX crypt() fonction, qui a été utilisé pour générer des mots de passe UNIX passwd fichier. Il est nécessaire de stocker le sel quelque part, ou vous ne pouvez pas vérifier plus tard que le mot de passe est correct. Pour le passwd fichier, le simple comportement était juste d'ajouter le sel (toujours deux caractères) pour le début de la crypté mot de passe, ce qui le rend simple à ranger dans un seul champ.

    La déclaration que le sel de valeur doit être tenu secret, est ouverte à la confusion. Pour une meilleure pratique, vous ne devriez pas publier votre sels, de la même manière que vous ne devriez pas publier vos mots de passe. Donnant un attaquant les hachages et les sels rend facile pour eux pour exécuter une attaque par force brute, sans générer de trafic suspect de votre système. Toutefois, le système doit encore être sûr, même si un attaquant peut voir à la fois le sel et le mot de passe haché.

    En fait, il n'y a nulle part vous peut stocker la valeur de hachage qui ne pouvait pas, en principe, être compromise par un hacker exactement de la même manière que les mots de passe hachés. Si le mot de passe-code de vérification peut y accéder, vous devez supposer que quelqu'un qui aurait compromis le système pourrait y avoir accès.

    OriginalL'auteur Tim Martin