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

on dit actuellement que le MD5 est partiellement dangereux. En tenant compte de cela, j'aimerais savoir quel mécanisme utiliser pour la protection par mot de passe.

cette question, est-ce que" double hashing " est un mot de passe moins sûr qu'un simple hashing? suggère que le hachage à plusieurs reprises peut être une bonne idée, alors que comment mettre en œuvre la protection par mot de passe pour les 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. Hasher 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. être en sécurité
  3. il peut utiliser du sel (dans ce cas, tous les sels sont-ils également bons? Est-il un moyen de générer de bons sels?)

aussi, dois-je stocker deux champs dans la base de données (UN utilisant MD5 et un autre utilisant SHA, par exemple)? Est-ce plus sûr ou moins sûr?

dans le cas où je n'étais 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 de mot de passe sûr et rapide.

questions connexes qui ne couvrent pas tout à fait mon 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 des clés, des mots de passe pour asp.net

comment implémenter des mots de passe salés dans Tomcat 5.5

1064
demandé sur Community 2008-12-31 01:02:45

14 réponses

clause de non-responsabilité : 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 du mot de passe.

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

TL; DR

Don't

  • ne limitez pas les caractères que les utilisateurs peuvent entrer pour les mots de passe. Seuls les idiots font ça.
  • 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 conservez jamais le mot de passe de votre Utilisateur en clair.
  • N'envoyez jamais de mot de passe à votre utilisateur sauf s'ils ont perdu le leur, et vous avez envoyé un temporaire.
  • N'enregistrez jamais les mots de passe de quelque manière que ce soit.
  • Ne jamais hachez les mots de passe avec SHA1 ou MD5 ou même SHA256! craqueurs modernes peut dépasser 60 et 180 milliards de hashes/seconde (respectivement).
  • Ne pas mélanger bcrypt et avec le raw sortie de hash() , soit utiliser hex de sortie ou base64_encode. (Ceci s'applique à toute entrée qui peut avoir un "rogue 151920920" en elle, ce qui peut sérieusement affaiblir la sécurité.)

Dos

  • utilisez scrypt quand vous le pouvez; bcrypt si vous ne le pouvez pas.
  • utilisez PBKDF2 si vous ne pouvez pas utiliser bcrypt ou scrypt, avec des hachures SHA2.
  • réinitialise les mots de passe de tout le monde lorsque la base de données est compromise.
  • mettre en œuvre un longueur minimale raisonnable de 8 à 10 caractères, plus au moins une lettre majuscule, une lettre minuscule, un nombre et un symbole. Cela améliorera l'entropie du mot de passe, ce qui le rendra plus difficile à déchiffrer. (Voir "Qu'est-ce qui fait un bon mot de passe?"pour le débat.)

pourquoi hachez-vous les mots de passe?

l'objectif derrière le hachage des mots de passe est simple: empêcher l'accès malveillant aux comptes d'utilisateur en compromettant la base de données. Donc le but du hachage de mot de passe est de dissuader un hacker ou un cracker en leur coûtant trop de temps ou d'argent pour calculer les mots de passe en clair. Et le temps et le coût sont les meilleurs éléments dissuasifs de votre arsenal.

une autre raison pour laquelle vous voulez un bon et robuste hachage sur un compte 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 minimum verrouiller le système vers le bas, si non changer chaque mot de passe dans la base de données.

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

fait intéressant, en vivant ce cauchemar, j'ai appris beaucoup de choses que je ne connaissais pas sur le craquage de mot de passe, le stockage, et la complexité. j'ai fini par comprendre pourquoi le stockage par 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é, alors tout ce que vous pouvez vraiment dépendre est la complexité. cela pourrait être de notoriété publique pour les pros du mot de passe et de la cryptographie, mais pour le spécialiste moyen D'InfoSec ou de la sécurité Web, j'en doute fortement.

(l'Emphase est mienne.)

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

l'Entropie . (Pas Je suis entièrement d'accord avec le point de vue de Randall.)

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

mot de passe entropie est approximated facilement. L'utilisation de la gamme complète des caractères ascii (environ 96 caractères typographiques) 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 une sécurité future. Mais la bonne nouvelle est que les mots de passe plus longs, et les mots de passe avec des caractères unicode, augmentent vraiment l'entropie d'un mot de passe et le rendent plus difficile à déchiffrer.

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

dans les commentaires que j'ai parlé avec @popnoodles, qui a souligné que appliquer une politique de mot de passe de x longueur avec X beaucoup de lettres, de nombres, de symboles, etc, peut effectivement réduire l'entropie en rendant le schéma de mot de passe plus prévisible. Je suis d'accord. Aléatoire, comme vraiment aléatoire comme possible, est toujours la solution la plus sûre mais la moins mémorable.

d'après ce que j'ai pu dire, faire le meilleur mot de passe du monde est un hic-22. Soit son pas mémorable, trop prévisible, trop court, trop de caractères unicode (difficile à taper sur un Windows/appareil Mobile), trop long, etc. Aucun mot de passe n'est vraiment suffisant pour nos besoins, donc nous devons les protéger comme s'ils étaient à Fort Knox.

meilleures pratiques

Bcrypt et scrypt sont les meilleures pratiques actuelles. Scrypt sera meilleur que bcrypt dans le temps, mais il n'a pas vu l'adoption en tant que norme par Linux/Unix ou par les serveurs web, et n'a pas encore eu des revues en profondeur de son algorithme posté. Mais l'avenir de l'algorithme semble prometteur. Si vous travaillez avec Ruby il ya un scrypt gem qui vous aidera, et le noeud.js a maintenant son propre paquet scrypt . Vous pouvez utiliser Scrypt en PHP via l'extension Scrypt ou l'extension Libsodium (tous deux disponibles en PECL).

je suggère fortement de lire la documentation pour la fonction de cryptage si vous voulez comprendre comment utiliser bcrypt, ou de trouver vous-même 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 pas 15 à 18.

j'ai changé d'avis au sujet de l'utilisation de bcrypt quand j'ai appris que bcrypt utilise seulement l'horaire de 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 l'horaire de clé déjà coûteux de blowfish.

Moyenne "pratiques de 1519180920"

j'ai presque Je ne peux 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 savoir pour certain que votre environnement supporte bcrypt.

mais supposons que vous ne pouvez pas utiliser bcrypt ou PHPASS du tout. Alors, quoi?

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

Pratiques Futures

venant en PHP 5.5 est un bibliothèque de protection de mot de passe complète qui élimine toutes les douleurs de travailler avec bcrypt. Alors que la plupart d'entre nous sont bloqués avec PHP 5.2 et 5.3 dans la plupart des environnements communs, en particulier les hôtes partagés, @ircmaxell a construit une "couche de compatibilité" 15191540920 pour L'API à venir qui est rétro-compatible avec PHP 5.3.7.

Cryptographie Recap & Avertissement

la puissance de calcul nécessaire pour réellement crack un mot de passe hachée n'existe pas. La seule façon pour les ordinateurs de "cracker" un mot de passe est de le recréer et simuler l'algorithme de hachage utilisé pour le fixer. La vitesse du hachage est en relation linéaire avec sa capacité à être brutalement forcé. Pire encore, la plupart des algorithmes de hachage peuvent être facilement parallélisés pour effectuer encore plus rapidement. C'est pourquoi coûteux programmes comme bcrypt et scrypt sont si importants.

vous ne pouvez pas prévoir toutes les menaces ou les voies d'attaque, et vous devez donc faire de votre mieux pour protéger vos utilisateurs up front . Si vous ne le faites pas, alors 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, agir paranoïaque pour commencer. Attaquez votre propre logiciel (en interne) et tentez de voler les justificatifs d'identité des utilisateurs, 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, alors vous ne pouvez blâmer personne d'autre que vous-même.

enfin: je ne suis pas un cryptographe. Ce que j'ai dit est mon opinion, mais je pense que c'est basé sur le bon vieux sens commun ... et beaucoup de lecture. Rappelez-vous, être aussi paranoïaque que possible, rendre les choses aussi difficile à intrus que possible, et puis, si vous êtes toujours inquiet, contacter un hacker ou un cryptographe de chapeau blanc pour voir ce qu'ils disent à propos de votre code/système.

903
répondu Robert K 2017-05-23 12:10:41

une réponse beaucoup plus courte et plus sûre - n'écrivez pas 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 partie du coeur de PHP.
  • anciennes versions PHP: Openwall's phpass Bibliothèque est beaucoup mieux que la plupart du code personnalisé - utilisé 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 des vulnérabilités.

auto-test rapide: qu'est-ce que l'étirement du mot de passe et combien d'itérations devez-vous utiliser? Si vous ne connaissez pas la réponse, vous devriez utiliser password_hash() , car l'étirement du mot de passe est maintenant une caractéristique critique des mécanismes de mot de passe en raison de CPU beaucoup plus rapide et l'utilisation de GPUs et FPGAs pour craquer mots de passe à des taux de milliards de conjectures par seconde (avec GPUs).

par exemple, vous pouvez fissurer tous les mots de passe de 8 caractères de Windows en 6 heures en utilisant 25 GPUs installés dans 5 ordinateurs de bureau. Il s'agit de forcer brutalement c.-à-d. en énumérant et en vérifiant chaque mot de passe de Windows de 8 caractères , y compris les caractères spéciaux, et n'est pas une attaque de dictionnaire. C'était en 2012, à partir de 2018 on pouvait utiliser moins de Gpu, ou craquent plus vite avec 25 GPUs.

il y a aussi beaucoup d'attaques de table arc-en-ciel sur les mots de passe de Windows qui fonctionnent sur les CPU ordinaires et sont très rapides. Tout cela parce que Windows encore ne salt ou stretch ses mots de passe, même dans Windows 10 - ne faites pas la même erreur que Microsoft!

Voir aussi:

  • excellente réponse avec plus sur les raisons de password_hash() ou phpass sont la meilleure façon d'aller.
  • bon article du blog donner recommandés travail des facteurs (nombre d'itérations) pour les principaux algorithmes, y compris bcrypt, scrypt et PBKDF2.
120
répondu RichVel 2018-03-20 09:48:43

Je ne stockerais pas le mot de passe hachée de deux façons différentes, parce qu'alors le système est au moins aussi faible que le plus faible des algorithmes de hachage en usage.

40
répondu Tom Haigh 2013-01-17 14:22:05

depuis PHP 5.5, PHP a des 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 hash produit (avec le coût et l'algorithme utilisés.) password_verify() lit alors que le hachage et détermine le sel et la méthode de cryptage utilisés, et le vérifie par rapport à la mot de passe en clair.

fournit le PASSWORD_DEFAULT demande à 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 sera toujours l'un des algorithmes disponibles les plus forts.

Augmentation du coût (qui est par défaut à 10) rend le hachage plus difficile à brute-force, mais signifie également générer des hachages et de vérifier les mots de passe contre eux seront plus de travail pour le CPU de votre serveur.

notez que même si l'algorithme de hachage par défaut peut changer, les vieux hachages continueront à vérifier très bien parce que l'algorithme utilisé est stocké dans le hachage et password_verify() ramasse dessus.

31
répondu AlliterativeAlice 2015-08-25 19:08:11

bien que la question ait été répondue, je veux juste répéter que les sels utilisés pour le hachage doivent être aléatoires et pas comme l'adresse e-mail comme suggéré dans la première réponse.

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

récemment j'ai eu une discussion si le mot de passe hashes salé au hasard les bits sont plus sûrs que l'un salé avec des suppositions ou connu sel. Voyons voir: si le système stockant le mot de passe est compromis comme ainsi que le système qui stocke le sel aléatoire, l'attaquant avoir accès au hash ainsi que le sel, si le sel est aléatoire ou pas, n'a pas d'importance. L'attaquant va pouvoir générer précalculé des tables arc-en-ciel pour casser le hachage. Voici la partie intéressante - il n'est pas si trivial pour générer des tables pré-calculées. Laissez-nous prendre exemple du modèle de sécurité WPA. Votre mot de passe WPA est en fait, jamais envoyé Point D'Accès Sans Fil. Au lieu de cela, il est hashé avec votre SSID (le nom du réseau: Linksys, Dlink, etc.). Une très bonne explication de comment 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 Wifi a déjà pré-calculé des tables de hachage qui a le top 1000 SSIDs et environ 1 million de mots de passe. La taille de tous les tableaux 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 le mot de passe comme "123456", sera-t-il craqué par ceux les tables? Pas de! .. il ne peut pas. Même si le mot est faible, les tables Je n'ai pas de hashes pour SSID a387csf3. C'est la beauté d'avoir aléatoire de sel. Il dissuadera les pirates qui prospèrent sur pré-calculé table. Peut-il arrêter déterminé un hacker? Probablement pas. Mais à l'aide de les sels aléatoires fournissent une couche de défense supplémentaire. Alors que nous sommes sur ce sujet, discutons l'avantage supplémentaire de stocker aléatoire sels sur un autre système. Scénario n ° 1 : les hachages de mot 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 estimées ou sont connues (p. ex. nom d'utilisateur) scénario 2 : Les hachages de mot de passe sont stockés sur les valeurs du système X et du sel le hachage est stocké sur le système Y. Ces valeurs de sel sont aléatoires. En cas le système X a été compromis, comme vous pouvez le deviner, il y a un énorme avantage de l'utilisation du sel aléatoire sur un système distinct (scénario 2) . L'attaquant aura besoin de deviner des valeurs supplémentaires pour être en mesure de se fissurer hachage. Si l'on utilise un sel de 32 bits, 2^32= 4.294.967.296 (environ 4.2 des itérations peuvent être nécessaires pour chaque mot de passe estimé.

30
répondu Gaurav Kumar 2012-06-27 16:10:17

je veux juste souligner que PHP 5.5 inclut une API de hachage de mot de passe qui fournit une enveloppe autour de crypt() . Cette API simplifie considérablement la tâche de hachage, de vérification et de reformulation des hachages de mots de passe. L'auteur a également publié un compatibilité pack (sous la forme d'un mot de passe unique.php fichier que vous simplement require à utiliser), pour ceux qui utilisent PHP 5.3.7 et plus tard et que vous voulez utiliser ce droit maintenant.

il ne supporte BCRYPT pour le moment, mais il vise à être facilement étendu pour inclure d'autres techniques de hachage de mot de passe et parce que la technique et le coût est stocké dans le cadre du hachage, les changements à votre technique/coût de hachage préférées n'invalidera pas les hachages actuels, le cadre sera automatiquement, utiliser la technique/coût correcte 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() - 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 technique actuelle/schéma de coût 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 PASSWORD_BCRYPT et PASSWORD_DEFAULT password, qui sont synonymes pour le moment, la différence étant que PASSWORD_DEFAULT "peut changer dans les nouvelles versions de PHP lorsque de nouveaux algorithmes de hachage plus forts sont pris en charge."En utilisant PASSWORD_DEFAULT et password_needs_rehash() lors de la connexion (et en ressassant si nécessaire) devrait s'assurer que vos hashs sont raisonnablement résistants aux attaques brutales avec peu ou pas de travail pour vous.

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

25
répondu JonoCoetzee 2014-07-06 14:08:05

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

par défaut, il a utilisé le cryptage le plus fort disponible qui est mis en œuvre dans Phpass, qui est bcrypt et retombe à d'autres cryptages jusqu'à MD5 pour fournir rétrocompatibilité à des cadres comme Wordpress.

le hash retourné pourrait être stockés dans la base de données. Exemple d'utilisation pour la production de hash:

$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
répondu rabudde 2012-06-26 08:05:12

CHOSES À RETENIR

beaucoup de choses ont été dites sur le cryptage de mot de passe pour PHP, dont la plupart sont de très bons conseils, mais avant même de commencer le processus D'utilisation de PHP pour le cryptage de mot de passe assurez-vous que vous avez mis en œuvre ou prêt à être mis en œuvre.

SERVEUR

PORTS

peu importe à quel point votre le cryptage est si vous ne sécurisez pas correctement le serveur qui exécute le PHP et la 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 soit par ftp ou shell. Assurez-vous de changer le port par défaut de la connexion distante que vous avez active. En ne le faisant pas, vous avez en effet fait faire à l'attaquant une étape 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 unix, ne rendez pas l'ouverture de session du compte root accessible, elle doit toujours être sudo seulement.

mot de passe

vous dites à vos utilisateurs de faire de bons mots de passe pour éviter d'être piraté, faites de même. Quel est l'intérêt de passer par tous les efforts de verrouiller votre porte d'entrée lorsque vous avez la porte dérobée ouverte.

base de données

SERVEUR

Idéalement, vous voulez votre DB et APPLICATION sur des serveurs séparés. Ce n'est pas toujours possible en raison du coût, mais cela permet une certaine sécurité car l'attaquant devra passer par deux étapes pour accéder pleinement au système.

utilisateur

Always ayez votre application avoir son propre compte pour accéder à la DB, et ne lui donner que les privilèges dont elle aura besoin.

alors avoir un compte d'utilisateur séparé pour vous qui n'est pas stocké n'importe où 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 qu'avec tous les bons mots de passe. Aussi, ne pas réutiliser le même mot de passe sur N'importe quel compte serveur ou DB sur le même système.

PHP

mot de passe

ne stockez jamais de mot de passe dans votre base de données, au lieu de stocker le hash et le sel unique, je vous expliquerai pourquoi plus tard.

"1519130920 de" HACHAGE

À SENS UNIQUE!!!!!!!, Jamais de hachage d'un mot de passe de sorte qu'il peut être inversée, de la cendre devrait être un chemin, ce qui signifie que vous ne les inversez pas et les comparez au mot de passe, vous hachez le mot de passe entré de la même façon et comparez les deux hachages. Cela signifie que même si un attaquant obtient l'accès à la base de données il ne sait pas ce que le mot de passe est réellement, juste son hachage résultant. 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 d' pour sélectionner un bon algorithme de hachage pour être efficace. (bcrypt et ceux similaires sont décents algorithmes.)

quand la vitesse de hashage est la clé, le plus lent est le plus résistant aux attaques par la force Brute.

L'une des erreurs les plus fréquentes en matière de hachage est que les hachures ne sont pas uniques aux utilisateurs. Ceci est principalement dû au fait que les sels ne sont pas produits uniquement.

salaison

mots de passe il faut toujours le saler avant de le hacher. Salting ajoute une chaîne de caractères aléatoire au mot de passe pour que des mots de passe similaires n'apparaissent pas les mêmes dans la base de données. Toutefois, si le sel n'est pas propre à chaque utilisateur (c.-à-d. que vous utilisez un sel codé dur) que vous avez pratiquement 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 au mot de passe qu'il est salting, puis stocker à la fois le hachage terminé et le sel dans votre base de données. Ce que cela va faire est de faire en sorte qu'un attaquant devra individuellement craquer chaque sel et le hachage avant qu'ils ne puissent obtenir l'accès. Cela signifie beaucoup plus de temps et de travail pour l'attaquant.

UTILISATEURS CRÉANT DES MOTS DE PASSE

si l'utilisateur crée un mot de passe par l'intermédiaire de l'interface, cela signifie qu'il doit être envoyé au serveur. Cela ouvre un problème de sécurité parce que 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 que toute votre sécurité en PHP est sans valeur. Transmettez toujours les données en toute sécurité, Ceci est fait par SSL, mais soyez las, même SSL n'est pas sans faille (la faille Heartbleed D'OpenSSL en est un exemple).

aussi faire l'utilisateur Créer un mot de passe sécurisé, il est simple et doit toujours être fait, l'Utilisateur sera reconnaissant pour lui à 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 sont avancées. Mais en suivant ces étapes rendra votre site plus sûr et beaucoup moins souhaitable pour les attaquants d'aller après.

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

http://git.io/mSJqpw

13
répondu wmfrancia 2014-07-07 19:38:53

Google dit que SHA256 est disponible pour PHP.

Vous devriez certainement utiliser un sel. Je recommande d'utiliser des octets aléatoires (et de ne pas vous limiter aux caractères et aux nombres). Comme d'habitude, plus vous choisissez, plus il devient sûr, plus il ralentit. 64 octets devraient suffire, je suppose.

12
répondu AticusFinch 2008-12-30 22:20:54

j'ai trouvé le sujet parfait sur cette question ici: https://crackstation.net/hashing-security.htm , je voulais que vous en tiriez profit, voici le code source qui fournit aussi une prévention contre 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));
}
?>
8
répondu Jason OOO 2013-09-19 13:26:29

en fin de compte, le double-hachage, mathématiquement, ne fournit aucun avantage. Dans la pratique, cependant, il est utile pour prévenir les attaques basées sur des tables arc-en-ciel. 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.

7
répondu Max 2008-12-30 22:29:28

j'utilise habituellement SHA1 et salt avec le nom d'utilisateur (ou un autre élément d'information spécifique à l'utilisateur), et parfois j'utilise en plus un sel constant (donc j'ai 2 parties au sel).

SHA1 est maintenant considéré comme quelque peu compromis, mais à un degré beaucoup plus faible que MD5. En utilisant un sel (n'importe quel sel), vous empêchez l'utilisation d'un générique table arc-en-ciel pour attaquer vos hash (certaines personnes ont même eu du succès en utilisant Google comme une sorte de table arc-en-ciel en cherchant le hachage). Un attaquant pourrait éventuellement 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 dans votre système, pas seulement un pour l'ensemble de votre système! Avec ce type de salage, même MD5 est décemment sûr.

6
répondu rmeador 2008-12-30 22:18:25

SHA1 et un sel devraient suffire (selon, naturellement, si vous codez quelque chose pour Fort Knox ou un système de login pour votre liste d'achats) 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. On sait, par exemple, que le hachage MD5 d'une chaîne vide est d41d8cd98f00b204e9800998ecf8427e . Donc, si quelqu'un avec assez de mémoire voyait ce hachage et savait que c'est le hachage d'une corde vide. Mais si la corde est salée (disons, avec la corde " MY_PERSONAL_SALT "), le hachage pour la 'corde vide' (i.e. " MY_PERSONAL_SALT ") devient aeac2612626724592271634fb14d3ea6 , donc non-évident à rétrograder. Ce que j'essaie de dire, c'est qu'il vaut mieux utiliser tout sel, que de ne pas le faire. Par conséquent, il n'est pas trop d'une importance de savoir qui sel à utiliser.

il y a en fait des sites Web qui font justement ceci - vous pouvez lui donner un hash (md5), et il crache un plaintext connu qui génère ce hash particulier. Si vous avez accès à une base de données qui stocke des MD5-hashes simples, il serait trivial pour vous d'entrer le hachage pour l'administrateur à un tel service, et se connecter. Mais, si les mots de passe étaient salés, un tel service deviendrait inefficace.

aussi, double-hashing est généralement considérée comme mauvaise méthode, parce qu'elle diminue l'espace de résultat. Tous les hashs populaires sont de longueur fixe. Ainsi, vous pouvez avoir seulement des valeurs finies de cette longueur fixe, et les résultats deviennent moins variés. Ce pourrait être considéré comme une autre forme de salage, mais je ne le recommande pas.

4
répondu Henrik Paul 2008-12-30 22:29:51

ok dans le fitsy nous avons besoin de sel le sel doit être unique alors laissez génèrent

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

nous avons aussi besoin du hash Je suis en utilisant sha512 c'est le meilleur et c'est en php

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

donc maintenant nous pouvons utiliser ces fonctions pour générer un 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 devons sauvegarder dans la base de données notre valeur variable $hash_psw et notre variable $salt

et pour autoriser nous utiliserons les mêmes étapes...

c'est la meilleure façon 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 hashé dans le futur lorsque vous devez autoriser l'utilisateur...

-5
répondu shalvasoft 2015-10-08 04:05:05