Question Hash sécurisé et sel pour les mots de passe PHP


On dit actuellement que MD5 est partiellement dangereux. En prenant cela en considération, j'aimerais savoir quel mécanisme utiliser pour la protection par mot de passe.

Cette question, Est-ce que le "double hachage" est un mot de passe moins sécurisé que juste le hacher une fois?  suggère que le hashing plusieurs fois peut être une bonne idée, alors que Comment mettre en place une protection par mot de passe pour des fichiers individuels? suggère d'utiliser du sel.

J'utilise PHP. Je veux un système de cryptage de mot de passe sûr et rapide. Hacher 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é? Aussi, je préférerais que le résultat ait un nombre constant de caractères.

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

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

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

Questions connexes qui ne couvrent pas tout à fait ma question:

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


1049
2017-12-30 22:02


origine


Réponses:


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

Depuis lors, PHP nous a donné password_hash et password_verify et, depuis leur introduction, ils sont la méthode recommandée de hachage et de vérification de mot de passe.

La théorie de la réponse est encore une bonne lecture cependant.

TL; DR

Ne pas faire

  • Ne limitez pas les caractères que les utilisateurs peuvent entrer 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 avec supercalifragilisticexpialidocious, ne les empêchez pas de l'utiliser.
  • Ne stockez jamais le mot de passe de votre utilisateur en texte brut.
  • N'envoyez jamais de mot de passe à votre utilisateur sauf quand ils ont perdu le leur, et vous avez envoyé un temporaire.
  • Jamais, jamais enregistrer les mots de passe de quelque manière que ce soit.
  • Ne jamais hash mots de passe avec SHA1 ou MD5 ou même SHA256! Craquelins modernes peut dépasser 60 et 180 milliards de hachages / seconde (respectivement).
  • Ne pas mélanger bcrypt et avec le brut sortie de hachage (), utilisez soit la sortie hexadécimale, soit la base64_encode. (Cela s'applique à toute entrée qui peut avoir un voyou \0 dedans, 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 pas utiliser bcrypt ou scrypt, avec des hachages SHA2.
  • Réinitialiser les mots de passe de tout le monde lorsque la base de données est compromise.
  • Mettre en œuvre une longueur minimale raisonnable de 8 à 10 caractères, en plus d'exiger 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 à déchiffrer. (Voir la section "Qu'est-ce qui fait un bon mot de passe?" Pour un débat.)

Pourquoi hacher les mots de passe quand même?

L'objectif derrière le hachage des mots de passe est simple: empêcher l'accès malveillant aux comptes d'utilisateurs en compromettant la base de données. L'objectif du hachage par mot de passe est donc de dissuader un pirate ou un hacker en lui coûtant trop de temps ou d'argent pour calculer les mots de passe en texte clair. Et le temps / coût sont les meilleurs moyens de dissuasion dans votre arsenal.

Une autre raison pour laquelle vous voulez un bon hachage robuste sur un compte d'utilisateur est de vous donner assez 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 moins verrouillez le système, sinon changez chaque mot de passe dans la base de données.

Jeremiah Grossman, directeur technique de Whitehat Security, a déclaré sur son blog après une récente récupération de mot de passe qui a nécessité une rupture brutale de sa protection par mot de passe:

Fait intéressant, en vivant ce cauchemar, j'ai appris BEAUCOUP que je ne savais pas sur le mot de passe cracking, le stockage et la complexité. J'ai appris à comprendre pourquoi le stockage de mot de passe est toujours plus important que la complexité du mot de passe. Si vous ne savez pas comment votre mot de passe est stocké, tout ce sur quoi vous pouvez réellement compter est la complexité. Cela peut être une connaissance courante du mot de passe et des professionnels de la crypto, mais pour l'expert InfoSec ou Web Security moyen, j'en doute fortement.

(Emphase la mienne.)

Qu'est-ce qui fait un bien mot de passe quand même?

Entropie. (Pas que je souscris pleinement au point de vue de Randall.)

En bref, l'entropie est la quantité de variation dans le mot de passe. Quand un mot de passe est seulement en minuscules romaines, ce n'est que 26 caractères. Ce n'est pas beaucoup de variation. Les mots de passe alphanumériques sont meilleurs, avec 36 caractères. Mais autoriser les majuscules et minuscules, avec des symboles, est d'environ 96 caractères. C'est beaucoup mieux que des lettres. Un problème est que, pour rendre nos mots de passe mémorisables, nous insérons des motifs, ce qui réduit l'entropie. Oops!

Le mot de passe entropy est approché facilement. L'utilisation de la gamme complète de caractères ascii (environ 96 caractères typables) donne une entropie de 6,6 par caractère, ce qui à 8 caractères pour un mot de passe est encore trop faible (52,679 bits d'entropie) pour la sécurité future. Mais les bonnes nouvelles sont: des mots de passe plus longs, et des mots de passe avec des caractères Unicode, augmentent vraiment l'entropie d'un mot de passe et le rendent plus difficile à cracker.

Il y a une discussion plus longue de l'entropie de mot de passe sur le Crypto StackExchange site. Une bonne recherche sur Google donnera aussi beaucoup de résultats.

Dans les commentaires, j'ai parlé avec @popnoodles, qui a souligné que l'application une politique de mot de passe de longueur X avec X beaucoup de 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. Randomess, aussi aléatoire que possible, est toujours la solution la plus sûre mais la moins mémorable.

Autant que j'ai pu le dire, faire le 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 assez bon pour nos besoins, nous devons donc les protéger comme s'ils étaient à Fort Knox.

Les meilleures pratiques

Bcrypt et scrypt sont les meilleures pratiques actuelles. Scrypt sera meilleur que bcrypt dans le temps, mais il n'a pas été adopté comme standard par Linux / Unix ou par les serveurs web, et n'a pas encore fait l'objet de critiques approfondies de son algorithme. Mais encore, l'avenir de l'algorithme semble prometteur. Si vous travaillez avec Ruby il y a un scrypt gemme cela 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 suggère fortement de lire la documentation pour le fonction crypt si vous voulez comprendre comment utiliser bcrypt, ou vous trouver un bien  wrapper ou utiliser quelque chose comme PHPASS pour une implémentation plus ancienne. Je recommande un minimum de 12 tours de bcrypt, sinon 15 à 18.

J'ai changé d'avis à propos de l'utilisation de bcrypt quand j'ai appris que bcrypt n'utilisait que la programmation clé de blowfish, avec un mécanisme de coût variable. Ce dernier vous permet d'augmenter le coût de la force brute d'un mot de passe en augmentant le programme clé déjà cher de blowfish.

Pratiques moyennes

Je ne peux presque plus imaginer cette situation. PHPASS supporte PHP 3.0.18 à 5.3, donc il est utilisable sur presque toutes les installations imaginables - et devrait être utilisé si vous ne le faites pas savoir pour certain que votre environnement supporte bcrypt.

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

Essayez une implémentation de PDKBF2 avec le nombre maximum de tours que votre environnement / application / perception de l'utilisateur peut tolérer. Le plus petit nombre que je recommanderais est 2500 tours. Aussi, assurez-vous d'utiliser hash_hmac () s'il est disponible pour rendre l'opération plus difficile à reproduire.

Pratiques futures

Venir en PHP 5.5 est un bibliothèque complète de protection par mot de passe cela résout toute peine de travailler avec bcrypt. Alors que la plupart d'entre nous sommes coincés avec PHP 5.2 et 5.3 dans les environnements les plus courants, en particulier les hôtes partagés, @ircmaxell a construit un couche de compatibilité pour l'API à venir qui est rétrocompatible avec PHP 5.3.7.

Récapitulatif de la cryptographie et avis de non-responsabilité

La puissance de calcul nécessaire pour réellement fissure un mot de passe haché n'existe pas. La seule façon pour les ordinateurs de "casser" un mot de passe est de le recréer et de simuler l'algorithme de hachage utilisé pour le sécuriser. La vitesse du hachage est liée linéairement à sa capacité à être brutalement forcé. Pire encore, la plupart des algorithmes de hachage peuvent être facilement parallélisés pour fonctionner encore plus rapidement. C'est pourquoi des systèmes coûteux comme bcrypt et scrypt sont si importants.

Vous ne pouvez pas prévoir toutes les menaces ou voies d'attaque, et vous devez donc faire de votre mieux pour protéger vos utilisateurs à l'avant. Si vous ne le faites pas, vous pourriez même manquer le fait que vous avez été attaqué jusqu'à ce qu'il soit trop tard ... et vous êtes responsable. Pour éviter cette situation, agissez paranoïaque pour commencer. 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 pas blâmer qui que ce soit, sauf vous-même.

Enfin: je ne suis pas un cryptographe. Tout ce que j'ai dit est mon opinion, mais je pense que c'est basé sur le bon sens du bon sens ... et beaucoup de lecture. Rappelez-vous, soyez aussi paranoïaque que possible, faites en sorte que les choses soient aussi difficiles que possible, et si vous êtes encore inquiet, contactez un pirate ou un cryptographe pour voir ce qu'ils disent de votre code / système.


892
2017-12-30 22:15



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

  • PHP 5.5 ou supérieur: password_hash () est de bonne qualité et fait partie du noyau PHP.
  • Anciennes versions de PHP: OpenWall's phpass la bibliothèque est beaucoup mieux que la plupart des codes personnalisés - utilisés dans WordPress, Drupal, etc.

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

Auto-test rapide: qu'est-ce que le mot de passe étirement et combien d'itérations devriez-vous utiliser? Si vous ne connaissez pas la réponse, vous devez utiliser password_hash(), puisque l'étirement du mot de passe est maintenant une caractéristique critique des mécanismes de mot de passe en raison de processeurs beaucoup plus rapides et de l'utilisation de GPU et FPGA pour casser les mots de passe à des taux de des milliards de suppositions par seconde (avec les GPU).

Par exemple, vous pouvez cracker tous les mots de passe Windows à 8 caractères en 6 heures en utilisant 25 GPU installés dans 5 PC de bureau. Ceci est un forçage brutal, c'est-à-dire l'énumération et la vérification chaque mot de passe Windows à 8 caractères, y compris les caractères spéciaux, et n'est pas une attaque par dictionnaire. C'était en 2012, à partir de 2018, vous pourriez utiliser moins de GPU, ou craquer plus vite avec 25 GPU.

Il y a aussi de nombreuses attaques de tables arc-en-ciel sur les mots de passe Windows qui s'exécutent sur des processeurs ordinaires et qui sont très rapides. Tout cela est parce que Windows encore  ne pas saler ou étirer ses mots de passe, même dans Windows 10 - Ne faites pas la même erreur que Microsoft!

Voir également: 

  • excellente réponse avec plus d'informations sur pourquoi password_hash() ou phpass sont le meilleur moyen d'y aller.
  • bon article de blog donner des 'facteurs de travail' recommandés (nombre d'itérations) pour les algorithmes principaux incluant bcrypt, scrypt et PBKDF2.

120
2017-11-08 12:02



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


40
2017-12-30 22:18



Bien que la question ait été résolue, je veux juste réitérer que les sels utilisés pour le hachage devraient être aléatoires et ne pas être comme l'adresse e-mail comme suggéré dans la première réponse.

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

Récemment j'ai eu une discussion si les hachages de mot de passe salés avec aléatoire   les bits sont plus sûrs que celui salé avec guessable ou connu   sels. Voyons voir: si le système stockant le mot de passe est compromis   ainsi que le système qui stocke le sel aléatoire, l'attaquant   avoir accès à du hasch ainsi que du sel, donc si le sel est aléatoire ou   pas, pas d'importance. L'attaquant pourra générer des données pré-calculées   tables arc-en-ciel pour casser le hachage. Voici la partie intéressante   n'est pas si trivial 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 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 comment   cela fonctionne 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   Wifi a déjà pré-calculé des tables de hachage qui a top 1000 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 tableaux FGPA pendant 3 jours   pour générer ces tables. En supposant que la victime utilise le SSID comme   "A387csf3" et mot de passe comme "123456", sera-t-il craqué par ceux   les tables? Non! .. ça ne peut pas. Même si le mot de passe est faible, les tables   n'ont pas de hachages pour le SSID a387csf3. C'est la beauté d'avoir   sel aléatoire. Cela dissuadera les craqueurs qui prospèrent grâce à des calculs pré-calculés   les tables. Peut-il arrêter un hacker 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 de l'avantage supplémentaire de stocker au hasard   sels sur un système séparé. Scénario n ° 1: Les hachages de mots de passe sont stockés   sur le système X et les valeurs de sel utilisées pour le hachage sont stockées sur le système Y.   Ces valeurs de sel peuvent être devinées ou connues (par exemple, nom d'utilisateur) Scénario n ° 2:   Les hashs de mot 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ù   système X a été compromise, comme vous pouvez le deviner, il y a un énorme   avantage d'utiliser du sel aléatoire sur un système séparé (Scénario # 2).   L'attaquant devra deviner des valeurs d'addition pour pouvoir se fissurer   hashes. Si un sel de 32 bits est utilisé, 2 ^ 32 = 4,294,967,296 (environ 4,2   milliards) des itérations seront nécessaires pour chaque mot de passe deviné.


30
2018-02-12 00:52



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

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

Fournir le PASSWORD_DEFAULT demande à PHP d'utiliser l'algorithme de hachage par défaut de la version installée de PHP. Quel algorithme précis cela signifie est destiné à changer au fil du temps dans les versions futures, de sorte qu'il sera toujours l'un des algorithmes les plus forts disponibles.

L'augmentation du coût (qui vaut par défaut 10) rend le hachage plus difficile à force brute mais signifie également générer des hachages et vérifier les mots de passe contre eux, ce qui sera plus de travail pour le processeur de votre serveur.

Notez que même si l'algorithme de hachage par défaut peut changer, les anciens hash continueront à être vérifiés car l'algorithme utilisé est stocké dans le hash et password_verify() ramasse dessus.


30
2017-09-21 21:33



Je veux juste souligner que PHP 5.5 comprend un mot de passe hashing qui fournit une enveloppe autour crypt(). Cette API simplifie considérablement la tâche de hachage, de vérification et de ressassement des hachages de mots de passe. L'auteur a également publié un pack de compatibilité (sous la forme d'un seul fichier password.php que vous avez simplement require à utiliser), pour ceux qui utilisent PHP 5.3.7 et les versions ultérieures et que vous souhaitez utiliser dès maintenant.

Il ne supporte que BCRYPT pour l'instant, mais il a pour but d'ê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 de votre technique de hachage préférée n'invalideront pas les hachages actuels. utilisera automagiquement la bonne technique / coût lors de la validation. Il gère également la génération d'un sel "sécurisé" si vous ne définissez pas explicitement le vôtre.

L'API expose quatre fonctions:

  • password_get_info() - renvoie des informations sur le hachage donné
  • password_hash() - crée un hachage de mot de passe
  • password_needs_rehash() - vérifie si le hash 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

Au moment où ces fonctions acceptent les constantes de mot de passe PASSWORD_BCRYPT et PASSWORD_DEFAULT, qui sont pour le moment, la différence étant que PASSWORD_DEFAULT "peut changer dans les nouvelles versions de PHP quand de nouveaux algorithmes de hachage plus forts sont supportés." L'utilisation de PASSWORD_DEFAULT et de password_needs_rehash () lors de la connexion (et du rehashing si nécessaire) devrait garantir que vos hachages sont raisonnablement résilients aux attaques par force brute avec peu ou pas de travail pour vous.

EDIT: Je viens de réaliser que cela est mentionné brièvement dans la réponse de Robert K. Je vais laisser cette réponse ici car je pense qu'elle fournit un peu plus d'informations sur son fonctionnement et la facilité d'utilisation qu'elle offre à ceux qui ne connaissent pas la sécurité.


25
2018-04-27 21:41



j'utilise Phpass qui est une simple classe PHP à un fichier qui pourrait être implémentée très facilement dans presque tous les projets PHP. Voir également Le H.

Par défaut, il utilise le cryptage disponible le plus fort qui est implémenté dans Phpass, qui est bcrypt et retombe à d'autres cryptages jusqu'à MD5 pour fournir une compatibilité descendante avec des frameworks comme Wordpress.

Le hachage retourné pourrait être stocké dans la base de données telle qu'elle est. Exemple d'utilisation pour générer du 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);

17
2018-06-26 08:05



CHOSES DONT IL FAUT SE RAPPELER

On a beaucoup parlé du cryptage des mots de passe pour PHP, dont la plupart sont de très bons conseils, mais avant même de commencer à utiliser PHP pour le cryptage des mots de passe, assurez-vous d'avoir implémenté ou prêt à être implémenté.

SERVEUR

PORTS

Peu importe la qualité de votre cryptage si vous ne sécurisez pas correctement le serveur qui exécute PHP et DB, tous vos efforts sont sans valeur. La plupart des serveurs fonctionnent relativement de la même manière, ils ont des ports assigné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 à distance que vous avez active. En ne faisant pas cela, vous avez en fait obligé l'attaquant à faire un pas de moins dans l'accès à 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 utilisez un système basé sur UNIX, NE RENDEZ PAS le login du compte root, il devrait toujours être sudo.

MOT DE PASSE

Vous dites à vos utilisateurs de faire de bons mots de passe pour éviter de se faire pirater, faites de même. Quel est le point en faisant tous les efforts de verrouillage de votre porte d'entrée lorsque vous avez la porte arrière grande ouverte.

BASE DE DONNÉES

SERVEUR

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

UTILISATEUR

Faites en sorte que votre application dispose toujours de son propre compte pour accéder à la base de données et ne lui donne que les privilèges dont elle aura besoin.

Ayez alors pour vous un compte d'utilisateur distinct qui n'est stocké nulle part sur le serveur, 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 le même mot de passe sur des comptes SERVER ou DB sur le même système.

PHP

MOT DE PASSE

Ne jamais stocker un mot de passe dans votre base de données, à la place de stocker le hachage et le sel unique, je vais vous expliquer pourquoi plus tard.

HACHER

HASHING ONE WAY !!!!!!!, Jamais hash un mot de passe d'une manière qui peut être inversée, Hashes doit être à sens unique, ce qui signifie que vous ne les inversez pas et les comparer au mot de passe, vous hachez plutôt le mot de passe entré 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, juste le hash qui en résulte. Ce qui signifie plus de sécurité pour vos utilisateurs dans le pire des cas.

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

Lorsque la vitesse de hachage est la clé, la plus lente est la plus résistante aux attaques de force brute.

L'une des erreurs les plus courantes dans le hachage est que les hachages ne sont pas uniques aux utilisateurs. C'est principalement parce que les sels ne sont pas générés de manière unique.

SALAISON

Les mots de passe doivent toujours être salés avant d'être hachés. Salting ajoute une chaîne aléatoire au mot de passe afin que les mots de passe similaires n'apparaissent pas identiques dans la base de données. Toutefois, 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 fait de sel. Parce qu'une fois qu'un attaquant trouve un mot de passe, il a le sel pour chacun d'entre eux.

Lorsque vous créez un sel, assurez-vous qu'il est unique au mot de passe qu'il salage, puis stockez le hachage et le sel dans votre base de données. Ce que cela fera, c'est de faire en sorte qu'un attaquant devra craquer individuellement chaque sel et hachage 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 le frontal, cela 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 d'accéder, toute votre sécurité en PHP est sans valeur. TOUJOURS transmettre les données SÉCURITÉ, ceci est fait via SSL, mais soyez fatigué même SSL n'est pas parfait (la faille Heartbleed d'OpenSSL en est un exemple).

De plus, faites en sorte que l'utilisateur crée un mot de passe sécurisé, c'est simple et doit toujours être fait, l'utilisateur sera reconnaissant à la fin.

Enfin, peu importe les mesures de sécurité que vous prenez, rien n'est sûr à 100%. Plus la technologie à protéger est avancée, plus les attaques deviennent avancées. Mais suivre ces étapes rendra votre site plus sûr et moins souhaitable pour les attaquants.

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

http://git.io/mSJqpw


13
2018-04-09 15:01



Google dit que SHA256 est disponible pour PHP.

Vous devriez certainement utiliser un sel. Je vous recommande d'utiliser des octets aléatoires (et ne vous limitez pas aux caractères et aux nombres). Comme d'habitude, plus vous choisissez, plus c'est sécuritaire et lent. 64 octets devraient être bien, je suppose.


12
2017-12-30 22:20