Le temps () est-il un bon sel?

Question

Je suis à la recherche d'un peu de code que je n'ai pas écrit moi-même. Le code tente de hachage d'un mot de passe avec SHA512 et utilise seulement time() comme le sel. Est - time() trop simple de sel pour cela ou est-ce le code de sécurité?

Merci pour les réponses et les commentaires. Je vais résumer ici pour les nouveaux lecteurs:

• le sel doit être différent pour chaque utilisateur, donc si 2 utilisateurs de s'inscrire en même temps, leurs sels de ne pas être unique. C'est un problème, mais pas un gros.
• mais le sel ne devrait pas être en aucune façon liés à l'utilisateur, de sorte que time() n'est pas un bon sel.
• "Utiliser un hasard, uniformément répartie, de haute entropie de sel." -- C'est une bouchée, de sorte que ce code pourrait éventuellement générer un random, evenly distributed, high entropy de sel?

Ok, alors, comment je le remplacer de temps() avec une chaîne aléatoire de 32 char de long. La chaîne aléatoire pourrait être généré à partir de bouclage 32 fois au cours d'un jeu de caractères de l'alphabet. Que c'est bon?

Answer 1

Réponse courte:

Non, time() n'est pas un bon sel.

Réponse longue:

^{copié à partir de ma réponse à Sel de la Génération et de logiciels open source}

Qu'est ce qu'un sel?

Un sel est un hasard ensemble d'octets de longueur fixe qui est ajouté à l'entrée d'un algorithme de hachage.

Pourquoi est-salage (ou semis) un hachage utile?

L'ajout d'un hasard de sel à une table de hachage garantit que le même mot de passe va produire beaucoup de différentes tables de hachage. Le sel est généralement stocké dans la base de données, ainsi que le résultat de la fonction de hachage. Saler un hachage est bon pour un certain nombre de raisons:

1. Saler augmente la difficulté et le coût de l'precomputated attaques (y compris les rainbow tables)
2. Le salage permet de s'assurer que le même mot de passe n'est pas le même hachage. Cela permet de s'assurer que vous ne peut pas déterminer si deux utilisateurs ont le même mot de passe. Et, plus important encore, vous ne pouvez pas déterminer si la personne utilise le même mot de passe sur les différents systèmes.
3. Saler augmente la complexité des mots de passe, augmentant ainsi considérablement la diminution de l'efficacité à la fois un Dictionnaire et d'Anniversaire des attaques. (Ceci n'est vrai que si le sel est entreposés à l'écart de la table de hachage).
4. Bon salage grandement augmente l'espace de stockage nécessaire pour le précalcul des attaques, jusqu'au point où ils ne sont plus pratique. (8 caractères sensibles à la casse alpha-numérique des mots de passe avec 16 bits de sel, de hachage de 128 bits, prendre un peu moins de 200 exaoctets sans arc-en-ciel de réduction).

Il n'est pas nécessaire pour le sel à être secret.

Un sel n'est pas une clé secrète, au lieu d'un sel "œuvres" en faisant de la fonction de hachage spécifiques à chaque instance. Salé de hachage, il n'y a pas une fonction de hachage, mais pour tout le sel de la valeur. Cela empêche l'attaquant de s'attaquer à la N des mots de passe hachés pour les moins de N fois le coût d'attaquer un mot de passe. C'est le point de la le sel.
Un "secret de sel" n'est pas un sel, il est appelé une "clé", et cela signifie que vous n'êtes plus le calcul d'un hash, mais un Code d'Authentification de Message (MAC). Le calcul de MAC est un travail délicat (beaucoup plus difficile que de simplement gifler ensemble d'une clé et d'une valeur dans une fonction de hachage, et il est très différent sujet tout à fait.

Le sel doit être aléatoire pour chaque instance dans lequel il est utilisé. Cela garantit qu'un attaquant n'a pour l'attaque de chaque salé de hachage séparément.
Si vous comptez sur votre sel (ou le salage algorithme) étant secret, vous entrez dans les domaines de la Sécurité Par l'Obscurité (ne fonctionne pas). Très probablement, vous n'obtenez pas de sécurité supplémentaire à partir du sel secret; vous obtenez juste l'ambiance chaleureuse et douillette de la sécurité. Ainsi, au lieu de rendre votre système plus sûr, c'est juste vous distrait de la réalité.

Alors, pourquoi ne le sel être aléatoire?

Techniquement, le sel doit être unique. Le point de la sel doit être distinct pour chaque mot de passe haché. Ceci est fait dans le monde entier. Puisqu'il n'existe pas d'organisme central qui distribue unique de sels sur demande, nous devons compter sur la prochaine meilleure chose, qui est la sélection aléatoire avec une imprévisible générateur aléatoire, de préférence au sein d'un sel de l'espace assez grand pour faire des collisions improbable (deux occurrences à l'aide de la même valeur salt).

Il est tentant d'essayer de tirer un sel de certaines données qui est "sans doute unique", comme l'ID utilisateur, mais ces régimes échouent souvent en raison de certains détails désagréables:

1. Si vous utilisez par exemple l'ID de l'utilisateur, des méchants, attaquer des systèmes distincts, peut tout simplement mettre leurs ressources en commun et de créer des tables précalculées pour l'utilisateur Id de 1 à 50. Un ID d'utilisateur est unique à l'échelle du système , mais pas dans le monde entier.

2. La même chose s'applique pour le nom d'utilisateur: il est une "racine" par le système Unix, mais il y a beaucoup de racines dans le monde. Un arc-en-ciel de la table pour "root" serait en vaut la chandelle, car elle pourrait être appliquée à des millions de systèmes. Pire encore, il y a aussi beaucoup de "bob" là-bas, et beaucoup n'ont pas sysadmin de formation: leurs mots de passe pourrait être assez faible.

3. L'unicité est aussi temporelle. Parfois, les utilisateurs de modifier leur mot de passe. Pour chaque nouveau mot de passe, un nouveau sel doit être sélectionné. Sinon, un attaquant a obtenu le hachage de l'ancien mot de passe et le hachage de la nouvelle pourrait essayer d'attaquer les deux simultanément.

À l'aide d'un hasard sel obtenu à partir d'un point de vue cryptographique sécurisé, imprévisible PRNG peut être une sorte de matraquage, mais au moins il prouvable vous protège contre tous ces dangers. Il n'est pas sur la prévention de l'attaquant de savoir ce qu'est un individu de sel, c'est de ne pas leur donner la grosse cible qui sera utilisé sur un grand nombre de cibles potentielles. La sélection aléatoire rend les cibles aussi mince que possible.

En conclusion:

Utiliser un hasard, uniformément répartie, de haute entropie de sel. L'utilisation d'un nouveau sel chaque fois que vous créez un nouveau mot de passe ou modifier un mot de passe. Stocker le sel avec le mot de passe haché. Faveur gros sels (au moins 10 octets, de préférence de 16 ans ou plus).

Un sel ne tourne pas un mauvais mot de passe dans un bon mot de passe. Il est tout à fait sûr que l'attaquant va au moins payer l'attaque de dictionnaire des prix pour chaque mot de passe incorrect, il rompt.

Utile sources:
stackoverflow.com: Non-aléatoire de sel pour le hachage de mots de passe
Bruce Schneier: Pratique de la Cryptographie (livre)
Matasano de Sécurité: Assez avec les Rainbow Tables
usenix.org: Unix utilisé sel depuis 1976
owasp.org: Pourquoi ajouter du sel
openwall.com: Sels

Avertissement:
Je ne suis pas un expert en sécurité. (Bien que cette réponse a été examiné par Thomas Pornin)
Si l'un des professionnels de la sécurité y trouver quelque chose de mal, s'il vous plaît ne commentaire ou modifier ce wiki réponse.

Comme pour ce qui semble être une bonne source pour votre aléatoires de sel
^{A lire également: Quelle est la plus sûre des semences pour la génération de nombre aléatoire?}
En l'absence d'dédié, matériel, générateurs aléatoires, le meilleur moyen d'obtenir des données aléatoires est de demander au système d'exploitation (Linux, cela s'appelle /dev/random ou /dev/urandom [les deux ont des avantages et des inconvénients, choisissez votre poison]; sur Windows, appel CryptGenRandom())

Si pour quelque raison vous n'avez pas accès à ces sources de hasard, en PHP, vous pouvez utiliser la fonction suivante:
^{À partir de la source de phpass v0.3}

<?php
/**
 * Generate pseudo random bits
 * @copyright: public domain
 * @link http://www.openwall.com/phpass/
 * @param int $length number of bits to generate
 * @return string A string with the hexadecimal number
 * @note don't try to improve this, you will likely just ruin it
 */
function random_bits($entropy) {
    $entropy /= 8;
    $state = uniqid();
    $str = '';
    for ($i = 0; $i < $entropy; $i += 16) {
        $state = md5(microtime().$state);
        $str .= md5($state, true);
    }
    $str = unpack('H*', substr($str, 0, $entropy));
    // for some weird reason, on some machines 32 bits binary data comes out as 65! hex characters!?
    // so, added the substr
    return substr(str_pad($str[1], $entropy*2, '0'), 0, $entropy*2);
}
?>

Answer 2

Mise à jour

Ce n'est pas vraiment un bon sel, mais probablement assez bonne pour vaincre tous les, mais le plus déterminé et plein de ressources attaquants. Les caractéristiques d'un bon sel sont:

• Différents pour chaque utilisateur
• assez longtemps (au moins alphanumérique de 8 caractères) pour faire de la concaténation de sel et (potentiellement faible) mot de passe trop long pour une attaque par force brute.

time() valeurs ne sont pas vraiment assez longtemps, depuis qu'ils ont 10 caractères, mais seulement des chiffres.

Aussi, il arrive parfois que les utilisateurs peuvent obtenir la même valeur lorsqu'ils sont créés dans la même seconde. Mais c'est seulement un problème si vous avez des situations où de nombreux utilisateurs sont automatiquement créés dans la même seconde.

En tout cas, beaucoup plus important que parfait que le sel est à l'aide d'une bonne fonction de hachage, et SHA512 est l'un des meilleurs que nous avons de disponible dès maintenant.

Answer 3

Ce poste peut virer un peu trop loin de l'original de votre question, mais j'espère que vous le trouverez utile;

La sécurité est de renforcer les barrières et d'obstacles; la défense en profondeur. Il n'est pas vraiment sûr de hachage solution, seulement ceux qui sont difficiles à briser. C'est comme mettre un système d'alarme et de verrous de fenêtre dans votre maison, votre site moins attractif pour percer que quelqu'un d'autre.

De sel pour la crypte de l'algorithme n'est qu'une petite partie du problème de sécurité. Un seul sel signifie simplement qu'il y a une chose de moins à comprendre quand d'essayer de casser le mot de passe pour plusieurs utilisateurs. Une faible entropie de sel (tels que l'heure du serveur) le rend un peu plus difficile, et une haute entropie de sel rend plus difficile encore. Laquelle de ces utiliser, et si c'est quelque chose dont vous devez vous préoccuper principalement dépend à la fois de la sensibilité des données vous êtes à la protection, mais aussi ce que les autres mesures de sécurité en place. Un site qui donne juste un personnalisé prévisions météo pour une ville sélectionnée a évidemment moins de données sensibles que celui qui a l'adresse de votre domicile, de la mère nom de jeune fille, date de naissance et d'autres informations qui pourraient être utilisées à des fins d'identification.

Donc, c'est là le hic; un haut niveau d'entropie sel est encore un mauvais sel si c'est facile à obtenir.

Dans le monde réel, le stockage de sel dans la base de données (aléatoire ou non) est probablement moins sûre que l'utilisation d'une constante de sel et de l'enfouir loin de privé yeux dans un fichier inaccessible via le navigateur web. Tout en un unique et de haute entropie de sel est plus difficile à deviner, si vous les avez autorisés à root de se connecter à partir de n'importe quel serveur MySql et le mot de passe à 'mot de passe' il n'a pas vraiment d'importance! Contraste combien il est facile pour le crack de la base de données contre obtenir une connexion valide à votre serveur - qui est peut-être plus difficile de le faire discrètement, comme vous pouvez le mettre fail2ban et une pléthore d'autres vecteurs d'attaque watchers en place en fonction de votre configuration.

Vous pouvez combiner les deux approches, le stockage de l'emplacement d'un fichier contenant un utilisateur spécifique du sel dans la base de données, plutôt que le sel lui-même. Si le fait d'avoir à se fissurer à la fois le système de fichiers et de la base de données est justifiée dépend si la sensibilité des données que vous tentez de protéger les bons de souscription de surcharge.

Une autre alternative, la recommandation d'experts en sécurité pour stocker le nom d'utilisateur dans une base de données distincte (et, idéalement, une technologie différente) pour le mot de passe, et de référence entre les deux à l'aide d'un UUID. E. g. utiliser MySQL et SQLite. Cela signifie que les deux bases de données doivent être craqué (et c'est aussi pourquoi, de descendre de séparer trou de lapin pour le bien d'un exemple, vous ne devez pas stocker les détails de l'utilisateur et les numéros de carte de crédit dans la même base de données, puisque l'un n'est d'aucune utilité sans l'autre).

Notez que des Algorithmes tels que SHA-512 et Blowfish pouvez retourner le sel dans le cadre de leur hachage. Soyez prudent avec ces comme si vous stockez l'complet de hachage de vous donner l'algorithme, ce qui signifie qu'il y a deux chose en moins pour les pirates de la figure (le sel donne aussi loin de l'algorithme).

Assurez-vous d'appliquer des mots de passe forts et les noms d'utilisateur, de sorte que les attaques par dictionnaire ne pourront pas; je sais de dictionnaires pour tous les 6 alphanumériques combinaisons de nom d'utilisateur/ mot de passe entrées pour le MD5 et je pense qu'il ya plus que cela disponible pour toutes sortes d'algorithmes. Avec l'explosion du faible coût de nuage et CPGPU de l'informatique, de la taille et de la complexité des dictionnaires disponibles est sur le point d'exploser.

En fin de compte, de la manière la plus sûre est de ne jamais en programmant générer un sel mais obliger l'utilisateur à entrer avec leur nom d'utilisateur et mot de passe sur une liaison SSL (donc ne peut pas être snooped), mais jamais de les stocker. C'est l'approche adoptée par les sociétés de cartes de crédit; c'est à dire les 3 chiffres CSV clé de sécurité sur votre carte de crédit, vous devez le saisir à chaque fois que vous achetez en ligne, car il ne doit jamais être stocké dans une base de données. Si vous voulez vraiment générer le sel, l'envoyer à eux séparément (par exemple, via SMS ou e-Mail) et les rend toujours les saisir manuellement à chaque fois. Avec cette approche, bien que plus de sécurité, vous devez le contraste entre la complexité contre si les utilisateurs vont tout simplement arrêter d'utiliser le site comme vous l'avez fait, il est trop difficile pour eux d'être dérangé.

Tous les ci-dessus repose toujours sur le fait que vous avez aussi une protection contre le détournement de session, cross-site scripting, etc., etc. Le plus fort du monde algorithme de mot de passe n'est pas pertinent si tout ce que je dois faire est de calculer un valide PHPSESSID pour un utilisateur connecté et la détourner!

Je ne suis pas un expert en sécurité, mais avez lu sur ce autant que j'ai peut raisonnablement le faire. Le fait qu'il ya tellement de nombreux livres sur le sujet indique la taille de la réponse à votre question est vraiment.

Un couple de vraiment grands livres que vous aimeriez essayer que j'ai trouvé le précieux;

Les Vulnérabilités des Applications Web de Détecter, de les Exploiter, de les Prévenir - ISBN-13: 978-1-59749-209-6

La prévention des Attaques Web avec Apache - ISBN-13: 978-0-321-32128-2

Answer 4

Oui.
Il semble qu'un timestamp unix, stockés dans la base de données comme un "Membre depuis le" champ va être décent de sel.

Cependant, le sel est la question la plus négligeable. Il y a beaucoup de choses plus importantes que vous devez faire attention à:

1. Probablement pas un mot de passe, ni de sel ou de l'algorithme de hachage va être la partie la plus faible de votre site. Certains boiteux fichier injection ou XSS ou CSRF est sûrement. Donc, ne pas faire une trop grosse affaire.
   Parler d'une vraie chaîne aléatoire de 32 char longtemps dans la typique d'application du web, c'est comme parler de 32-pouces de porte blindée dans le bois de la grange.

2. En parlant de mots de passe, la plus importante jamais chose est de complexité de mot de passe. Avec les mots de passe faibles pas de sel ni d'algorithme de hachage, même super-ingénieux-incroyable-un dur, susceptible de l'aider. C'est une douleur pour demander à l'utilisateur d'utiliser le mot de passe complexe, mais, sans elle, tout le reste devient un morceau de merde.
   Donc, votre première préoccupation devrait être de complexité de mot de passe. De 12 à 16 caractères de différents cas, y compris les chiffres et la ponctuation est une exigence.

3. Comme pour le sel, je ne vois pas d'avantage à utiliser de temps, comme vous devez le stocker avec d'autres données de l'utilisateur. Vaut mieux utiliser un e-mail - c'est assez aléatoire et que vous l'avez déjà de toute façon. N'oubliez pas de ressasser un mot de passe si l'utilisateur modifie leur e-mail. il semble que unix timstamp va être un décent de sel, pas besoin d'utiliser la messagerie électronique ou tout autre chose.

Mise à jour
Comme je peux le voir, beaucoup de gens toujours pas en mesure d'obtenir le point.
Comme le gars de commentaires, en disant:

Beaucoup d'utilisateurs utilisent des mots de passe faibles (nous devons les éduquer, ou au moins de continuer à essayer), mais cela n'excuse pas; ils méritent toujours une bonne sécurité

Ils le méritent, sans aucun doute. Mais avec les mots de passe faibles de la mission. est. impossible.

Si votre mot de passe est faible, alors que le sel ne va la protéger.

Tandis que le sel n'est pas important de passer un 10 kilo-octets de texte sur le sujet.

Answer 5

Non, time() n'est pas un bon sel

Il est préférable de ne pas réinventer la roue quand il s'agit de l'authentification, mais pour répondre à votre question, non. Le problème avec time():

• C'est prévisible et il est en corrélation avec potentiellement détectable choses. Ces problèmes de le rendre plus facile à croiser différentes haché résultats.
• Il n'y a pas beaucoup de valeurs possibles. Depuis les bits de poids fort de ne pas changer, c'est encore plus étroit de sel qu'il paraît au premier abord.
• L'aide qu'il répète ses erreurs antérieures. Si cette application ont été les premiers à utiliser time() un sel, au moins, il aurait besoin d'une nouvelle attaque.