Sécuriser le hachage et le sel pour les mots de passe PHP

https://stackoverflow.com/questions/401656

03-07-2019
|

Question

On dit actuellement que MD5 est partiellement dangereux. Compte tenu de cela, j'aimerais savoir quel mécanisme utiliser pour la protection par mot de passe.

Cette question, Est & Double hachage # 8220 & # 8221; un mot de passe moins sûr qu'un simple hachage? suggère de hacher plusieurs fois peut être une bonne idée, alors que Comment mettre en œuvre une protection par mot de passe pour des fichiers individuels? suggère d'utiliser Salt.

J'utilise PHP. Je veux un système de cryptage des mots de passe sûr et rapide. Le hachage d'un mot de passe un million de fois peut être plus sûr, mais aussi plus lent. Comment atteindre un bon équilibre entre vitesse et sécurité? De plus, je préférerais que le résultat ait un nombre constant de caractères.

Le mécanisme de hachage doit être disponible en PHP
Cela doit être sûr
Il peut utiliser du sel (dans ce cas, tous les sels sont-ils égaux? Y a-t-il un moyen de générer de bons sels?)

De plus, devrais-je stocker deux champs dans la base de données (l'un utilisant MD5 et l'autre utilisant SHA, par exemple)? Cela le rendrait-il plus sûr ou moins sûr?

Au cas où je ne serais pas assez clair, je veux savoir quelle (s) fonction (s) de hachage utiliser et comment choisir un bon sel afin d’avoir un mécanisme de protection par mot de passe rapide et sûr.

Des questions connexes qui ne couvrent pas tout à fait ma question:

Quelle est la différence entre SHA et MD5 en PHP
cryptage de mot de passe simple
Méthodes sécurisées de stockage de clés et de mots de passe pour asp.net
Comment implémenteriez-vous les mots de passe salés dans Tomcat 5.5

La solution

AVERTISSEMENT : cette réponse a été écrite en 2008.

Depuis lors, PHP nous a fourni password_hash et password_verify et, depuis leur introduction, ils sont le mot de passe recommandé hashing & amp; méthode de vérification.

La théorie de la réponse reste néanmoins une bonne lecture.

TL; DR

À ne pas faire

Ne limitez pas le nombre de caractères que les utilisateurs peuvent saisir pour les mots de passe. Seuls les idiots le font.
Ne limitez pas la longueur d'un mot de passe. Si vos utilisateurs veulent une phrase contenant supercalifragilisticexpialidocious, n’empêchez pas les utilisateurs de l’utiliser.
Ne stockez jamais le mot de passe de votre utilisateur en texte brut.
N'envoyez jamais de mot de passe par e-mail à votre utilisateur , sauf s'il en a perdu un et si vous en avez envoyé un temporairement.
Ne jamais enregistrer les mots de passe de quelque manière que ce soit.
Ne hachez jamais les mots de passe avec SHA1 ou MD5 ou même SHA256! Les crackers modernes peuvent dépasser 60 et 180 milliards de hachages / seconde (respectivement).
Ne mélangez pas bcrypt et avec le raw de hash () , utilisez soit la sortie hexadécimale, soit base64_encode. (Ceci s’applique à toute entrée pouvant contenir un \ 0 malveillant, ce qui peut sérieusement affaiblir la sécurité.)

Dos

Utilisez scrypt quand vous le pouvez; bcrypt si vous ne pouvez pas.
Utilisez PBKDF2 si vous ne pouvez utiliser ni bcrypt ni scrypt avec les hachages SHA2.
Réinitialisez les mots de passe de chacun lorsque la base de données est compromise.
Implémentez une longueur minimale raisonnable de 8 à 10 caractères, plus au moins une lettre majuscule, une lettre minuscule, un chiffre et un symbole. Cela améliorera l'entropie du mot de passe, ce qui le rendra plus difficile à craquer. (Consultez la section "Qu'est-ce qui fait un bon mot de passe?" Pour plus de précisions.)

Pourquoi hacher les mots de passe de toute façon?

L'objectif du hachage des mots de passe est simple: empêcher les accès malveillants aux comptes d'utilisateurs en compromettant la base de données. L'objectif du hachage de mot de passe est donc de dissuader un pirate informatique ou un pirate informatique en leur coûtant trop de temps ou d'argent pour calculer les mots de passe en texte brut. Et le temps et les coûts sont les meilleurs moyens de dissuasion dans votre arsenal.

Une autre raison pour laquelle vous souhaitez un hachage solide et robuste sur un compte d'utilisateur est de vous donner suffisamment de temps pour modifier tous les mots de passe du système. Si votre base de données est compromise, vous aurez besoin de suffisamment de temps pour au moins verrouiller le système, sinon changer tous les mots de passe de 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 nécessitant la suppression brutale de sa protection par mot de passe:

Fait intéressant, en vivant ce cauchemar, j’ai appris BEAUCOUP que je ne connaissais pas la fêlure des mots de passe, le stockage et la complexité. J’en viens à comprendre pourquoi le stockage de mots de passe est bien plus important que la complexité de ces derniers. Si vous ne savez pas comment votre mot de passe est stocké, la complexité dépend vraiment de vous. Cela pourrait être courant pour les professionnels du mot de passe et de la crypto, mais pour l'expert moyen d'InfoSec ou de Web Security, en doute fortement.

(Soulignez le mien.)

Qu'est-ce qui fait qu'un bon mot de passe de toute façon?

Entropie . (Non pas que je souscrive pleinement au point de vue de Randall.)

En bref, l'entropie est la variation du mot de passe. Lorsqu'un mot de passe est composé uniquement de lettres romaines minuscules, il ne compte que 26 caractères. Ce n'est pas beaucoup de variation. Les mots de passe alphanumériques sont meilleurs, avec 36 caractères. Mais permettre les majuscules et les minuscules, avec les symboles, équivaut à environ 96 caractères. C'est beaucoup mieux que de simples lettres. L’un des problèmes est que, pour rendre nos mots de passe mémorables, nous insérons des motifs qui réduisent l’entropie. Oups!

L'entropie du mot de passe est approchée facilement. . L'utilisation de toute la gamme de caractères ascii (environ 96 caractères pouvant être saisis) génère une entropie de 6,6 par caractère, ce qui, avec un mot de passe de 8 caractères, est encore trop faible (52,679 bits d'entropie) pour une sécurité future. Mais la bonne nouvelle est que des mots de passe plus longs et des mots de passe avec des caractères unicode augmentent considérablement l'entropie d'un mot de passe et le rendent plus difficile à déchiffrer.

Il existe une discussion plus détaillée de l'entropie des mots de passe dans le Site Crypto StackExchange . Une bonne recherche sur Google donnera également beaucoup de résultats.

Dans les commentaires avec @popnoodles, qui a souligné que l'application d'une stratégie de mot de passe de longueur X avec X lettres, nombres, symboles, etc. peut réellement réduire l'entropie en rendant le schéma de mot de passe plus prévisible. Je suis d'accord. Le hasard, aussi aléatoire que possible, est toujours la solution la plus sûre mais la moins mémorable.

Autant que je sache, faire du meilleur mot de passe du monde est un Catch-22. Soit ce n’est pas mémorable, trop prévisible, trop court, trop de caractères Unicode (difficile à taper sur un appareil Windows / Mobile), trop long, etc. Aucun mot de passe n’est vraiment suffisant pour nos besoins, nous devons donc les protéger étaient à Fort Knox.

Meilleures pratiques

Bcrypt et scrypt sont les meilleures pratiques actuelles. Scrypt sera meilleur que bcrypt avec le temps, mais il n'a pas encore été adopté comme norme par Linux. / Unix ou par les serveurs Web, et n’a pas encore publié d’examens approfondis de son algorithme. Mais encore, l'avenir de l'algorithme semble prometteur. Si vous travaillez avec Ruby, il existe un bijou scrypt qui vous aidera, et Node.js a maintenant son propre package scrypt . Vous pouvez utiliser Scrypt en PHP via l'extension Scrypt ou à l'aide de Libsodium (les deux sont disponibles dans PECL).

Je suggère fortement de lire la documentation de la fonction de cryptage si vous souhaitez comprendre comment utiliser bcrypt, ou trouvez-vous un bien encapsuleur ou utilisez quelque chose comme PHPASS pour une implémentation plus ancienne. Je recommande un minimum de 12 tours de bcrypt, sinon de 15 à 18 ans.

J'ai changé d'avis sur l'utilisation de bcrypt quand j'ai appris que bcrypt n'utilise que la planification de clé de blowfish, avec un mécanisme de coût variable. Ce dernier vous permet d’augmenter le coût de la force brutale d’un mot de passe en augmentant la planification des clés déjà coûteuse de blowfish.

Pratiques moyennes

Je ne peux presque plus imaginer cette situation. PHPASS prend en charge PHP 3.0.18 à 5.3. Il est donc utilisable sur presque toutes les installations imaginables & # 8212; et doit être utilisé si vous ne savez pas avec certitude que votre environnement prend en charge bcrypt.

Mais supposons que vous ne puissiez pas utiliser bcrypt ou PHPASS du tout. Quoi alors?

Essayez une implémentation de PDKBF2 avec le nombre maximal de tours que votre environnement / application / perception de l'utilisateur peut tolérer. Le nombre le plus bas que je recommanderais est 2500 tours. Veillez également à utiliser hash_hmac () s'il est disponible pour rendre l'opération plus difficile à reproduire.

Pratiques futures

PHP 5.5 contient une bibliothèque de protection par mot de passe complet qui supprime peine de travailler avec bcrypt. Alors que la plupart d’entre nous sont coincés avec PHP 5.2 et 5.3 dans la plupart des environnements courants, en particulier des hôtes partagés, @ircmaxell a construit une couche de compatibilité pour la prochaine API compatible avec PHP 5.3.7.

Récapitulatif de cryptographie & amp; Déni de responsabilité

La puissance de calcul nécessaire pour casser un mot de passe haché n'existe pas. La seule manière pour les ordinateurs de "casser" un mot de passe consiste à le recréer et à simuler l'algorithme de hachage utilisé pour le sécuriser. La vitesse du hash est linéairement liée à sa capacité à être brutalement forcée. Pire encore, la plupart des algorithmes de hachage peuvent être facilement parallélisés pour une performance encore plus rapide. C’est pourquoi les systèmes coûteux tels que bcrypt et scrypt sont si importants.

Vous ne pouvez probablement pas prévoir toutes les menaces ou les voies d’attaque. Vous devez donc faire de votre mieux pour protéger vos utilisateurs à l’avance . Sinon, vous risquez même de rater le fait que vous avez été attaqué jusqu'à ce qu'il soit trop tard ... et que vous soyez responsable . Pour éviter cette situation, agissez d’abord paranoïaque. Attaquez votre propre logiciel (en interne) et tentez de voler les informations d'identification de l'utilisateur, ou de modifier les comptes d'autres utilisateurs ou d'accéder à leurs données. Si vous ne testez pas la sécurité de votre système, vous ne pouvez en vouloir à personne d'autre que vous-même.

Enfin: je ne suis pas un cryptographe. Tout ce que j'ai dit est mon opinion, mais j'estime que c'est basé sur le bon sens commun ... et beaucoup de lecture. N'oubliez pas que vous devez être aussi paranoïaque que possible, rendre les choses aussi difficiles que possible à interférer, puis si vous êtes toujours inquiet, contactez un hacker ou un cryptographe à chapeau blanc pour connaître son avis sur votre code / système.

Autres conseils

Une réponse beaucoup plus courte et plus sûre - n'écrivez pas du tout votre propre mécanisme de mot de passe , utilisez un mécanisme éprouvé.

PHP 5.5 ou supérieur: password_hash () est de bonne qualité et une partie du coeur de PHP.
Anciennes versions de PHP: la bibliothèque phpass d'OpenWall est bien meilleure que la plupart des codes personnalisés - utilisés dans WordPress, Drupal, etc.

La plupart des programmeurs n'ont simplement pas l'expertise nécessaire pour écrire du code lié à la cryptographie en toute sécurité sans introduire de vulnérabilités.

Auto-test rapide: qu'est-ce que l'extension du mot de passe et combien d'itérations devez-vous utiliser? Si vous ne connaissez pas la réponse, vous devez utiliser password_hash () , car l'extension des mots de passe est désormais une fonctionnalité essentielle des mécanismes de mot de passe en raison de processeurs beaucoup plus rapides et de l'utilisation de Les GPU et les FPGA pour déchiffrer les mots de passe à des taux de des milliards de suppositions par seconde (avec les GPU).

Par exemple, vous pouvez déchiffrez tous les mots de passe Windows à 8 caractères en 6 heures à l'aide de 25 GPU installés sur 5 ordinateurs de bureau. Ceci oblige à énumérer et à vérifier tous les mots de passe Windows à 8 caractères , y compris les caractères spéciaux, et ne constitue pas une attaque par dictionnaire. C'était en 2012, à compter de 2018, vous pourriez utiliser moins de GPU ou accélérer vos craintes avec 25 GPU.

Il existe également de nombreuses attaques sur table arc-en-ciel sur les mots de passe Windows qui fonctionnent sur des processeurs ordinaires et sont très rapides. Tout cela est dû au fait que Windows encore ne salue pas et ne tisse pas ses mots de passe, même sous Windows 10 - ne faites pas la même erreur que Microsoft!

Voir aussi:

excellente réponse avec plus d'informations sur pourquoi password_hash () ou phpass sont la meilleure solution.
bon article de blog donnant les" facteurs de travail "recommandés (nombre d'itérations) pour les principaux algorithmes, notamment bcrypt, scrypt et PBKDF2.

Je ne voudrais pas stocker le mot de passe haché de deux manières différentes, car le système est au moins aussi faible que le plus faible des algorithmes de hachage utilisés.

Depuis PHP 5.5, PHP dispose de fonctions simples et sécurisées pour le hachage et la 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

Lorsque password_hash () est utilisé, il génère un sel aléatoire et l'inclut dans le hachage généré (avec le coût et l'algorithme utilisé.) password_verify () puis lit ce hachage et détermine la méthode de chiffrement et de chiffrement utilisée et le vérifie par rapport au mot de passe en texte clair fourni.

Fournir le PASSWORD_DEFAULT indique à PHP d'utiliser l'algorithme de hachage par défaut de la version installée de PHP. Exactement quel algorithme cela signifie est destiné à changer au fil du temps dans les versions futures, de sorte qu'il restera toujours l'un des algorithmes les plus puissants disponibles.

L'augmentation des coûts (dont la valeur par défaut est 10) rend le hachage plus difficile à manoeuvrer brutalement mais signifie également que la génération de hachages et la vérification des mots de passe par rapport à eux demanderont plus de travail à la CPU de votre serveur.

Notez que même si l'algorithme de hachage par défaut peut changer, les anciens empreintes continueront à se vérifier correctement car l'algorithme utilisé est stocké dans le hachage et password_verify () y est repris.

Bien que la question ait été résolue, je tiens simplement à rappeler que les sels utilisés pour le hachage doivent être aléatoires et non pas comme l’adresse e-mail suggérée dans la première réponse.

De plus amples explications sont disponibles sur http: / /www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/

Récemment, j’ai eu une discussion sur la question de savoir si les mots de passe hachés étaient salés au hasard les bits sont plus sûrs que celui salé avec devinable ou connu sels. Voyons: Si le système qui enregistre le mot de passe est compromis en tant que ainsi que le système qui stocke le sel aléatoire, l'attaquant va avoir accès à hasch ainsi que du sel, donc si le sel est aléatoire ou non, cela n'a pas d'importance. L’attaquant aura la possibilité de générer des données pré-calculées tables arc-en-ciel pour casser le hash. Voici la partie intéressante n'est pas si simple de générer des tables pré-calculées. Prenons l'exemple du modèle de sécurité WPA. Votre mot de passe WPA n'est en réalité 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 comment cela fonctionne est ici. Afin de récupérer le mot de passe de hash, vous devrez besoin de connaître le mot de passe ainsi que le sel (nom du réseau). Église de Le wifi a déjà pré-calculé des tables de hachage contenant les 1000 meilleurs SSID et environ 1 million de mots de passe. La taille de toutes les tables est d'environ 40 Go. Comme vous pouvez le lire sur leur site, quelqu'un a utilisé 15 baies FGPA pendant 3 jours pour générer ces tables. En supposant que la victime utilise le SSID comme & # 8220; a387csf3 & # 8243; et mot de passe comme & # 8220; 123456 & # 8243 ;, sera-t-il craqué par ceux les tables? Non! .. ça ne peut pas. Même si le mot de passe est faible, les tables ne pas avoir de hachage pour le SSID a387csf3. C'est la beauté d'avoir sel aléatoire. Il dissuadera les crackers qui prospèrent de pré-calculer les tables. Peut-il arrêter un pirate informatique déterminé? Probablement pas. Mais en utilisant les sels aléatoires fournissent une couche supplémentaire de défense. Alors que nous sommes sur ce sujet, laissez-nous discuter des avantages supplémentaires de stocker aléatoire sels sur un système séparé. Scénario 1: les hachages de mots de passe sont stockés sur le système X, les valeurs de sel utilisées pour le hachage sont stockées sur le système Y. Ces valeurs de sel sont prévisibles ou connues (par exemple, nom d'utilisateur) Scénario n ° 2: Les hachages de mots de passe sont stockés sur le système X et les valeurs de sel utilisées pour le hachage est stocké sur le système Y. Ces valeurs de sel sont aléatoires. Au cas où le système X a été compromis, comme vous pouvez le deviner, il existe un énorme avantage de l'utilisation de sel aléatoire sur un système séparé (scénario n ° 2). L’attaquant devra deviner des valeurs d’addition pour pouvoir craquer hachage. Si un sel 32 bits est utilisé, 2 ^ 32 = 4 294 967 296 (environ 4,2 milliards d’itérations seront nécessaires pour chaque mot de passe deviné.

Je tiens simplement à souligner que PHP 5.5 inclut une API de hachage de mot de passe qui fournit une wrapper autour de crypt () . Cette API simplifie considérablement la tâche de hachage, de vérification et de redistribution des mots de passe. L’auteur a également publié un pack de compatibilité (sous la forme d’un fichier unique password.php que vous demandez seulement à utiliser), pour ceux qui utilisent PHP 5.3.7 et les versions ultérieures et qui souhaitent l’utiliser maintenant.

Il ne prend en charge que BCRYPT pour le moment, mais il vise à être facilement étendu pour inclure d'autres techniques de hachage de mot de passe et, comme la technique et le coût sont stockés dans le hachage, les modifications apportées à votre technique / coût de hachage préféré n'invalideront pas les hachages actuels , le framework utilisera automatiquement la technique / le coût correct lors de la validation. Il gère également la génération d’un message "sécurisé". sel si vous ne définissez pas explicitement le vôtre.

L'API expose quatre fonctions:

password_get_info () - retourne des informations sur le hachage donné
password_hash () - crée un hachage de mot de passe
password_needs_rehash () - vérifie si le hachage donné correspond aux options données. Utile pour vérifier si le hachage est conforme à votre schéma technique / coût actuel vous permettant de ressasser si nécessaire
password_verify () - vérifie qu'un mot de passe correspond à un hachage

Pour le moment, ces fonctions acceptent les constantes de mot de passe PASSWORD_BCRYPT et PASSWORD_DEFAULT, qui sont également synonymes, la différence étant que PASSWORD_DEFAULT "peut changer dans les nouvelles versions de PHP lorsque des algorithmes de hachage plus récents et plus puissants sont pris en charge." L'utilisation de PASSWORD_DEFAULT et de password_needs_rehash () lors de la connexion (et de la redistribution des points si nécessaire) devrait vous assurer que vos hachages sont raisonnablement résistants aux attaques par force brute avec peu ou pas de travail pour vous.

EDIT: Je viens de me rendre compte que ceci est mentionné brièvement dans la réponse de Robert K. Je laisse cette réponse ici car je pense que cela fournit un peu plus d'informations sur son fonctionnement et sur la facilité d'utilisation offerte aux personnes qui ne connaissent pas la sécurité.

J'utilise Phpass , une simple classe PHP pouvant être implémentée très facilement dans presque tous les PHP. projet. Voir aussi The H .

Par défaut, il utilisait le cryptage disponible le plus puissant implémenté dans Phpass, à savoir bcrypt , et utilisait d'autres cryptages que MD5 pour offrir une compatibilité ascendante à des frameworks tels que Wordpress.

Le hachage renvoyé pourrait être stocké dans la base de données tel quel. Voici un exemple d'utilisation pour générer un hachage:

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

Pour vérifier le mot de passe, on peut utiliser:

$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);

Choses à retenir

On a beaucoup parlé du cryptage des mots de passe pour PHP, ce qui est généralement un très bon conseil, mais avant même de commencer le processus d’utilisation de PHP pour le cryptage des mots de passe, assurez-vous que les éléments suivants sont implémentés ou prêts à être implémentés.

SERVEUR

PORTS

Peu importe la qualité de votre cryptage si vous ne sécurisez pas correctement le serveur qui exécute PHP et la base de données, tous vos efforts sont vains. La plupart des serveurs fonctionnent relativement de la même manière, ils ont des ports attribués pour vous permettre d'y accéder à distance via ftp ou shell. Assurez-vous de changer le port par défaut de la connexion distante active. En ne le faisant pas, vous avez en fait obligé l'attaquant à effectuer une étape de moins pour accéder à votre système.

NOM D'UTILISATEUR

Pour tout ce qui est bon dans le monde, n'utilisez pas le nom d'utilisateur admin, root ou quelque chose de similaire. De plus, si vous êtes sur un système basé sur Unix, NE rendez PAS la connexion au compte root accessible, il devrait toujours s'agir uniquement de sudo.

MOT DE PASSE

Vous demandez à vos utilisateurs de créer de bons mots de passe pour éviter de se faire pirater. Faites de même. Quel est l’intérêt de passer tous les efforts nécessaires pour verrouiller votre porte lorsque la porte arrière est grande ouverte.

DATABASE

SERVEUR

Idéalement, vous voulez que votre base de données et votre application soient sur des serveurs distincts. Ce n'est pas toujours possible en raison des coûts, mais cela permet une certaine sécurité, car l'attaquant devra suivre deux étapes pour accéder pleinement au système.

UTILISATEUR

Assurez-vous que votre application a toujours son propre compte pour accéder à la base de données et ne lui donnez que les privilèges dont elle aura besoin.

Ensuite, ayez pour vous un compte utilisateur distinct, qui ne sera stocké nulle part sur le serveur, pas même dans l'application.

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

MOT DE PASSE

Suivez les mêmes directives que pour tous les bons mots de passe. Ne réutilisez pas non plus le même mot de passe sur les comptes SERVER ou DB du même système.

PHP

MOT DE PASSE

NE JAMAIS JAMAIS stocker un mot de passe dans votre base de données, mais stocker plutôt le hachage et le sel unique, je vais expliquer pourquoi plus tard.

HASHING

ONE WAY HASHING !!!!!!!, Ne hachez jamais un mot de passe de manière à ce qu'il puisse être inversé. Entrez le mot de passe de la même manière et comparez les deux hachages. Cela signifie que même si un attaquant a accès à la base de données, il ne sait pas quel est le mot de passe, mais uniquement le hachage qui en résulte. Ce qui signifie plus de sécurité pour vos utilisateurs dans le pire des scénarios.

Il existe de nombreuses bonnes fonctions de hachage ( password_hash , hash , etc ...), mais vous devez sélectionner un bon algorithme pour que le hash soit efficace. (bcrypt et ceux qui lui ressemblent sont des algorithmes décents.)

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

Une des erreurs les plus courantes dans le hachage est que les hachages ne sont pas uniques aux utilisateurs. Ceci est principalement dû au fait que les sels ne sont pas générés de manière unique.

SALTING

Les mots de passe doivent toujours être salés avant leur hachage. Salting ajoute une chaîne aléatoire au mot de passe afin que les mots de passe similaires n'apparaissent pas de la même manière dans la base de données. Cependant, si le sel n’est pas propre à chaque utilisateur (c’est-à-dire que vous utilisez un sel codé en dur), vous n’avez pratiquement pas rendu votre sel inutile. Parce qu'une fois qu'un attaquant a trouvé un mot de passe sel, il a le sel pour tous.

Lorsque vous créez un sel, assurez-vous que le mot de passe associé au mot de passe est unique, puis stockez le hachage et le sel dans votre base de données. Cela fera en sorte qu'un attaquant devra craquer individuellement chaque sel et chaque hasch avant de pouvoir y accéder. Cela signifie beaucoup plus de travail et de temps pour l'attaquant.

UTILISATEURS CRÉANT DES MOTS DE PASSE

Si l'utilisateur crée un mot de passe via l'interface frontale, cela signifie qu'il doit être envoyé au serveur. Cela pose un problème de sécurité car cela signifie que le mot de passe non chiffré est envoyé au serveur. Si un attaquant peut écouter et accéder, toute votre sécurité en PHP ne vaut rien. TOUJOURS transmettre les données SÉCURISÉMENT, cela se fait via SSL, mais soyez las même si SSL n'est pas sans faille (la faille Heartbleed d'OpenSSL en est un exemple).

Demandez également à l’utilisateur de créer un mot de passe sécurisé. C’est simple et il faut toujours le faire. L’utilisateur lui en sera reconnaissant à la fin.

Enfin, quelles que soient les mesures de sécurité que vous preniez, rien n’est sécurisé à 100%, plus la technologie à protéger est avancée, plus les attaques deviennent avancées. En suivant ces étapes, votre site sera plus sécurisé et moins convoité par les attaquants.

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

http://git.io/mSJqpw

Google indique que SHA256 est disponible pour PHP.

Vous devez absolument utiliser un sel. Je vous recommande d'utiliser des octets aléatoires (et non de vous limiter aux caractères et aux nombres). Comme d'habitude, plus vous choisissez de temps, plus vous êtes sûr et lent. 64 octets devraient être bons, je suppose.

J'ai trouvé le sujet parfait à ce sujet ici: https://crackstation.net/hashing-security.htm , je souhaitais que vous en tiriez parti. Voici le code source qui prévient également les attaques basées sur le temps.

<?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));
}
?>

Au final, le double hachage, mathématiquement, ne procure aucun avantage. En pratique, cependant, il est utile pour prévenir les attaques basées sur des tables arc-en-ciel. En d’autres termes, cela n’est pas plus avantageux que le hachage avec un salt, qui prend beaucoup moins de temps de traitement de votre application ou de votre serveur.

J'utilise habituellement SHA1 et salt avec l'ID utilisateur (ou une autre information spécifique à l'utilisateur), et parfois j'utilise également un sel constant (donc j'ai 2 parties dans le sel).

SHA1 est maintenant également considéré comme quelque peu compromis, mais dans une bien moindre mesure que MD5. En utilisant un sel (n'importe quel sel), vous empêchez l'utilisation d'un tableau arc-en-ciel générique pour attaquez vos hashes (certaines personnes ont même réussi à utiliser Google comme une sorte de table arc-en-ciel en recherchant le hash). Un attaquant pourrait générer une table arc-en-ciel en utilisant votre sel. C'est pourquoi vous devriez inclure un sel spécifique à l'utilisateur. De cette façon, ils devront générer une table arc-en-ciel pour chaque enregistrement de votre système, et pas seulement un pour l'ensemble de votre système! Avec ce type de salage, même le MD5 est bien sécurisé.

SHA1 et un sel devraient suffire (selon, naturellement, si vous codez quelque chose pour Fort Knox ou un système de connexion pour votre liste de courses) dans un avenir prévisible. Si SHA1 ne vous convient pas, utilisez SHA256 .

L’idée d’un sel est de déséquilibrer les résultats de hachage, pour ainsi dire. Par exemple, il est connu que le hachage MD5 d'une chaîne vide est d41d8cd98f00b204e9800998ecf8427e . Donc, si quelqu'un avec suffisamment de mémoire verrait ce hachage et saurait que c'est le hachage 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" (c'est-à-dire " MY_PERSONAL_SALT ") devient aeac2612626724592271634fb14d3ea6 , par conséquent, il n’est pas évident de revenir en arrière. Ce que j'essaie de dire, c'est qu'il vaut mieux utiliser n'importe quel sel que de ne pas le faire. Par conséquent, il n’est pas très important de savoir quel sel utiliser.

Il existe en fait des sites Web qui ne font que cela - vous pouvez le nourrir avec un hachage (md5), et il crache un texte en clair connu qui génère ce hachage particulier. Si vous pouviez accéder à une base de données qui stocke des hachages md5 simples, il serait facile de saisir le hachage de l'administrateur pour un tel service et de vous connecter. Toutefois, si les mots de passe étaient salés, un tel service deviendrait inefficace.

De plus, le double hachage est généralement considéré comme une mauvaise méthode car il diminue l’espace de résultat. Tous les hachages populaires ont une longueur fixe. Ainsi, vous ne pouvez avoir qu'une valeur finie de cette longueur fixe et les résultats deviennent moins variés. Cela pourrait être considéré comme une autre forme de salage, mais je ne le recommanderais pas.

ok dans la crise nous avons besoin de sel le sel doit être unique alors laissez le 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 du hash J'utilise sha512 c'est le meilleur et c'est en php

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

alors nous pouvons utiliser cette fonction pour générer un mot de passe sécurisé

// 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 devons enregistrer dans la base de données notre valeur de variable $ hash_psw et notre variable $ salt

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

c’est le meilleur moyen de sécuriser les mots de passe de nos clients ...

P.s. pour les 2 dernières étapes, vous pouvez utiliser votre propre algorithme ... mais assurez-vous que vous pouvez générer ce mot de passe haché à l'avenir lorsque vous devez autoriser un utilisateur ...

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow