D'où devraient provenir les valeurs de hachage du sel?

12

Lorsque vous ajoutez des valeurs de sel à une valeur de hachage pour quelque chose comme un mot de passe qui ne peut pas être stocké en texte brut, quel est le meilleur endroit pour obtenir les valeurs de sel? Pour le contexte, supposons qu'il s'agit de mots de passe sur une connexion à une page Web.

Morgan Herlocker
la source
@DevArt, je pensais que c'était mieux adapté ici car cela nécessite une réponse très subjective. Une valeur de sel pourrait être tirée de n'importe où, donc je demande "Où pensez-vous est l'emplacement le plus sûr pour extraire des valeurs de sel: client ou serveur?"
Morgan Herlocker

Réponses:

7

J'ai généralement une colonne created TIMESTAMPdans une table utilisateur afin que je puisse voir quand l'utilisateur s'est inscrit. Je n'aime pas ajouter une colonne supplémentaire pour Salt, donc j'utilise la colonne d'horodatage comme sel:

SHA1(password + created)
Jonas
la source
Je suppose alors que lorsque l'utilisateur se connecte à nouveau, vous tirez la date en fonction du nom d'utilisateur lorsque vous ressaisissez pour vérification?
Morgan Herlocker
1
@Prof: Oui, de la même manière que si vous avez une colonne spécifique pour le sel, donc aucune différence dans cette perspective.
Jonas
7

Est-ce que ça importe?

Le sel sert à deux fins. Cela rend peu pratique l'utilisation de grandes tables de mots de passe pré-hachés ("tables arc-en-ciel") et rend les mots de passe identiques différents dans la liste des hachages. Le fait de rendre les mots de passe identiques différents permet d'éviter un problème où plusieurs personnes utilisent un mot de passe particulier, qui est vraisemblablement un mot de passe commun faible.

Par conséquent, chaque compte doit avoir son propre sel unique, et les sels ne doivent pas être trop prévisibles, dans le sens où il n'y aura pas de groupe de sels susceptibles de se produire. (Si de nombreux sites ont commencé à 1 et comptés, les méchants pourraient construire des tables arc-en-ciel comprenant des sels de faible nombre, par exemple.) Ils ne doivent pas être aléatoires dans un sens autre que généralement imprévisible. Ils ne sont pas plus secrets que le hachage lui-même, ils n'ont donc pas besoin d'être spécifiquement invisibles.

Utilisez n'importe quelle méthode pratique pour générer un sel. S'il y a beaucoup de valeurs de sel potentielles (les premiers systèmes Unix utilisaient fréquemment deux octets, pour un nombre possible de 65536) par rapport au nombre de comptes, l'attribution semi-aléatoire ne donnerait presque jamais un sel en double.

David Thornley
la source
1
J'ai généralement vu le deuxième problème - des mots de passe identiques semblant différents - traités en concaténant le nom d'utilisateur, le sel et le mot de passe et en hachant la chaîne entière. Cela élimine le besoin de générer un sel unique par compte.
Justin Cave
1
@Justin: intéressant, je n'avais jamais vu le nom d'utilisateur utilisé dans le cadre du hachage, mais c'est en effet un bon moyen d'ajouter de l'entropie. J'utiliserais quand même un sel pseudo-aléatoire, simplement parce que cela ne coûte pas cher d'en générer un.
Matthieu M.
2
@Matthieu Avec l'inconvénient de devoir le stocker quelque part, et si les deux côtés d'une transaction en ont besoin, de l'envoyer également. Avec le nom d'utilisateur, les deux parties le savent déjà.
Matthew Frederick
2
@Justin: Dans ce cas, vous utilisez le nom d'utilisateur comme sel. Il répond aux deux objectifs du sel: rendre les tables arc-en-ciel peu pratiques et rendre les mots de passe similaires différents.
David Thornley
@David - Vrai, vous pouvez le voir comme le nom d'utilisateur faisant partie du sel. Je voudrais toujours un sel supplémentaire pour que l'attaquant ne puisse pas utiliser une table arc-en-ciel pour trouver les combinaisons nom d'utilisateur / mot de passe. Sans sel explicite, vous augmentez simplement la taille de la chaîne dont l'attaquant a besoin de la table arc-en-ciel de la longueur du nom d'utilisateur (qui est susceptible d'être court et complètement en minuscules ou complètement en majuscules). Un sel constant est suffisant pour contrecarrer une attaque de table arc-en-ciel à moins que votre site ne soit suffisamment grand pour qu'un attaquant génère une table arc-en-ciel spécifique au site.
Justin Cave
3

Chaque fois que vous souhaitez enregistrer un nouveau mot de passe (enregistrement, réinitialisation du mot de passe, mise à jour du mot de passe), une bonne technique consiste à:

  • générer du nouveau sel
    • utiliser un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé
    • utiliser un sel de taille décente - une bonne valeur est la taille de bloc de l'algorithme de hachage sous-jacent (peut être SHA-256)
  • générer un nouveau jeton de mot de passe
    • créer une fonction hmac à partir de l'algorithme de hachage sous-jacent (peut être SHA-256) en utilisant le sel comme clé hmac
    • for i in (0...65536) { password = hmac(password) }
    • le résultat des applications itérées de la fonction hmac est le jeton de mot de passe
  • stocker le sel et le jeton de mot de passe
    • ne stocke pas le mot de passe d'origine
    • stocker éventuellement l'algorithme de hachage sous-jacent et les étirements pour la découverte
yfeldblum
la source
1

Tirez parti du cadre. Dans .NET, vous pouvez utiliser le RNGCryptoServoiceProvider ...

        // If salt is not specified, generate it on the fly.
        if (saltBytes == null)
        {
            // Define min and max salt sizes.
            int minSaltSize = 4;
            int maxSaltSize = 8;

            // Generate a random number for the size of the salt.
            Random  random = new Random();
            int saltSize = random.Next(minSaltSize, maxSaltSize);

            // Allocate a byte array, which will hold the salt.
            saltBytes = new byte[saltSize];

            // Initialize a random number generator.
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

            // Fill the salt with cryptographically strong byte values.
            rng.GetNonZeroBytes(saltBytes); 
        }

D'autres frameworks devraient avoir des classes similaires que vous pouvez exploiter. Pour obtenir un logiciel aléatoire, il emploie souvent l'utilisateur par rapport Randomà ce qui est mentionné ci-dessus. Le déplacement aléatoire d'une souris dans une zone définie pour fournir du sel est une option utilisée par TrueCrypt. Cela se résume à vos besoins spécifiques et à votre niveau de sécurité; puisque votre sel pourrait être tout simplement !@#$%.

Aaron McIver
la source
1

Vous générez un côté serveur Salt et l'affectez à un compte d'utilisateur lors de sa création. Mieux vaut utiliser une API de génération de cryptographie disponible avec votre framework mais en principe n'importe quelle séquence fera l'affaire.

Habituellement, les choses sont stockées comme ceci:

User
-------------------
ID
Username
PasswordHashWithSalt

Exemple:

PasswordHashWithSalt =

A15CD9652D4F4A3FB61A2A422AEAFDF0DEA4E703 j5d58k4b56s8744q


la source
Attribuez-le en fonction de quoi cependant? Ne doit-il pas provenir d'une valeur qui restera en place pour pouvoir être répliquée lorsque l'utilisateur se reconnectera après sa création?
Morgan Herlocker
Avec «assigner», je veux dire générer un sel par paire nom d'utilisateur / mot de passe (compte) et le stocker dans la base de données. Lorsque vous devez effectuer une connexion, vous utilisez ce sel stocké pour vérifier les choses.
1

Utilisez bcrypt et lisez cet article quant aux hachages normaux seuls n'est pas une protection sérieuse de nos jours.

Pensez à utiliser le protocole de mot de passe de connaissance zéro SDR qui possède de nombreuses bibliothèques opensource et est sans brevet.

Le SDR nécessite du sel et le meilleur endroit pour l'obtenir est le client; chronométrez leurs frappes, mouvements de souris, hachez leurs variables d'environnement, nombres aléatoires, heures de création de fichiers dans leur dossier temporaire, pour faire du sel à leur fin de manière imprévisible loin de votre serveur. SDR prend le sel, un grand premier, le mot de passe utilisateur et génère une clé de vérification. Vous ne stockez pas de mot de passe, il ne quitte jamais leur machine, mais vous pouvez vérifier qu'ils ont le mot de passe qui va avec la clé de vérification et le sel. Il est à l'abri de l'homme au milieu et des attaques de dictionnaire. Cryptez les clés et le sel dans la colonne de la base de données pour être sûr.

simbo1905
la source