Secure hash et du sel pour les mots de passe en PHP

Question

Actuellement, il est dit que MD5 est partiellement dangereux. Compte tenu de cela, je voudrais savoir quel mécanisme utiliser pour la protection par mot de passe.

Cette question, Est "double hachage d'un mot de passe de moins en moins sûre juste hacher à la fois? suggère que le hachage plusieurs fois peut être une bonne idée, alors que la Façon de mettre en œuvre protection par mot de passe pour les fichiers individuels? suggère d'utiliser le sel.

Je suis à l'aide de PHP. Je veux un coffre-fort et rapide de cryptage de mot de passe système. Le hachage d'un mot de passe d'un million de fois peut-être plus sûr, mais aussi plus lents. Comment à obtenir un bon équilibre entre la vitesse et la sécurité? Aussi, je préfère le résultat d'avoir un nombre constant de caractères.

1. Le mécanisme de hachage doit être disponible en PHP
2. Elle doit être sûre
3. On peut utiliser du sel (dans ce cas, tous les sels d'aussi bons? Est-il possible de générer de bons sels?)

Aussi, dois-je conserver les deux champs dans la base de données (à l'aide de MD5 et un autre à l'aide de SHA, par exemple)? Serait-il le rendre plus sûr ou unsafer?

Dans le cas où je n'étais pas assez claire, je veux savoir quelle fonction de hachage(s) à utiliser et la façon de choisir un bon sel afin d'avoir un coffre-fort et rapide mot de passe d'un mécanisme de protection.

Les questions connexes qui ne sont pas tout couvrir ma question:

Quelle est la différence entre SHA, MD5 en PHP
Simple Cryptage De Mot De Passe
Méthodes sécurisées de stockage des clés, des mots de passe pour asp.net
Comment voulez-vous mettre en œuvre salé mots de passe dans Tomcat 5.5

Answer 1

TL;DR

À ne pas faire

• Ne limitez pas les caractères que les utilisateurs peuvent entrer des mots de passe. Seuls les idiots ne ce.
• Ne pas limiter la longueur d'un mot de passe. Si vos utilisateurs veulent une phrase avec "supercalifragilisticexpialidocious" à elle, ne pas les empêcher de l'utiliser.
• Ne rangez jamais votre mot de passe utilisateur en texte clair.
• Jamais e-mail un mot de passe pour l'utilisateur sauf quand ils ont perdu le leur, et vous avez envoyé un temporaire.
• Ne jamais, jamais se connecter mots de passe en toute manière.
• Jamais de hachage des mots de passe avec SHA1 ou MD5 ou même SHA256! Moderne des craquelins peuvent dépasser 60 et 180 milliards de hachages/seconde (respectivement).

Faire

• Utilisation scrypt quand vous le pouvez; bcrypt si vous ne pouvez pas.
• Utilisation PBKDF2 si vous ne pouvez pas utiliser bcrypt ou scrypt, avec SHA2 les tables de hachage.
• Réinitialiser tous les mots de passe lorsque la base de données est compromise.
• Mettre en œuvre une raisonnable de 8 à 10 caractères minimum de longueur, plus besoin d'au moins 1 lettre majuscule, 1 minuscule, un chiffre et un symbole. Cela permettra d'améliorer l'entropie du mot de passe, à son tour, rend plus difficile à craquer. (Voir le "Ce qui fait un bon mot de passe?" pour le débat.)

Pourquoi hachage des mots de passe de toute façon?

L'objectif derrière le hachage des mots de passe est simple: empêcher les malveillants d'accéder à des comptes d'utilisateur par compromettre la base de données. Donc, le but de hachage de mot de passe est de dissuader un hacker ou cracker par leur coûte trop de temps ou d'argent pour calculer la plaine mots de passe en texte. Et le temps/coût sont les meilleurs moyens de dissuasion dans votre arsenal.

Une autre raison pour laquelle vous voulez un bon, solide hachage sur un des comptes d'utilisateur est de vous donner suffisamment de temps pour changer tous les mots de passe dans le système. Si votre base de données est compromise, vous aurez besoin de suffisamment de temps pour au moins verrouiller le système, si ce n'est de changer à chaque mot de passe dans la base de données.

Jeremiah Grossman, CTO de Whitehat Security, a déclaré sur son blog après une récente récupération de mot de passe que requis par la force brute bris de sa protection par mot de passe:

Il est intéressant de noter, en vivant de ce cauchemar, j'ai appris BEAUCOUP de choses que je ne savais pas à propos de craquage de mot de passe, de stockage, et de la complexité. J'ai appris à apprécier, pourquoi stockage de mot de passe est toujours tellement plus important que la complexité de mot de passe. Si vous ne savez pas comment votre mot de passe est stocké, puis tout ce que vous ne pouvez vraiment dépendre de la complexité. Ce pourrait être la connaissance commune à un mot de passe et chiffrement des pros, mais pour la moyenne InfoSec ou Web expert en Sécurité, j'en doute fortement.

(C'est moi qui souligne.)

Ce qui fait un bon mot de passe, de toute façon?

L'entropie. (Non pas que je souscris pleinement à Randall point de vue.)

En bref, l'entropie est combien la variation est dans le mot de passe. Lorsqu'un mot de passe est uniquement de lettres minuscules, c'est que de 26 caractères. Ce n'est pas une grande variation. Alpha-numérique les mots de passe sont mieux, avec 36 caractères. Mais de permettre aux majuscules et minuscules, avec des symboles, est à peu près 96 caractères. C'est beaucoup mieux que les lettres. Un problème est que, pour faire de nos mots de passe mémorable nous insérer les modèles qui réduit l'entropie. Oups!

Mot de passe de l'entropie est approchée facilement. À l'aide de la gamme complète de caractères ascii (environ 96 typable caractères) donne une entropie de 6,6 par personnage, qui à 8 caractères pour un mot de passe est encore trop faible (52.679 bits d'entropie) pour la sécurité de l'avenir. Mais la bonne nouvelle, c'est: plus les mots de passe et mots de passe avec des caractères unicode, vraiment, augmentation de l'entropie d'un mot de passe et de le rendre plus difficile à craquer.

Il n'y a plus de discussion de mot de passe d'entropie sur la Crypto StackExchange site. Une bonne recherche sur Google permet également de mettre en place un grand nombre de résultats.

Dans les commentaires, j'ai parlé avec @popnoodles, qui a souligné que l'application d'une stratégie de mot de passe de X de la longueur X de nombreuses lettres, des chiffres, des symboles, etc, peuvent réduire l'entropie par mettre le mot de passe système plus prévisible. Je suis d'accord. Randomess, comme véritablement aléatoire que possible, est toujours le plus sûr, mais moins mémorable solution.

Donc, autant que j'ai été en mesure de dire, rendre le monde meilleur mot de passe est un Catch-22. Son pas mémorable, trop prévisible, trop court, trop de caractères unicode (dur de taper sur un ordinateur Windows/Mobile), trop long, etc. Aucun mot de passe n'est vraiment assez bon pour nos fins, nous devons les protéger, comme s'ils étaient de Fort Knox.

Les meilleures pratiques

Bcrypt et scrypt sont les meilleures pratiques actuelles. Scrypt sera meilleure que celle de bcrypt dans le temps, mais il n'a pas vu l'adoption de la norme par Linux/Unix ou par des serveurs web, et n'a pas eu des examens en profondeur de son algorithme publié pour le moment. Mais encore, l'avenir de l'algorithme ne semblent prometteurs. Si vous travaillez avec Ruby il y a un scrypt bijou qui va vous aider, et Node.js a maintenant son propre scrypt paquet.

Je vous suggère fortement de lire la documentation de la fonction crypt (), si vous voulez comprendre comment utiliser bcrypt, ou de vous trouver un bon wrapper ou utiliser quelque chose comme PHPASS pour un plus de l'héritage de la mise en œuvre. Je recommande un minimum de 12 tours de bcrypt, si ce n'est de 15 à 18 ans.

J'ai changé d'avis sur l'utilisation de bcrypt quand j'ai appris que bcrypt utilise uniquement blowfish clés du calendrier, avec un coût variable mécanisme. Ce dernier vous permet d'augmenter le coût de la force brute d'un mot de passe par l'augmentation de blowfish est déjà cher clé de l'annexe.

Moyenne des pratiques

J'ai du mal à imaginer cette situation plus. PHPASS prend en charge le PHP 3.0.18 à travers 5.3, donc il est utilisable sur presque toutes les configurations imaginables-et doit être utilisé si vous ne savez pour certain que votre environnement prend en charge bcrypt.

Mais supposons que vous ne pouvez pas utiliser bcrypt ou PHPASS à tous. Alors, quoi?

Essayez une mise en œuvre de PDKBF2 avec le nombre maximum de tours que votre environnement/application/utilisateur de la perception ne peut tolérer. Le numéro le plus bas, je recommande est de 2500 tours. Aussi, assurez-vous d'utiliser hash_hmac() si elle est disponible, pour rendre l'opération plus difficile à reproduire.

Les Pratiques De L'Avenir

Venir en PHP 5.5 est une pleine protection par mot de passe de la bibliothèque qui fait abstraction de loin les douleurs de travailler avec bcrypt. Alors que la plupart d'entre nous sommes coincés avec PHP 5.2 et 5.3 dans la plupart des environnements, en particulier des hôtes, @ircmaxell a construit une couche de compatibilité pour la venue de l'API qui est compatible PHP 5.3.7.

La Cryptographie Recap & Avertissement

La puissance de calcul nécessaire pour réellement craquer un mot de passe haché n'existe pas. La seule façon pour les ordinateurs à "craquer" un mot de passe est de recréer et de simulation de l'algorithme de hachage utilisé pour le fixer. La vitesse de la table de hachage est linéairement liée à sa capacité à être brute forcé. Pire encore, la plupart des algorithmes de hachage peuvent être facilement mises en parallèle pour effectuer encore plus vite. C'est pourquoi coûteux programmes comme bcrypt et scrypt sont si importants.

Vous ne pouvez pas possible de prévoir toutes les menaces ou voies de l'attaque, et donc vous devez faire de votre mieux pour protéger vos utilisateurs à l'avant. Si vous ne le faites pas, alors vous pourriez même passer à côté du fait que vous avez été attaqué jusqu'à ce qu'il soit trop tard... et vous êtes responsable. Pour éviter cette situation, la loi paranoïaque pour commencer. Attaque de votre propre logiciel (interne) et de tenter de voler les informations d'identification utilisateur, ou de modifier de comptes d'autres utilisateurs ou d'accéder à leurs données. Si vous n'avez pas tester la sécurité de votre système, alors vous ne pouvez pas blâmer personne, mais vous-même.

Enfin: je ne suis pas un cryptographe. Tout ce que j'ai dit, c'est mon avis, mais je pense qu'il est basé sur le bon vieux sens commun ... et beaucoup de lecture. Rappelez-vous, être aussi paranoïaque que possible, de rendre les choses le plus dur de s'immiscer que possible, et puis, si vous êtes toujours inquiet, contactez un blanc-chapeau de pirate ou un cryptographe pour voir ce qu'ils disent au sujet de votre code/système.

Answer 2

Beaucoup plus court et plus sûr de répondre - ne pas écrire votre propre mot de passe mécanisme à tous, utiliser celui qui est essayé et testé et intégré à WordPress, Drupal, etc, c'est à dire Openwall de phpass.

La plupart des programmeurs n'ont tout simplement pas l'expertise pour écrire crypto liées code en toute sécurité, sans introduire des vulnérabilités.

L'auto-test rapide: quel est le mot de passe de l'étirement et le nombre d'itérations devriez-vous utiliser? Si vous ne connaissez pas la réponse, vous devez utiliser phpass, comme le mot de passe d'étirement est maintenant une caractéristique essentielle de mot de passe mécanismes en raison de beaucoup plus rapide Cpu et l'utilisation des Gpu et des Fpga pour le crack de mots de passe à des taux de milliards de suppositions par seconde (avec Gpu).

Par exemple, vous pouvez maintenant faire craquer tous de 8 caractères des mots de passe Windows en 6 heures à l'aide de 5 produits Pc de bureau avec 5 Gpu pour PC. C'est brute-forcer c'est à dire l'énumération et la vérification de tous les 8 caractères du mot de passe Windows, y compris les caractères spéciaux, et n'est pas une attaque par dictionnaire. Il y a aussi beaucoup de rainbow table des attaques qui ont lieu ordinaire de Processeurs et sont très rapides. Tout cela parce que Windows encore n'a pas de sel ou d'étirer ses mots de passe, ne faites pas la même erreur que Microsoft l'a fait!

Voir cette excellente réponse pour en savoir plus sur pourquoi phpass est la meilleure façon d'aller.

Answer 3

Je ne voudrais pas stocker le mot de passe hashé de deux façons différentes, parce que le système est au moins aussi faible que la plus faible des algorithmes de hachage à utiliser.

Answer 4

Bien que la question a été posée, je veux juste réitérer que les sels utilisés pour le hachage doit être aléatoire et non pas comme l'adresse email, comme suggéré dans la première réponse.

Plus d'explications sont disponibles à http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/

Récemment, j'ai eu une discussion pour savoir si les mots de passe hachés salé avec l'aléatoire les bits sont plus sécurisées que l'on salé de deviner ou connu les sels. Voyons voir: Si le système de stockage de mot de passe est compromis bien que le système qui stocke l'aléatoire, le sel, l'attaquant va avoir accès à de hachage ainsi que le sel, donc, que le sel est aléatoire ou pas, n'a pas d'importance. L'attaquant ne peut générer des pré-calculé rainbow tables pour le crack de la table de hachage. Voici la partie intéressante - il n'est pas si anodin pour générer des pré-calculé des tables. Laissez-nous prendre exemple de sécurité WPA modèle. Votre mot de passe WPA est en fait jamais envoyé à Point D'Accès Sans Fil. Au lieu de cela, il est haché avec votre SSID (le nom de réseau - comme Linksys, Dlink, etc). Une très bonne explication de la façon dont cela fonctionne est ici. Afin de récupérer le mot de passe de hachage, vous besoin de connaître le mot de passe ainsi que le sel (nom de réseau). L'église de Le Wifi est déjà pré-calculé des tables de hachage qui est top 1000 Ssid et environ 1 million de mots de passe. La taille est de toutes les tables est d'environ 40 GO. Comme vous pouvez le lire sur leur site, quelqu'un a utilisé 15 FGPA tableaux pour 3 jours pour générer ces tables. En supposant que la victime est à l'aide du SSID que "a387csf3" et le mot de passe "123456", il va être forcé par ceux les tables? Non! .. il ne peut pas. Même si le mot est faible, les tables n'ont pas de hachages pour SSID a387csf3. C'est la beauté d'avoir aléatoire de sel. Il permettra de prévenir les craquelins qui prospèrent sur pré-calculée des tables. Peut-il arrêter déterminé un hacker? Probablement pas. Mais à l'aide de aléatoire sels ne fournissent une couche supplémentaire de défense. Alors que nous sommes sur ce sujet, laissez-nous discuter de l'avantage supplémentaire de stockage aléatoire sels sur un autre système. Scénario #1 : hachage de mots de Passe sont stockés sur le système de X et les valeurs du sel utilisé pour le hachage sont stockés sur le système d'Y. Ces valeurs du sel sont deviner ou connues (par exemple, nom d'utilisateur) Scénario n ° 2 : Hachage de mots de passe sont stockés sur le système de X et les valeurs du sel utilisé pour le hachage sont stockés sur le système de Y. Ces valeurs du sel sont aléatoires. En cas le système X a été compromise, comme vous pouvez le deviner, il y a une énorme avantage de l'utilisation aléatoire de sel sur un système séparé (Scénario n ° 2) . L'attaquant aura besoin de deviner le plus de valeurs pour être capable de craquer les tables de hachage. Si un 32 bits, le sel est utilisé, 2^32= 4,294,967,296 (environ 4,2 milliards de dollars) d'itérations sera peut être nécessaire pour chaque mot de passe deviné.

Answer 5

Je veux juste souligner que PHP 5.5 comprend un hachage de mot de passe API qui fournit un wrapper autour de crypt(). Cette API simplifie considérablement la tâche du hachage, de la vérification et de la redéfinition de hachage de mots de passe. L'auteur a également publié un pack de compatibilité (sous la forme d'un seul password.php le fichier que vous simplement require d'utilisation), pour ceux qui utilisent PHP 5.3.7 et, plus tard, et souhaitez exercer ce droit maintenant.

Il ne supporte BCRYPT pour l'instant, mais il vise à être facilement étendu pour inclure d'autres hachage de mot de passe techniques et parce que la technique et le coût est stocké dans la table de hachage, des modifications à votre moyen de hachage technique/coût n'entraînera pas la nullité actuelle de tables de hachage, le cadre sera automatiquement, utilisez la bonne technique/coût lors de la validation. Il gère également la génération d'un "secure" de sel si vous n'avez pas de définition explicite de votre propre.

L'API expose quatre fonctions:

• password_get_info() - retourne des informations à propos de la donnée de hachage
• password_hash() - crée un hash du mot de passe
• password_needs_rehash() - vérifie si l'objet de hachage correspond à la donnée d'options. Utile pour vérifier si le hachage est conforme à votre technique actuelle/coût du système vous permettant de ressasser si nécessaire
• password_verify() - vérifie que le mot de passe correspond à un hachage

À l'heure actuelle, ces fonctions acceptent les PASSWORD_BCRYPT et PASSWORD_DEFAULT mot de passe constantes, qui sont synonymes pour le moment, la différence étant que PASSWORD_DEFAULT "peut changer dans les nouvelles versions de PHP lors de la plus récente, la plus forte, les algorithmes de hachage sont pris en charge." À l'aide de PASSWORD_DEFAULT et password_needs_rehash() sur login (et ressasser si nécessaire) doivent s'assurer que votre hachages sont raisonnablement résilientes face aux attaques en force avec peu ou pas de travail pour vous.

EDIT: je viens de réaliser que ce qui est mentionné brièvement dans Robert K de réponse. Je vais quitter cette réponse ici car je pense qu'il donne un peu plus d'informations sur la façon dont il fonctionne et la facilité d'utilisation, elle fournit pour ceux qui ne connaissent pas la sécurité.