password_bcrypt - php hash password online




Hash sécurisé et sel pour les mots de passe PHP (10)

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 "double hashing" est un mot de passe moins sécurisé que juste le hacher une fois? 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. 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


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

Depuis lors, PHP nous a donné php.net/manual/en/function.password-hash.php et password_verify et, depuis leur introduction, ils sont la méthode de hachage et de vérification de mot de passe recommandée.

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 s'il a perdu le sien et que vous lui avez envoyé un mot de passe temporaire.
  • Jamais, jamais enregistrer les mots de passe de quelque manière que ce soit.
  • Jamais hash mots de passe avec SHA1 ou MD5 ou même SHA256! Les craquelins modernes peuvent dépasser 60 et 180 milliards de hachages / seconde (respectivement).
  • Ne mélangez pas bcrypt et avec la sortie brute de hash () , utilisez soit la sortie hexadécimale, soit la base64_encode. (Ceci s'applique à toute entrée qui peut contenir un \0 , 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. Ainsi, l'objectif du hachage par mot de passe est de dissuader un pirate 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 / 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 au moins verrouiller le système, sinon 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 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 bon mot de passe quand même?

Entropy (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!

L'entropie du mot de passe est approximated 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 sur l'entropie du mot de passe sur le site Crypto StackExchange . 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 d' une politique de mot de passe de X longueur avec X beaucoup de lettres, nombres, symboles, etc., peut effectivement 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 une gemme scrypt qui vous aidera, et Node.js a maintenant son propre paquet scrypt . Vous pouvez utiliser Scrypt en PHP via l'extension Scrypt ou l'extension Libsodium (les deux sont disponibles dans PECL).

Je suggère fortement de lire la documentation de la fonction crypt si vous voulez comprendre comment utiliser bcrypt, ou vous trouver un good wrapper ou utiliser quelque chose comme openwall.com/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. openwall.com/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 savez pas avec certitude 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 utilisateur peut tolérer. Le plus petit nombre que je recommanderais est 2500 tours. Assurez-vous également d'utiliser hash_hmac() s'il est disponible pour rendre l'opération plus difficile à reproduire.

Pratiques futures

Venir en PHP 5.5 est une bibliothèque complète de protection par mot de passe qui résout toute peine de travailler avec bcrypt. Alors que la plupart d'entre nous sont coincés avec PHP 5.2 et 5.3 dans les environnements les plus communs, en particulier les hôtes partagés, @ircmaxell a construit une 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 requise pour réellement cracker un mot de passe hashé 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 dès le départ . 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.


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 pour savoir si les hashs salés avec des bits aléatoires sont plus sûrs que ceux qui sont salés avec des sels supposés ou connus. 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 aura accès au hachage ainsi qu'au sel, donc que le sel soit aléatoire ou non, peu importe. L'attaquant pourra générer des tables arc-en-ciel pré-calculées pour casser le hachage. Voici la partie intéressante - il 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é au point d'accès sans fil. Au lieu de cela, il est haché avec votre SSID (le nom du 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 aurez besoin de connaître le mot de passe ainsi que le sel (nom du réseau). Church of Wifi a déjà des tables de hachage pré-calculées qui ont 1000 premiers 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 tableaux. En supposant que la victime utilise le SSID comme "a387csf3" et le mot de passe comme "123456", sera-t-il craqué par ces tables? Non! .. ça ne peut pas. Même si le mot de passe est faible, les tables n'ont pas de hash pour le SSID a387csf3. C'est la beauté d'avoir du sel au hasard. Cela dissuadera les craqueurs qui prospèrent sur des tables pré-calculées. Peut-il arrêter un hacker déterminé? Probablement pas. Mais en utilisant des sels aléatoires fournit une couche supplémentaire de défense. Alors que nous sommes sur ce sujet, laissez-nous discuter de l'avantage supplémentaire de stocker des sels aléatoires sur un système distinct. Scénario 1: Les hachages de mot de passe sont stockés sur le système X et les valeurs salées utilisées pour le hachage sont stockées sur le système Y. Ces valeurs de sel sont devinables ou connues (par exemple, nom d'utilisateur) Scénario 2: Les hachages sont stockés sur le système X le hachage est stocké sur le système Y. Ces valeurs de sel sont aléatoires. Dans le cas où le système X a été compromis, comme vous pouvez le deviner, il y a un énorme avantage à utiliser du sel aléatoire sur un système séparé (Scénario # 2). L'attaquant devra deviner les valeurs d'addition pour être capable de casser les hachages. Si un sel de 32 bits est utilisé, 2 ^ 32 = 4 294 967 296 (environ 4,2 milliards), des itérations pourront être requises pour chaque mot de passe deviné.


En fin de compte, le double-hachage, mathématiquement, ne fournit aucun avantage. En pratique, cependant, il est utile pour empêcher les attaques à base de tables arc-en-ciel. En d'autres termes, cela n'a pas plus d'intérêt que le hachage avec un sel, ce qui prend beaucoup moins de temps processeur dans votre application ou sur votre serveur.


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.


J'utilise openwall.com/phpass qui est une simple classe PHP en un fichier qui pourrait être implémentée très facilement dans presque tous les projets PHP. Voir aussi The H.

Par défaut, il utilise le cryptage le plus fort disponible qui est implémenté dans Phpass, qui est bcrypt et revient à d'autres cryptage jusqu'à MD5 pour fournir une rétrocompatibilité 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);

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.


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

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 l'étirement du mot de passe et combien d'itérations devriez-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 processeurs beaucoup plus rapides et de l'utilisation de GPUs et FPGAs pour cracker les mots de passe. (avec les GPU).

Par exemple, vous pouvez craquer tous les mots de passe Windows à 8 caractères en 6 heures en utilisant 25 GPU installés sur 5 ordinateurs de bureau. C'est un forçage brutal, c'est-à-dire l'énumération et la vérification de tous les mots de passe Windows à 8 caractères , y compris les caractères spéciaux, et ce 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 dû au fait que Windows ne salit pas encore et n'explose pas 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 sur pourquoi password_hash() ou phpass sont la meilleure voie à suivre.
  • bon article de blog donnant des 'facteurs de travail' recommandés (nombre d'itérations) pour les algorithmes principaux incluant bcrypt, scrypt et PBKDF2.

SHA1 and a salt should suffice (depending, naturally, on whether you are coding something for Fort Knox or a login system for your shopping list) for the foreseeable future. If SHA1 isn't good enough for you, use SHA256 .

The idea of a salt is to throw the hashing results off balance, so to say. It is known, for example, that the MD5-hash of an empty string is d41d8cd98f00b204e9800998ecf8427e . So, if someone with good enough a memory would see that hash and know that it's the hash of an empty string. But if the string is salted (say, with the string " MY_PERSONAL_SALT "), the hash for the 'empty string' (ie " MY_PERSONAL_SALT ") becomes aeac2612626724592271634fb14d3ea6 , hence non-obvious to backtrace. What I'm trying to say, that it's better to use any salt, than not to. Therefore, it's not too much of an importance to know which salt to use.

There are actually websites that do just this - you can feed it a (md5) hash, and it spits out a known plaintext that generates that particular hash. If you would get access to a database that stores plain md5-hashes, it would be trivial for you to enter the hash for the admin to such a service, and log in. But, if the passwords were salted, such a service would become ineffective.

Also, double-hashing is generally regarded as bad method, because it diminishes the result space. All popular hashes are fixed-length. Thus, you can have only a finite values of this fixed length, and the results become less varied. This could be regarded as another form of salting, but I wouldn't recommend it.


I usually use SHA1 and salt with the user ID (or some other user-specific piece of information), and sometimes I additionally use a constant salt (so I have 2 parts to the salt).

SHA1 is now also considered somewhat compromised, but to a far lesser degree than MD5. By using a salt (any salt), you're preventing the use of a generic rainbow table to attack your hashes (some people have even had success using Google as a sort of rainbow table by searching for the hash). An attacker could conceivably generate a rainbow table using your salt, so that's why you should include a user-specific salt. That way, they will have to generate a rainbow table for each and every record in your system, not just one for your entire system! With that type of salting, even MD5 is decently secure.


ok in the fitsy we need salt salt must be unique so let generate it

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

also we need the hash I`m using sha512 it is the best and it is in php

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

so now we can use this functions to generate safe password

// 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);

now we need to save in database our $hash_psw variable value and $salt variable

and for authorize we will use same steps...

it is the best way to safe our clients passwords...

Ps for last 2 steps you can use your own algorithm... but be sure that you can generate this hashed password in the future when you need to authorize user...





protection