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

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.

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)

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.

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

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 !@#$%.

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

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.