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

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 Comment 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.

Le mécanisme de hachage doit être disponible en PHP
Il doit être sûr
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

openwall.com/phpass est également très bonne bibliothèque
Md5 est maintenant complètement dangereux
Cela dépend de ce que vous êtes en utilisant pour. Il est trivial de l'arc-en-ciel-match ou juste la force brute non salé mots de passe MD5, bien sûr, mais décent avec le salage c'est toujours extrêmement peu pratique pour construire un arc-en-ciel de table rapide pour le craquage des ensembles de mots de passe, et de la force brute est une hoper.
PHP 5.5+ a un mot de passe sécurisé de hachage construit en php.net/manual/en/function.password-hash.php
php.net/faq.password
Comment utiliser le PHP 5.5 les fonctions de hachage du mot de passe
Voir aussi Openwall de la Portable PHP cadre de hachage de mot de passe (PHPass). Durci à l'encontre d'un certain nombre d'attaques sur les mots de passe utilisateur.

InformationsquelleAutor luiscubal | 2008-12-30

949

AVERTISSEMENT: Cette réponse a été écrit en 2008.

Depuis, PHP nous a donné password_hash et password_verify et, depuis leur introduction, ils sont recommandées pour le hachage de mot de passe & méthode de vérification.

La théorie de la réponse est toujours une bonne lecture si.

TL;DR

Ne pas faire
- Ne limite pas les caractères que les utilisateurs peuvent entrer des mots de passe. Seuls les idiots ne ce.
- Ne limite pas 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 de votre utilisateur sauf quand ils ont perdu le leur, et vous avez envoyé un temporaire.
- Jamais, jamais connecter les mots de passe en toute manière.
- Jamais de hachage des mots de passe avec SHA1 ou MD5 ou même SHA256! Moderne craquelins peut dépasser 60 et 180 milliards de hachages/seconde (respectivement).
- Ne pas mélanger bcrypt et avec le brut sortie de hash(), soit utiliser hex de sortie ou base64_encode il. (Ceci s'applique à toutes les suggestions que peut avoir un voyou \0 en elle, ce qui peut sérieusement affaiblir la sécurité.)
Dos
- 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 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 de 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, déclaré sur son blog après une récente récupération de mot de passe que requis par la force brute de rupture de son mot de passe de protection:

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 bonne 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 approximé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 de 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.

Tellement loin 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.

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 gem qui va vous aider, et Node.js a maintenant son propre scrypt paquet. Vous pouvez utiliser Scrypt en PHP, soit via le Scrypt extension ou la Libsodium extension (les deux sont disponibles dans PECL).

Je vous suggère fortement la lecture de la documentation pour la 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 devrait être utilisé si vous n'avez pas sais que pour certains que votre environnement prend en charge bcrypt.

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

Essayer 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.

Pratiques Futures

Venir en PHP 5.5 est un pleine protection par mot de passe de la bibliothèque que les résumés 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 un la couche de compatibilité pour la venue de l'API qui est compatible PHP 5.3.7.

Cryptographie Recap & Avertissement

La puissance de calcul nécessaire pour réellement fissure un hachage de mot de passe 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.
- Je vois. Mais dans mon cas, la personne peut avoir plusieurs e-mails. Dois-je utiliser l'ID(BIGINT clé primaire) à la place?
- aussi longtemps que les valeurs pour votre sel venir à partir d'un espace suffisamment grand, il sera un bon sel. Votre ID de valeur sera probablement suffisant, surtout si le nombre de dossiers est de grande taille (nombre d'Id sera grand).
- vous pouvez utiliser ce que l'utilisateur n'a plus qu'un, mais, idéalement, quelque chose qui ne change pas.
- J'aimerais inclure quelque chose de secret, ainsi. Le point est, vous voulez que la fonction de hachage de l'entrée pour être conforme, pour un bon mot de passe, mais vous souhaitez également être nonguessable si quelqu'un ne peut pas brute-force deviner le mot de passe hors ligne. (en comparaison d'avoir à le faire par le biais de votre page web qui est beaucoup plus lent)
- un secret qui n'aide pas que votre mot de passe DB est censé être secret, de toute façon si ils peuvent obtenir DB, ils peuvent également trouver ce secret que vous utilisez. il est cependant important que le sel est aléatoire.
- remarque, ce n'est pas vrai que "la puissance de calcul pour décrypter' n'existe pas encore. puisque la plupart des mots de passe sont les mots du dictionnaire ou dictionnaire dérivé, un dictionnaire de base d'attaque est généralement très efficace (d'où l'utilisation de stratégies de mot de passe et l'itération de compte).
- Frank, tout ce que vous dites est vrai, l'algorithmique des cycles qu'il faut pour générer les mots n'est pas possible. N'oubliez pas l'inclusion du sel. La force Brute aura toujours du travail s'ils connaissent votre algorithme de hachage et le sel, sinon c'est presque impossible.
- Mais cela ne fait pas d'insécurité des mots de passe plus sûrs. Il est tout simplement la base de données des lignes plus sûr si compromise, à quel point vous devriez changer votre sel immédiatement et informer vos utilisateurs de changer leurs mots de passe.
- Même lorsque le sel et l'algorithme sont connus, trouver un mot de passe par force brute recherche prendra de nombreuses années si la bonne méthode est utilisée. Les mots de passe sont craqué quand ils sont prévus par la suite d'un modèle, comme pour la transformation des mots du dictionnaire et en intégrant d'autres crèches. Une partie essentielle de la méthode est une sorte de calcul intensif clé de l'étirement de la technique, comme l'utilisation de milliers d'itérations de la fonction de hachage.
- 42, si j'étais de la conception d'un véritable système de sécurité, je vous suggère un militaire de grade algorithme de hachage de toute façon avec un ~16 bits généré de façon aléatoire des numéros stockés dans la base de données. En général, l'utilisation, un sel avec un mot de passe est mieux que rien-à moins que ce soit est compromise. Je ne prétends pas être un expert, rien de mieux qu'forcée mot de passe de rotation plus un militaire de grade de l'algorithme, mais pour la base de la non-critiques de logiciels, cela est suffisant.
- aux puces, je ne suis pas d'argumenter avec vous. Il suffit de pointer comment alambiqué et complexe de cette région de notre travail. Je garde l'espoir d'obtenir à l'école de la, la fin la plus intelligente, la meilleure pratique pour la création d'un petit site web du système de gestion de contenu. Je suis encore à apprendre ici. ...chaque fois que je lis quelque chose qui a du sens, j'ai bientôt 5 avis d'autres postes qui la contredisent. ce tour et tour devient vertigineux rapidement 🙂
- Absolument! Je viens de partager ce que j'ai trouvé. J'ai trouvé un certain nombre de choses à partir de Shneier sur la Sécurité et une très longue (compliquée) de discussion sur un site de news (ne me souviens pas de qui maintenant).
- "Même MD5 est encore sûr, car à part une attaque en force de la puissance de calcul nécessaire pour décrypter n'existe pas encore." OMG, je ne le crois pas. MD5 ne peut pas être "décrypté", période. Mais il n'est certainement pas coffre-fort, tel qu'il est. Jamais entendu parler de rainbow tables?
- Si vous êtes à l'aide de MD5 sur un logiciel qui nécessite une haute sécurité (comme un magasin), alors VOUS ÊTES le fou, pas moi. Je sais que MD5 est extrêmement rapide, mais si vous êtes à la conception de logiciels de forum avec les bonnes pratiques, il est encore généralement sûres.
- Intéressant de révision. Est l'ID de l'utilisateur(par exemple, un incrément automatique de type BIGINT) une bonne nonce? Ou depuis qu'elle n'est pas aléatoire, il n'est pas bon? Aussi, je vais avoir à stocker le nonce pour chaque utilisateur dans la base de données... le site de la clé + nonce + HMAC fournir une importante amélioration de la sécurité sur un salée(avec ID d'utilisateur) de hachage itérées plusieurs fois? De même, est une itération l'algorithme HMAC plusieurs fois bon pour la sécurité?
- Excellent post. Répondu à beaucoup de mes questions. Cependant, je ne suis pas certain de ce que cela signifie pour enregistrer le site_key dans le système de fichiers. Pourriez-vous expliquer? Pour moi, même .fichier php dans un dossier sur le serveur est le système de fichiers.
- L'article de 42 lié erreur 404—voici une copie chargen.matasano.com/chargen/2007/9/7/...
- Je vais le mettre à jour au sujet de bcrypt de temps en temps. J'ai été très occupé et le régime, j'ai suggéré au moins modérément efficace. Mieux que que quelqu'un vient de lancer un simple md5/sha1 mot de passe haché dans leur DB.
- pas d'autre moyen de sauver un nombre aléatoire de $nonce à l'exception de l'enregistrer dans la base de données? Si le pirate peut obtenir hashed_password de db, assurez-vous qu'il a pu obtenir nonce de db trop
- Une grande révision. J'ai été en utilisant bcrypt pour un certain temps maintenant, et je crois que je vais commencer à regarder vers scrypt pour des projets futurs.
- Je pense que même en envoyant un nouveau mot de passe en cas de perte de l'un est une mauvaise idée. Pourquoi ne pas envoyer un lien à un site sécurisé qui permet à l'utilisateur de changer son mot de passe? C'est beaucoup plus confortable (pas besoin de changer le mot de passe après la connexion avec l'un au hasard) et plus sécurisé car aucun mot de passe n'est allé sur le fil non chiffrés - rappelez-vous, les utilisateurs sont paresseux et les chances sont bonnes qu'ils ne changent pas le mot de passe aléatoire.
- L'envoi d'un mot de passe temporaire par courriel qui demande à l'utilisateur de modifier la première fois qu'ils l'utilisent et l'envoi d'un "sécuriser" le lien par e-mail qui leur permet de définir leur mot de passe sont également risqué. Dans les deux cas, toute personne qui intercepte le courrier électronique peut accéder au compte tant qu'ils utiliser le lien ou le mot de passe avant que le destinataire ne.
- Au sujet de votre plus récente édition: "besoin d'au moins 1 lettre majuscule, 1 minuscule, un chiffre et un symbole" est en contradiction directe avec le xkcd bande dessinée dans le lien. Il montre un exemple d'un mot de passe avec pas de symboles, mais haute entropie.
- Je ne suis pas sûr que Randall est à droite, donc je n'ai pas 100% d'approuver sa proposition si j'ai essayé. Avec les minuscules et les espaces de votre entropie est ~4.75/personnage, qui pour 28 caractères est d'environ 131-133 bits d'entropie. Mais il y a seulement quatre mots, il, ~1 millions de mots dans la langue anglaise qui est 1e+24 combinaisons rapport supérieur/inférieur/symboles à 28 caractères est 3.18855 e+de 55 ans ou plus. De toute façon, je ne suis pas convaincu à 100%.
- Les humains sont imparfaits générateurs de nombres aléatoires, ce qui réduit considérablement l'entropie dans les deux cas. Ils ne choisissez pas un parfaitement aléatoire [a-zA-Z0-9_$%#]{28} de la séquence, ils sont plus susceptibles de choisir quelque chose comme $justinBieber28.
- Vous êtes correct. Toutefois, un gestionnaire de mot de passe qui peut faire que inestimable. Qui est l'autre problème avec Randall suggestion: sa méthode produit des pseudo-aléatoire de combinaisons de moins aléatoire que notre charabia pseudo-aléatoire de mots de passe. C'est pourquoi c'est seulement une suggestion de quelque chose à faire. L'un est probablement aussi sécurisé que les autres (pour l'instant).
- Notez qu'il n'a jamais vraiment vérifie l'entropie de "charabia complet", parce que les gens ont tendance à ne pas utiliser charabia complet pour les mots de passe. Générées par ordinateur mots de passe peuvent être beaucoup mieux que les humains générés par mots de passe, mais comment beaucoup de gens il suffit de frapper le "régénérer" jusqu'à ce qu'ils ont obtenu quelque chose de facile à retenir? Ou même ajuster le résultat d'être plus simple? Tout ce qui diminue l'entropie.
- J'ai dit un mot de passe manager ce n'est pas seulement un générateur. Personnellement, j'utilise LastPass pour générer/retenir les mots de passe, et il suffit de faire le meilleur mot de passe, je peux verrouiller ce service vers le bas. Qui maintient l'entropie élevée pour d'autres sites. En tant qu'utilisateur c'est la meilleure solution que j'ai rencontré jusqu'à présent.
- Il suffit de lire la mise à jour, et c'est beaucoup mieux. Retrait de mon -1. Il serait peut-être utile de mentionner la nouvelle 5.5 Api: php.net/manual/en/ref.password.php et de la compatibilité du projet: github.com/ircmaxell/password_compat Et merci pour la mise à jour de la réponse!!!
- nécessite au moins 1 lettre majuscule, 1 minuscule, un chiffre et un symbole ne va pas améliorer l'entropie du mot de passe, il suffit de le rendre plus difficile pour les gens à se rappeler.
- En élargissant le jeu de caractères et le nombre de caractères utilisés, il élargit les bits d'entropie par caractère, il n'est PAS une garantie contre le non-aléatoire de mots de passe par les utilisateurs.
- Par l'extension du jeu de caractères oui elle augmente, MAIS, en forçant tous les mots de passe pour suivre les règles diminue la quantité d'options possibles. Disons que quelqu'un a été d'obtenir un mot de passe par force brute. En leur disant le mot de passe utilisateur possède au moins 1 lettre majuscule, 1 minuscule, un chiffre et un symbole, cela signifie que le nombre d'essais qu'ils ont besoin de l'est nettement moins. En permettant à l'utilisateur de décider ce qu'ils veulent, le hacker a plus de peine.
- C'est un excellent point que j'ai totalement raté: j'ai donné la suggestion que de placer un dur-exigence qui permettrait de limiter le nombre d'plaintexts. Merci pour cette remarque!
- "Cela permettra d'améliorer l'entropie du mot de passe" - si vous forcez quelqu'un à utiliser au moins un numéro, puis vous avez réduit l'entropie du mot de passe car il y a seulement 10 chiffres à choisir
- pas sûr de savoir pourquoi vous personnellement m'a attaqué avec sarcasme là - falaise-notes de version". Je vais demander aux modérateurs pour vous donner une suspension temporaire car il était hors de commande.
- Je ne comprends pas ce que vous lisez comme le sarcasme. Le TL;DR section au début de ma réponse est la "falaise-notes de version de la longue partie de ma réponse. Tout ce que je demande est que vous répondez à des points spécifiques dans la section pertinente, plutôt que de le TL;DR résumé qui ne contient pas de débat sur le sujet.
- Également envisager de hachage sur le côté client, de cette manière, même si le serveur est corrompue en quelque sorte, les mots de passe ne peuvent pas être récupérés!
- À moins que votre journal dans le code est livré dans un plugin, vous ne pouvez pas vérifier que le code javascript est votre code d'origine, sans aucun compromis. Aussi, l'envoi d'un hachage pour être comparée à une valeur de hachage dans la DB est tout aussi dangereux (il prend la place du mot de passe). Ce n'est pas très bon, ou fort, idée. Il est préférable de s'appuyer sur la sécurité de la connexion que c'est le javascript de sécurité.
- Je suppose que vous m'avez mal compris. Je n'ai pas dit de le faire au lieu de créer une connexion sécurisée, ce que je suggère est de ce faire, en plus, la cause, même si la connexion est sécurisée, si le serveur se compromise, alors chaque requête envoyée au serveur potentiellement montre plaine des mots de passe pour les attaquants. Donc, mon point est, qu'en tant qu'utilisateur je ne veux pas faire confiance à n'importe quel serveur, mais cela ne signifie pas que je veux me souvenir de 64 caractères chaîne de hash au lieu de la couleur de mes fruits préférés. (Plus d'explications ici: xkcd.com/936)
- Ouais, j'ai probablement mal compris. Toutefois, l'envoi de la valeur de hachage pour le serveur est tout aussi mauvais. Mais je pense que SQRL par Steve Gibson montre vraiment bonne promesse.
- c'est vraiment juste un petit ajout qui protège le mot de passe lui-même, et non pas l'environnement. Mais depuis que les mots de passe doivent être haché de toute façon pour le stocker, le hachage sur le côté client plutôt du côté serveur n'est pas tellement un code supplémentaire de l'ajout de certains à la sécurité sans sortir de tout ça.
- Je suis également d'avis que les mots de passe ne devrait pas expirer. En forçant les utilisateurs à créer de nouveaux mots de passe et refuse d'utiliser des mots de passe déjà utilisés les résultats dans les utilisateurs qui choisissent de pire en pire des combinaisons qu'ils peuvent ne jamais s'en souvenir. Assurez-vous qu'ils ne devraient pas se souvenir de toute façon, mais je parle de la réalité non pas un monde idéal.
- En général je n'aime pas le mot de passe d'expiration, trop. Mais la prévention de l'utilisation de mots de passe précédents est une bonne idée pour les applications de haute sécurité. Après tout, vous ne voudriez pas que quelqu'un en alternant les mots de passe sur quelque chose de très sensible. Mais je laisse à ceux qui parce qu'ils se sentaient comme subjective conclusions. Ceux qui sont plus difficile à prouver que "X algorithme peut être calculé en Y M-hachage/sec".
- J'ai entendu parler des stratégies à des gens qui vont juste réinitialiser leur mot de passe 15 fois à expiration à la fin du "déjà utilisé" liste et revenir à un mot de passe, ils peuvent se souvenir... ouais d'accord les numéros ne sont pas coupé et sec sur cette partie de la question. C'est discutable et que le bon choix est différent selon les systèmes de but.
- Ouais, je ne suis pas surpris. La seule façon de l'expiration du mot de passe, le système de travail est passé si les mots de passe étaient stockés, alors levenshtein a été utilisé pour valider un nouveau mot de passe. Il est tyrannique, mais c'est la seule façon de s'assurer que les utilisateurs ne prennent pas de "mot de passe", puis "password1", puis "mot_passe2", etc. (Non pas que je conseille de faire cela...)
- Concernant les forçant les utilisateurs à mettre en œuvre un mot de passe à chaque type de personnage: d'abord, il va pisser sur eux et les faire disparaître, de deux, il n'est même pas nécessaire/utile. Il vous suffit de démarrer le verrouillage du compte suite à de trop nombreuses tentatives/trop rapide de la tente, Même si vous venez de le restreindre à 1 tentative de mot de passe par seconde, vous avez paralysé une attaque par force brute cracker options, non?
- Comment récupérer le mot de passe lorsque les utilisateurs oublié?
- la façon dont je voudrais faire c'est(et merci de ne corrigez-moi si je suis un con:P): faites-vous oublié le mot de passe de la page et laissez-lui de remplir un champ avec son adresse e-mail. Lorsque l'utilisateur clique sur envoyer vous générez un mot de passe aléatoire peut-être que cela aidera (qui bien sûr doit être haché fois de plus) et envoyer un email avec le mot de passe aléatoire à l'intérieur et un lien vers la page de son compte et de lui dire de changer son mot de passe. C'est la façon dont je le ferais peut-être que je suis totalement faux, mais alors je suis curieux de voir comment il devrait être fait
- Je ne conseille pas de changer le mot de passe utilisateur, parce que quelqu'un de la pêche pour les utilisateurs/e-mails pourrait verrouiller les utilisateurs. Au lieu de cela, créer un jeton avec un court temps d'expiration (comme < 15 minutes) et d'utiliser ce jeton dans l'e-mail de lien vers une page de réinitialisation. C'est plus sûr. Mais réinitialisation de mots de passe par courriel n'est jamais particulièrement sécurisé (OMI).
- Je vous remercie pour votre réponse. Je vais certainement utiliser cette méthode. Je vais regarder autour de l'internet pour quelques exemples. Pouvez-vous me donner un timestamp, je devrais utiliser avant la date d'expiration. Par exemple, serait une heure aussi être acceptable? Je sais qu'il serait moins sécurisé, mais certains services de messagerie sont assez lentes
- Je suis en désaccord avec exigeant une lettre majuscule, lettre minuscule, un chiffre et un symbole tout à la fois. Tout ce qui va faire, c'est de faire les gens d'entrer "Password1!" au lieu de "mot de passe". Ou pire, ils me l'écrire sur des post-its. De telles restrictions ne sont pas pertinents pour le gestionnaire de mot de passe des utilisateurs, mais même alors, ne pas mettre en œuvre de telles restrictions sévères, sauf si vous êtes une banque ou de services de paiement.
- En lieu et place de scrypt et bcrypt vous devriez sans doute aujourd'hui être à la recherche à argon2, qui a remporté le hachage de mot de passe de la concurrence.
- La limitation d'un mot de passe <200 caractères est très bien à mon humble avis; si l'utilisateur n'est entré 0s et 1s ils avaient encore ont pratiquement incassable entropie, ou pour les besoins de la discussion, 1000 caractères. Il n'y a rien à faire, moyen de plus de 256 bits d'entropie juste pour dire qu'il n'y a "pas de limite". Êtes-vous heureux de hachage d'un multi-GB mot de passe-je vous donner? Une autre solution: faire de l'utilisateur de hachage leur 50 GO mot de passe avec l'algorithme SHA-2 ou autre et prétendre que le mot de passe. Bam, tous les 'mots de passe', vous recevez sont de 32 octets de long (encore besoin d'utiliser un hachage de mot de passe pour stocker bien).
- La plupart des serveurs web serait de rejeter un 50 GO mot de passe à un dépassement des limites de chargement et de délai d'attente à l'entrée, donc je pense que ce point est discutable. Tant que votre limite est de 64+, ce serait de trouver à mon avis. (Vous pourriez vouloir vérifier l'âge de cette réponse, cependant).
InformationsquelleAutor Robert K
130

Beaucoup plus court et plus sûr de réponse - ne pas écrire votre propre mot de passe mécanisme à tous les, utiliser un essayé et testé le mécanisme.
- PHP 5.5 ou supérieur: password_hash() est de bonne qualité et partie du coeur de PHP.
- Les anciennes versions de PHP: OpenWall de phpass bibliothèque est beaucoup mieux que la plupart de code personnalisé utilisé dans WordPress, Drupal, etc.
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: qu'est-ce que 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 password_hash(), en tant que mot de passe l'étirement est maintenant une caractéristique essentielle de mot de passe mécanismes en raison de beaucoup plus rapide Cpu et l'utilisation de Les gpu et les Fpga à craquer des mots de passe à des taux de des milliards de suppositions par seconde (avec Gpu).

Par exemple, vous pouvez crack tous les 8 caractères des mots de passe Windows en 6 heures à l'aide de 25 Gpu installés dans les 5 Ordinateurs de bureau. C'est brute-forcer c'est à dire l'énumération et la vérification de chaque 8 caractères du mot de passe Windows, y compris les caractères spéciaux, et n'est pas une attaque par dictionnaire. C'était en 2012, à partir de 2018, vous pouvez utiliser moins de Gpu, ou fissure plus vite avec 25 Gpu.

Il y a aussi beaucoup de rainbow table des attaques sur les mots de passe Windows qui s'exécutent sur ordinaire Processeurs et sont très rapides. Tout cela parce que Windows encore ne pas saler ou de s'étirer ses mots de passe, même dans Windows 10 - ne pas faire la même erreur que Microsoft l'a fait!

Voir aussi:
- excellente réponse avec plus sur les raisons de password_hash() ou phpass sont la meilleure façon d'aller.
- bon article de blog donnant recommandés travail des facteurs (nombre d'itérations) pour les principaux algorithmes, y compris bcrypt, scrypt et PBKDF2.
- mais ces systèmes sont mieux connus et peut-être déjà compromise. mais il vaut mieux faire votre propre lorsque vous ne savez pas ce que vous faites.
- Re "ces systèmes sont mieux connus et peut-être déjà compromise" - il n'y a aucune raison pour laquelle un système bien conçu pour l'authentification devraient devenir des "compromis" juste parce que c'est de mieux en mieux connue. Les bibliothèques comme phpass sont rédigés par des experts et commenté par de nombreuses personnes dans le détail - le fait qu'ils sont bien connus va de pair avec un examen minutieux par des personnes différentes et sont plus susceptibles de dire qu'ils sont en sécurité.
- Compte tenu de la récente hachage de mot de passe dumps de LinkedIn, Dernier.fm et autres, ce qui est tout à fait d'actualité. Vous êtes en bonne compagnie on ne sait pas comment écrire votre propre mot de passe mécanisme de!
- "n'écrivez pas votre propre mot de passe mécanisme à tous" - mais la vraiment paranoïaque veulent écrire leur propre afin de minimiser la probabilité de la NSA, ont une porte dérobée.
- les chances d'une revue par les pairs hachage de mot de passe de l'algorithme ayant une backdoor de la NSA sont très faibles, de mon point de vue. Les chances de quelqu'un qui n'est pas un vrai crypto expert de l'écriture d'un nouveau mot de passe mécanisme de hachage sans autres vulnérabilités est beaucoup plus faible. Et de la webapp utilise MD5 ou SHA-1 de hachage, ce qui est terrible, même Chris Shiflett l'autre grande Essentielles de Sécurité PHP livre recommande MD5 ...
- phpass n'est PAS la meilleure façon d'aller. N'a jamais été et probablement ne le sera jamais. J'ai passé en revue le code il y a plusieurs années et il n'est PAS bloqué sur Windows ou de toute plate-forme où /dev/urandom est pas disponible. Il ne permet PAS de suivre les meilleures pratiques en matière de sécurité, en utilisant une combinaison de md5() et microtime() quand il doit être l'arrêt de l'application au lieu de faire de fausses déclarations à propos de la sécurité. Il n'a pas vu toutes les mises à jour depuis que j'ai passé en revue le code en dépit de PHP lui-même aller de l'avant dans le domaine de la sécurité avec bcrypt dans le noyau. Rester LOIN de phpass.
- pouvez-vous recommander une autre bibliothèque PHP pour le hachage de mot de passe? Sauf si il y a une meilleure bibliothèque, phpass sera toujours mieux que la grande majorité de code personnalisé qui utilise non salées et non étirés MD5.
- Le password_hash() fonction. Comme mentionné précédemment, il est intégré dans PHP de base (aka /ext/standard).
- password_hash() la valeur par défaut bcrypt et dispose d'une fonction de coût pour les étirements, de sorte qu'il semble bon pour les gens sur PHP 5.5 ou supérieure, php.net/manual/en/function.password-hash.php. phpass prend en charge les versions de PHP antérieures où il est certainement meilleur que celui de la plupart des gens, code personnalisé construit sur MD5 etc.
InformationsquelleAutor RichVel
41

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.
- pas pour le hachage de mot de passe. l'attaquant ne doit casser un hachage pour récupérer le mot de passe. le point est discutable de toute façon que ni MD5 ni SHA1 toute pratique pauses disponible dans le mot de passe scénario.
- désolé, j'ai mal lu votre réponse que de recommander à l'aide de deux hachages...vous êtes tout à fait correct. À l'aide de deux hachages affaiblit le système dans le cas de mot de passe, comme ils n'ont besoin de briser le plus faible de hachage.
InformationsquelleAutor Tom Haigh
35

Que de PHP 5.5, PHP est simple, assurer les fonctions de hachage et de vérification des mots de passe, password_hash() et password_verify()
```
$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false
```
Quand password_hash() est utilisé, il génère un hasard sel et l'inclut dans la sortie de hachage (avec le coût et l'algorithme utilisé.) password_verify() lit alors que hachage et détermine le sel et la méthode de chiffrement utilisée, et le vérifie à l'encontre de la condition mot de passe en clair.

Fournir la PASSWORD_DEFAULT indique à PHP pour utiliser la valeur par défaut algorithme de hachage de l'installation de la version de PHP. Exactement l'algorithme que cela signifie est destiné à changer au fil du temps dans les futures versions, de sorte qu'il sera toujours l'un des plus forts algorithmes disponibles.

Coût croissant (par défaut 10) rend la valeur de hachage plus difficile de force brute mais aussi des moyens de génération de hachages et de vérification des mots de passe contre eux sera plus de travail pour votre CPU.

Noter que même si la valeur par défaut algorithme de hachage peut changer, ancien hachages continuera à vérifier l'amende juste parce que l'algorithme utilisé est stocké dans la table de hachage et password_verify() ramasse sur elle.

InformationsquelleAutor AlliterativeAlice
31

Si 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'explication est disponible à l'- 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" 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é.
- Même si l'attaquant obtient le sel, un "sitesalt:usersalt:mot de passe" chaîne est toujours en résistant à des tables précalculées, puisque l'attaquant a besoin pour générer les tables pour chaque utilisateur(l'attaque devient beaucoup plus lent), à moins bien sûr d'un utilisateur spécifique est visé...
- Quant à "Même si l'attaquant obtient le sel, un "sitesalt:usersalt:mot de passe" chaîne est toujours en résistant à des tables précalculées" , tout à fait d'accord. Mon point est que sitesalt si fait aléatoire et longue, permettra de rendre le système plus sûr qu'il l' (sitesalt) d'être prévisible. J'ai vu quelques personnes qui recommandent l'utilisation de l'adresse e-mail, etc comme le sel, et je déconseille à qui.
- Vous avez raté que j'ai écrit. Je l'ai dit d'utiliser un hasard nonce, stocké à l'enregistrement, en PLUS de l'adresse e-mail. L'ajout de l'adresse de courriel rend pour plus d'entropie pour la hacker pour travailler sur. Depuis, j'ai réécrit ma réponse en faveur de bcrypt.
InformationsquelleAutor Gaurav Kumar
26

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 à l'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é.

InformationsquelleAutor JonoCoetzee
18

Je suis en utilisant Phpass qui est un simple fichier PHP classe qui pourrait être mis en place très facilement dans presque chaque projet PHP. Voir aussi Le H.

Par défaut utilisé plus puissant de chiffrement qui est mis en œuvre dans Phpass, qui est bcrypt et retombe à d'autres cryptages bas du MD5 pour assurer la compatibilité descendante avec les cadres comme WordPress.

Le retour de hachage peut être stocké dans la base de données tel qu'il est. Exemple d'utilisation pour la génération de hachage est:
```
$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);
```
Vérifier le mot de passe, on peut utiliser:
```
$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);
```
InformationsquelleAutor rabudde
13

CHOSES À RETENIR

Beaucoup a été dit à propos de cryptage de Mot de passe pour PHP, dont la plupart sont de très bon conseils, mais avant même de commencer le processus d'utilisation de PHP pour le mot de passe de cryptage assurez-vous que vous avez mis en œuvre ou prêt à être mis en œuvre.

SERVEUR

PORTS

N'importe comment bon votre de chiffrement est si vous n'avez pas correctement sécurisé le serveur qui exécute le PHP de base de données et tous vos efforts seront vains. La plupart des serveurs de fonction relativement de la même façon, ils ont des ports attribués pour vous permettre d'y accéder à distance, soit par ftp ou shell. Assurez-vous de changer le port par défaut de ce qui jamais de connexion à distance, vous disposez d'active. En ne faisant pas cela, vous, en effet, ont fait de l'attaquant de faire une étape de moins en accédant à votre système.

Nom d'utilisateur

Pour tout ce qui est bon dans le monde de ne pas utiliser le nom d'utilisateur admin, root ou quelque chose de similaire. Aussi, si vous êtes sur un unix système NE font PAS le compte root login accessible, il doit toujours être sudo seulement.

MOT de passe

Vous dire à vos utilisateurs à faire un bon mot de passe pour éviter de se faire piraté, faire la même chose. Quel est le point en passant par tout l'effort de fermer votre porte d'entrée lorsque vous avez la porte dérobée ouverte.

BASE de données

SERVEUR

Idéalement, vous voulez que votre base de données et des APPLICATIONS sur des serveurs distincts. Ce n'est pas toujours possible en raison du coût, mais il ne permet pas pour des raisons de sécurité que l'attaquant va passer par deux étapes pour accéder pleinement au système.

UTILISATEUR

Toujours votre application à son propre compte pour accéder à la DB, et seulement lui donner les privilèges dont il a besoin.

Alors disposer d'un compte d'utilisateur distinct pour vous qui n'est pas stockée sur le serveur, même pas dans l'application.

Comme toujours, NE font PAS de cette racine ou quelque chose de similaire.

MOT de passe

Suivez les mêmes directives que pour tous les bons mots de passe. Aussi, ne pas réutiliser le même mot de passe sur n'importe quel SERVEUR ou une base de données des comptes sur le même système.

PHP

MOT de passe

JAMAIS stocker un mot de passe dans votre base de données, au lieu de stocker la valeur de hachage unique et sel, je vous expliquerai pourquoi plus tard.

De HACHAGE

UNE FAÇON DE HACHAGE!!!!!!!, Jamais de hachage d'un mot de passe de sorte qu'il peut être inversée, de la cendre doit être d'une certaine façon, ce qui signifie que vous n'avez pas inverser la et de les comparer pour le mot de passe, vous, au lieu de hachage du mot de passe saisi de la même façon, et comparer les deux tables de hachage. Cela signifie que même si un attaquant a accès à la DB, il ne sait pas ce que le mot de passe est, juste ses résultant de hachage. Ce qui signifie plus de sécurité pour vos utilisateurs dans le pire scénario possible.

Il y a beaucoup de bonnes fonctions de hachage là-bas (password_hash, hash, etc...) mais vous avez besoin de choisir un bon algorithme de hachage pour être efficace. (bcrypt et ceux similaires sont décents algorithmes).

Lorsque le hachage de la vitesse est la clé, le plus lent, le plus résistant aux attaques par Force Brute.

L'une des erreurs les plus courantes dans le hachage est que les hachages sont pas uniques pour les utilisateurs. C'est principalement parce que les sels ne sont pas uniquement généré.

SALAGE

Les mots de passe doivent toujours être salée avant de les hacher. Saler ajoute une chaîne de caractères pour le mot de passe de façon similaire, les mots de passe ne semble pas la même dans la DB. Toutefois, si le sel n'est pas unique à chaque utilisateur (ie: vous utilisez une codés en dur de sel) que vous avez fait votre sel sans valeur. Parce qu'une fois un hacker un mot de passe de sel, il a le sel pour tous.

Lorsque vous créez un sel assurez-vous qu'il est unique pour le mot de passe c'est le salage, puis le stocker à la fois rempli de hachage et le sel dans votre base de données. Ce que cela va faire, c'est de faire en sorte qu'un attaquant devra individuellement fissure chacun de sel et de hachage avant qu'ils ne puissent y avoir accès. Cela signifie beaucoup plus de temps et de travail pour l'attaquant.

UTILISATEURS DE CRÉER DES MOTS DE PASSE

Si l'utilisateur est la création d'un mot de passe via le frontend qui signifie qu'il doit être envoyé au serveur. Cela ouvre un problème de sécurité, car cela signifie que le mot de passe non crypté est envoyé au serveur et si un attaquant est capable d'écouter et de l'accès de tous à votre sécurité en PHP est sans valeur. TOUJOURS transmettre des données de manière SÉCURISÉE, ce qui est fait grâce au protocole SSL, mais être fatigué, même SSL n'est pas parfait (l'installation de OpenSSL Heartbleed faille en est un exemple).

Également permettre à l'utilisateur de créer un mot de passe sécurisé, il est simple et devrait toujours être fait, l'utilisateur en sera reconnaissant de lui à la fin.

Enfin, peu importe les mesures de sécurité à prendre, rien n'est sûr à 100%, le plus avancé de la technologie afin de protéger devient la plus avancée, les attaques deviennent. Mais en suivant ces étapes permettra de rendre votre site plus sûr et beaucoup moins souhaitable pour les attaquants à aller au bout.

Ici est une classe PHP qui crée une table de hachage et de sel pour un mot de passe facilement

http://git.io/mSJqpw
- Vous devriez grève SHA512 à partir de votre liste de décent algorithmes de hachage, parce que c'est trop rapide. L'utiliser uniquement en combinaison avec PBKDF2. Alors que BCrypt est basé sur blowfish, blowfish lui-même est un algorithme de chiffrement, pas pour le hachage.
- Comment conservez-vous l'aléatoire de sel dans la DB? Je pense que vous n'avez pas de hachage, il (ne peut pas être utilisé à des fins de vérification) ni de stocker en clair (pas de réels avantages si l'attaquant peut lire la DB). Alors, comment vous le faites?
- wmfrancia a écrit: "le Salage ajoute une chaîne de caractères pour le mot de passe de façon similaire, les mots de passe ne semble pas la même dans la bd". Cela ne fait pas de sens pour moi. Hachages dans la DB figure déjà dissemblables parce que c'est une propriété des fonctions de hachage.
- wmfancia a écrit en ce qui concerne une constante de sel: "une fois un hacker un mot de passe de sel, il a le sel pour tous". La même chose peut être dit que si le pirate chiffres qui champ DB est le sel, il a les sels pour tous. Depuis une constante de sel ne serait probablement pas dans la DB, ce qui est une bonne chose au sujet d'une constante de sel.
- Bien entendu, ces commentaires ne sont pas à suggérer un hasard sel par l'utilisateur n'est pas mieux qu'un sel par l'application. C'est mieux.
InformationsquelleAutor wmfrancia
12

Google dit SHA256 est disponible pour PHP.

Vous devriez certainement utiliser un sel. Je vous recommande d'utiliser octets aléatoires (et de ne pas vous limiter aux caractères et de chiffres). Comme d'habitude, plus vous choisissez, le plus sûr, plus lent, il obtient. 64 octets devrait être bon, je suppose.
- 64 bits devrait être suffisant pour tout le monde?
- Je reviendrais à ce bout de 20 ans. 🙂 Mais ouais SHA256 est en effet disponible. Si vous voulez savoir comment sécuriser SHA256 est, vous pouvez vérifier cela: security.stackexchange.com/questions/90064/...
InformationsquelleAutor AticusFinch

Je l'ai trouvé parfait sujet sur cette question ici: https://crackstation.net/hashing-security.htm, je voulais vous faire bénéficier de cela, voici le code source aussi que la condition de prévention contre en fonction du temps d'attaque aussi.

<?php
/*
* Password hashing with PBKDF2.
* Author: havoc AT defuse.ca
* www: https://defuse.ca/php-pbkdf2.htm
*/
//These constants may be changed without breaking existing hashes.
define("PBKDF2_HASH_ALGORITHM", "sha256");
define("PBKDF2_ITERATIONS", 1000);
define("PBKDF2_SALT_BYTES", 24);
define("PBKDF2_HASH_BYTES", 24);
define("HASH_SECTIONS", 4);
define("HASH_ALGORITHM_INDEX", 0);
define("HASH_ITERATION_INDEX", 1);
define("HASH_SALT_INDEX", 2);
define("HASH_PBKDF2_INDEX", 3);
function create_hash($password)
{
//format: algorithm:iterations:salt:hash
$salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTES, MCRYPT_DEV_URANDOM));
return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" . 
base64_encode(pbkdf2(
PBKDF2_HASH_ALGORITHM,
$password,
$salt,
PBKDF2_ITERATIONS,
PBKDF2_HASH_BYTES,
true
));
}
function validate_password($password, $good_hash)
{
$params = explode(":", $good_hash);
if(count($params) < HASH_SECTIONS)
return false; 
$pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
return slow_equals(
$pbkdf2,
pbkdf2(
$params[HASH_ALGORITHM_INDEX],
$password,
$params[HASH_SALT_INDEX],
(int)$params[HASH_ITERATION_INDEX],
strlen($pbkdf2),
true
)
);
}
//Compares two strings $a and $b in length-constant time.
function slow_equals($a, $b)
{
$diff = strlen($a) ^ strlen($b);
for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
{
$diff |= ord($a[$i]) ^ ord($b[$i]);
}
return $diff === 0; 
}
/*
* PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
* $algorithm - The hash algorithm to use. Recommended: SHA256
* $password - The password.
* $salt - A salt that is unique to the password.
* $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
* $key_length - The length of the derived key in bytes.
* $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
* Returns: A $key_length-byte key derived from the password and salt.
*
* Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
*
* This implementation of PBKDF2 was originally created by https://defuse.ca
* With improvements by http://www.variations-of-shadow.com
*/
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false)
{
$algorithm = strtolower($algorithm);
if(!in_array($algorithm, hash_algos(), true))
die('PBKDF2 ERROR: Invalid hash algorithm.');
if($count <= 0 || $key_length <= 0)
die('PBKDF2 ERROR: Invalid parameters.');
$hash_length = strlen(hash($algorithm, "", true));
$block_count = ceil($key_length / $hash_length);
$output = "";
for($i = 1; $i <= $block_count; $i++) {
//$i encoded as 4 bytes, big endian.
$last = $salt . pack("N", $i);
//first iteration
$last = $xorsum = hash_hmac($algorithm, $last, $password, true);
//perform the other $count - 1 iterations
for ($j = 1; $j < $count; $j++) {
$xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
}
$output .= $xorsum;
}
if($raw_output)
return substr($output, 0, $key_length);
else
return bin2hex(substr($output, 0, $key_length));
}
?>

- Vous nous donner la solution sans aucune utilisation non utilisation

InformationsquelleAutor Jason OOO

7

En fin de compte, double hachage, mathématiquement, ne fournit aucune prestation. Dans la pratique, cependant, il est utile pour prévenir l'arc-en-ciel de la table-attaques. En d'autres termes, il n'est pas plus avantageuse que le hachage avec un sel, qui prend beaucoup moins de temps processeur dans votre application ou sur votre serveur.
- plusieurs de hachage protège également contre le dictionnaire et les attaques par force brute - c'est à dire qu'il fait tout simplement prendre plus de temps à calculer.
- double hachage ne vous donnera pas un avantage significatif, mais multi tour de hachage itérations sont encore possible à la défense contre les dictionnaire et bruce attaques de force. Industriel de la force des mots de passe l'utilisation de+ de 1000 tours. PKCS#5 PBKDF1 suggère 1000 tours minimum.
InformationsquelleAutor Max
5

J'ai l'habitude d'utiliser SHA1 et le sel avec l'ID d'utilisateur (ou un autre utilisateur-information spécifique), et parfois j'en outre utiliser une constante de sel (j'ai donc 2 parties pour le sel).

SHA1 est maintenant considéré comme quelque peu compromise, mais à un bien moindre degré que MD5. À l'aide d'un sel (le sel), vous êtes à la prévention de l'utilisation d'un générique table arc-en-ciel pour attaquer votre hachages (certaines personnes ont même eu du succès en utilisant Google comme une sorte d'arc-en-ciel de la table par la recherche de la table de hachage). Un attaquant pourrait générer un arc-en-ciel de la table à l'aide de votre sel, de sorte que c'est pourquoi vous devez inclure un utilisateur spécifique du sel. De cette façon, ils auront pour générer un arc-en-ciel de la table pour chaque enregistrement dans votre système, pas un seul pour l'ensemble de votre système! Avec ce type de salage, même MD5 est décemment sécurisé.
- constante de sel n'est pas une bonne idée...probablement pas un défaut fatal, mais il affaiblit inutilement le système.
- MD5 et SHA1 sont rapides, donc c'est une mauvaise idée.
InformationsquelleAutor rmeador
3

SHA1 et un sel devrait suffire (en fonction, bien entendu, si vous êtes le codage quelque chose pour Fort Knox ou un système de connexion à votre liste de courses) pour l'avenir prévisible. Si SHA1 n'est pas assez bon pour vous, utilisez SHA256.

L'idée d'un sel est de jeter le hachage des résultats hors-bilan, pour ainsi dire. Il est connu, par exemple, que le MD5 hash d'une chaîne vide est d41d8cd98f00b204e9800998ecf8427e. Donc, si quelqu'un avec une assez bonne mémoire permettrait de voir qui de hachage et de savoir que c'est le hash d'une chaîne vide. Mais si la chaîne est salée (par exemple, avec la chaîne "MY_PERSONAL_SALT"), le hachage de la "chaîne vide" (à savoir "MY_PERSONAL_SALT") devient aeac2612626724592271634fb14d3ea6, d'où la non-évidence de trace. Ce que j'essaie de dire, qu'il est préférable d'utiliser tout de sel, que de ne pas. Par conséquent, il n'est pas trop d'importance à savoir qui de sel à utiliser.

Il y a en fait les sites web qui n'juste ce - vous pouvez nourrir un (md5) de hachage, et il crache un texte en clair connu que génère ce hash. Si vous obtenez un accès à une base de données qui stocke plaine md5 hachages, il serait trivial pour vous d'entrer la valeur de hachage pour l'administrateur d'un tel service, et connectez-vous. Mais, si les mots de passe ont été salés, tels un service deviendrait inefficace.

Également, double hachage est généralement considéré comme une mauvaise méthode, car elle diminue le résultat de l'espace. Tous les hachages sont de longueur fixe. Ainsi, vous ne pouvez avoir qu'un nombre fini de valeurs de cette longueur fixe, et les résultats deviennent de moins en moins variées. Cette pourrait être considéré comme une autre forme de salage, mais je ne le recommande pas.
- Le site cible ne doivent pas contenir quelque chose de trop sensible(c'est pas une banque), mais je préfère l'avoir obtenu.
- double hachage ne réduit pas le résultat d'espace. itératif de hachage est une commune de la lutte contre les dictionnaire et les attaques par force brute (il ralentit beaucoup plus qu'il ralentit votre mot de passe de contrôle).
- oui, il est mauvais. sha1(sha1($foo)) réduit efficacement l'espace de sortie, parce que la collision de la fonction interne deviendra automatiquement une collision de l'extérieur. La dégradation est linéaire, mais c'est encore un sujet de préoccupation. L'itératif de hachage des méthodes de flux de données en arrière sur chaque rond, tels que $hash = sha1(sha1($salt . $password) . $salt). Mais c'est toujours pas bon... le Bâton avec PBKDF2 ou Bcrypt...
InformationsquelleAutor Henrik Paul
-7

ok
dans le fitsy nous avons besoin de sel
le sel doit être unique
alors laissez générer
```
   /**
* Generating string
* @param $size
* @return string
*/
function Uniwur_string($size){
$text = md5(uniqid(rand(), TRUE));
RETURN substr($text, 0, $size);
}
```
aussi nous avons besoin de la table de hachage
Je suis en utilisant sha512
il est le meilleur et il est en php
```
   /**
* Hashing string
* @param $string
* @return string
*/
function hash($string){
return hash('sha512', $string);
}
```
ainsi, nous pouvons maintenant utiliser cette fonction pour générer mot de passe sûr
```
//generating unique password
$password = Uniwur_string(20); //or you can add manual password
//generating 32 character salt
$salt = Uniwur_string(32);
//now we can manipulate this informations
//hashin salt for safe
$hash_salt = hash($salt);
//hashing password
$hash_psw = hash($password.$hash_salt);
```
maintenant nous avons besoin d'enregistrer dans notre base de données $hash_psw valeur de la variable $et le sel variable

et pour autoriser, nous allons utiliser les mêmes étapes...

c'est le meilleur moyen pour la sécurité de nos clients, mots de passe...

P. s. pour les 2 dernières étapes, vous pouvez utiliser votre propre algorithme...
mais assurez-vous que vous pouvez générer ce hachage de mot de passe dans le futur
lorsque vous devez autoriser l'utilisateur...
- Cette question a été sur les hashs des mots de passe. 1 l'exécution de sha512 (même si salé) est largement considéré comme de ne pas être assez bon pour la protection par mot de passe. (aussi que RNG n'est pas cryptographique sécurisé, afin de l'utiliser pour la génération de mot de passe est risqué).
- Vous n'avez aucune idée de ce que vous êtes en train de faire. Lire le haut de réponses dans ce post, et vous pouvez voir pourquoi votre code n'est pas seulement l'insécurité, mais n'a pas de sens.
- ok. mon code n'est pas sécurisé. alors laissez-moi savoir pourquoi vous aide dans vos algorithmes ony sha256??? Je sais que sha512 est le meilleur, pourquoi ne pas l'utiliser???
- sha512 est assez bon pour objectif général de hachage, mais la protection par mot de passe nécessite des hachages avec des propriétés très spécifiques ("lenteur" est curieusement un une bonne chose, par exemple, et sha512 est assez rapide). Certaines personnes ont utilisé sha512 comme un bloc de construction pour créer un mot de passe les fonctions de hachage, mais de nos jours, l'approche recommandée est "l'utilisation bcrypt et de garder un œil sur scrypt".
InformationsquelleAutor shalvasoft

Vous devez vous connecter pour publier un commentaire.

TL;DR

Ne pas faire

Dos

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

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

Meilleures pratiques

Moyenne des pratiques

Pratiques Futures

Cryptographie Recap & Avertissement