Saler votre mot de passe: meilleures pratiques?

Préfixe ou suffixe est sans importance, il s’agit uniquement d’append une certaine entropie et de la longueur au mot de passe.

Vous devriez considérer ces trois choses:

1. Le sel doit être différent pour chaque mot de passe que vous stockez. (Ceci est un malentendu courant.)
2. Utilisez un générateur de nombres aléatoires sécurisé par cryptographie.
3. Choisissez un sel assez long. Pensez au problème de l’anniversaire.

Dave Sherohman a une excellente réponse à une autre question: pourquoi devriez-vous utiliser des sels générés de manière aléatoire au lieu du nom d’un utilisateur (ou d’autres données personnelles)? Si vous suivez ces suggestions, peu importe où vous mettez votre sel.

Je pense que c’est toute la sémantique. Le mettre avant ou après n’a pas d’importance, sauf contre un modèle de menace très spécifique.

Le fait que ce soit là est censé vaincre les tables arc-en-ciel.

Le modèle de menace auquel je faisais allusion serait le scénario où l’adversaire peut avoir des tables arc-en-ciel de sels communs ajoutées / ajoutées au mot de passe. (Dites à la NSA) Vous devinez qu’ils l’ont soit ajouté ou ajouté, mais pas les deux. C’est idiot, et c’est une mauvaise supposition.

Il serait préférable de supposer qu’ils ont la capacité de stocker ces tables arc-en-ciel, mais pas, disons, des tables avec des sels étranges entremêlés au milieu du mot de passe. Dans ce cas étroit, je suppose que ce serait mieux.

Comme je l’ai dit. C’est de la sémantique Choisissez un sel par mot de passe différent, un sel long, et incluez des caractères impairs comme des symboles et des codes ASCII: © ¤¡

La vraie réponse, que personne ne semble avoir abordée, est que les deux ont tort . Si vous implémentez votre propre crypto, peu importe à quel point vous pensez que vous le faites, vous allez faire des erreurs.

HMAC est une meilleure approche, mais même si vous utilisez quelque chose comme SHA-1, vous avez déjà choisi un algorithme qui ne convient pas au hachage de mot de passe en raison de sa conception rapide. Utilisez quelque chose comme bcrypt ou éventuellement scrypt et éliminez entièrement le problème de vos mains.

Oh, et ne pense même pas à comparer les hachages résultants pour l’égalité avec votre langage de programmation ou les utilitaires de comparaison de chaînes de bases de données. Ceux-ci comparent caractère par caractère et court-circuit comme false si un caractère diffère. Ainsi, les attaquants peuvent maintenant utiliser des méthodes statistiques pour essayer de déterminer ce qu’est le hachage, un personnage à la fois.

Cela ne devrait pas faire de différence. Le hash ne sera plus facilement devinable où que vous mettiez le sel. Les collisions par hachage sont à la fois rares et imprévisibles, car elles sont intentionnellement non linéaires. Si cela faisait une différence pour la sécurité, cela suggérerait un problème avec le hachage, pas le salage.

Si vous utilisez un hachage sécurisé sur le plan cryptographique, cela ne devrait pas vous déranger, que ce soit avant ou après la correction; un sharepoint hachage est qu’un seul changement de bit dans les données sources (peu importe où) devrait produire un hachage différent.

Ce qui est important, cependant, c’est d’utiliser des sels longs, de les générer avec un PRNG cryptographique approprié et d’avoir des sels par utilisateur. Stocker les sels par utilisateur dans votre firebase database n’est pas un problème de sécurité, l’utilisation d’un hachage à l’échelle du site est .

Tout d’abord, le terme “table arc-en-ciel” est systématiquement mal utilisé. Une table “arc-en-ciel” n’est qu’un type particulier de table de correspondance, une table qui permet un type particulier de compression de données sur les clés. En échangeant des calculs pour l’espace, une table de consultation qui prendrait 1 000 To peut être compressée mille fois pour pouvoir être stockée sur un lecteur plus petit.

Vous devriez être inquiet au sujet du hachage pour mot de passe des tables de consultation, de l’arc-en-ciel ou autre.

@ onebyone.livejournal.com:

L’attaquant a des «tables arc-en-ciel» consistant non pas en des hachages de mots de dictionnaire, mais à l’état du calcul de hachage juste avant de finaliser le calcul de hachage.

Il pourrait alors être moins coûteux de forcer une entrée de fichier de mot de passe avec du sel de postfixe que du sel de préfixe: pour chaque mot du dictionnaire, vous devez charger l’état, append les octets de sel dans le hachage, puis le finaliser. Avec le sel préfixé, il n’y aurait rien de commun entre les calculs pour chaque mot du dictionnaire.

Pour une fonction de hachage simple qui parsing linéairement à travers la chaîne d’entrée, comme un générateur de congruence linéaire simple, il s’agit d’une attaque pratique. Mais une fonction de hachage cryptographiquement sécurisée est délibérément conçue pour avoir plusieurs tours, chacun utilisant tous les bits de la chaîne d’entrée, de sorte que le calcul de l’état interne juste avant l’ajout du sel n’est pas significatif après le premier tour. Par exemple, SHA-1 a 80 tours.

De plus, les algorithmes de hachage de mot de passe comme PBKDF composent leur fonction de hachage plusieurs fois (il est recommandé d’itérer PBKDF-2 au moins 1 000 fois, chaque itération appliquant SHA-1 deux fois).

BCrypt hash si la plateforme a un fournisseur. J’aime la façon dont vous ne vous souciez pas de la création des sels et vous pouvez les rendre encore plus forts si vous le souhaitez.

Insérer le sel un nombre arbitraire de caractères dans le mot de passe est le cas le moins attendu, et donc le plus «socialement sécurisé», mais ce n’est vraiment pas très significatif dans la mesure où vous utilisez long, unique par mot de passe cordes pour les sels.