A quoi sert md5 ()?
j'étais en train de lire ce tutoriel pour un simple PHP login system .
à la fin, il recommande que vous devez chiffrer votre mot de passe en utilisant md5 () .
même si je sais que c'est un tutoriel pour débutants, et que vous ne devriez pas mettre de relevés bancaires derrière ce système de connexion, cela m'a amené à penser au cryptage.
alors je suis allé de l'avant et est allé à (une des questions les plus utiles ce le site a pour débutants): Qu'un développeur doit-il savoir avant de construire un site web public?
là, il est dit (sous la sécurité) que vous devriez:
Crypterde Hachage et le sel des mots de passe plutôt que de les stocker en texte brut.
il n'en dit pas plus, pas de références.
alors je suis allé de l'avant et essayé moi-même:
$pass = "Trufa";
$enc = md5($pass);
echo $enc; #will echo 06cb51ce0a9893ec1d2dce07ba5ba710
et c'est ce qui m'a amené à penser, que même si je connais md5() pourrait ne pas être le meilleur moyen de crypter, tout ce qui produit toujours le même résultat peut être modifié par rétro-ingénierie.
alors quel est le sens de chiffrer quelque chose avec md5() ou toute autre méthode?
si un hacker obtient un mot de passe crypté avec md5 (), il utiliserait juste cette page! .
donc maintenant les questions actuelles:
- Comment fonctionne le cryptage par mot de passe?
je sais que je n'ai pas découvert une énorme vulnérabilité du web ici! :) Je veux juste comprendre la logique derrière le cryptage de mot de passe.
je suis sûr que je comprends quelque chose de mal, et j'apprécierais si vous pouviez m'aider à mettre ma pensée et d'autres (j'espère) droit.
appliquer le cryptage de mot de passe afin qu'il soit réellement utile?
- Qu'en est-il de cette idée?
comme je l'ai dit, je me trompe peut-être, mais cette méthode ajouterait-elle une sécurité en matière de sécurité à un environnement réel?
$reenc = array(
"h38an",
"n28nu",
"fw08d"
);
$pass = "Trufa";
$enc = chunk_split(md5($pass),5,$reenc[mt_rand(0,count($reenc)-1)]);
echo $enc;
comme vous le voyez, j'ai ajouté au hasard des chaînes arbitraires ( $reenc = array() ) à mon mot de passe md5 ()"ce qui le rend unique". Bien sûr, cela est juste un exemple stupide.
je peux me tromper, mais à moins que vous "semez le cryptage vous - même" il sera toujours facilement réversible.
ce qui précède serait mon idée de" mot de passe protégeant " et mot de passe crypté, si un hacker obtient à elle il ne sera pas en mesure de le décrypter à moins qu'il obtient l'accès à la raw .php
je sais que cela pourrait même pas de sens, mais je ne peux pas comprendre pourquoi c'est une mauvaise idée!
j'espère que j'ai fait moi-même assez clair, mais c'est une très longue question, s'il vous plaît demander pour toute clarification nécessaire!
Merci d'avance!!
13 réponses
vous devez avoir un encryption comme md5 ou sha512 . Vous devriez aussi avoir deux sels différents, un static salt (écrit par vous) et puis aussi un unique salt pour ce mot de passe spécifique.
quelques exemples de code (par exemple enregistrement.php):
$unique_salt = hash('md5', microtime());
$password = hash('md5', $_POST['password'].'raNdoMStAticSaltHere'.$unique_salt);
Maintenant vous avez un static salt , qui est valide pour tous vos mots de passe, qui est stocké dans le .fichier php. Ensuite, lors de l'exécution de l'enregistrement, vous générez un unique hash pour que le mot de passe spécifique.
tout cela se termine par: deux mots de passe qui sont épelés exactement le même, auront deux hashes différents . Le unique hash est stocké dans le database avec l'id courant. Si quelqu'un attrape le database , il aura chaque unique salt pour chaque mot de passe spécifique. Mais ce qu'ils n'ont pas c'est votre static salt , qui rend les choses beaucoup plus difficiles pour chaque "hacker" là-bas.
C'est comment vous vérifiez la validité de votre mot de passe à la connexion.php par exemple:
$user = //random username;
$querysalt = mysql_query("SELECT salt FROM password WHERE username='$user'");
while($salt = mysql_fetch_array($querysalt)) {
$password = hash('md5',
$_POST['userpassword'].'raNdoMStAticSaltHere'.$salt[salt]);
}
c'est Ce que j'ai utilisé dans le passé. Il est très puissant et sécurisé. Moi, je préfère le cryptage sha512 . C'est en fait juste pour mettre cela dans la fonction de hachage au lieu de md5 dans mon exemple.
si vous voulez être encore plus sûr, vous pouvez stocker le unique salt dans une base de données complètement différente.
premièrement, le" hachage "(utilisant une fonction cryptographique à Sens Unique) n'est pas un"chiffrement". En cryptage, vous pouvez inverser le processus (décryptage). Dans le hachage, il est (théoriquement) pas moyen d'inverser le processus.
un hachage est une fonction f telle que v ne peut pas être déterminé facilement à partir de f(v).
le point d'utiliser le hachage pour l'authentification est que vous (ou quelqu'un voyant la valeur du hachage) n'avez pas de moyen réalisable (encore une fois, théoriquement) de connaître le mot de passe. Cependant, vous pouvez toujours vérifier que l'utilisateur connaît son mot de passe. (Fondamentalement, l'utilisateur prouve qu'il connaît v tel que f(v) est le hachage stocké).
la faiblesse du simple hachage (en dehors des fonctions de hachage faibles) est que les gens peuvent compiler des tables de mots de passe et leur hachage correspondant et les utiliser pour (effectivement) obtenir l'inverse de la fonction de hachage. Salting empêche cela parce qu'alors une partie de la valeur d'entrée au hachage est contrôlé et donc, les tableaux doivent être compilées pour le sel.
donc pratiquement, vous stockez un sel et une valeur de hachage, et vous vous authentifiez en hachant une combinaison du sel et du mot de passe et en comparant cela avec votre valeur de hachage.
MD5 est une fonction de hachage à sens unique qui protégera votre mot de passe original plus ou moins en toute sécurité.
donc, disons que votre mot de passe est" Trufa", et sa version hachée est 06cb51ce0a9893ec1d2dce07ba5ba710 .
par exemple, lorsque vous vous connectez à une nouvelle page Web, ils vous demandent votre nom d'utilisateur et votre mot de passe. Lorsque vous écrivez "Trufa "comme mot de passe, la valeur 06cb51ce0a9893ec1d2dce07ba5ba710 est stockée dans la base de données parce qu'elle est hachée.
La prochaine fois que vous connectez-vous, et vous écrivez "Trufa", la valeur de hachage sera comparée à celle dans la base de données. S'ils sont les mêmes, vous êtes authentifiés! Fournir vous avez entré le nom d'utilisateur, bien sûr.
si votre mot de passe n'était pas stocké sous sa forme hachée dans la base de données, une personne malveillante pourrait lancer une requête d'une manière ou d'une autre sur cette base de données et voir tous les mots de passe réels. Et ce serait compromettre.
aussi, comme MD5 est une fonction cryptographique à 128 bits, il y a 2^128-1 = 340282366920938463463374607431768211455 combinaisons possibles.
Puisqu'il y a plus de chaînes possibles que celle-ci, il est possible que 2 chaînes génèrent la même valeur de hachage. Cela s'appelle une collision. Et il s'assure qu'un mot de passe hashé ne peut pas être modifié de manière inversée.
la seule vulnérabilité avec salting est que vous devez savoir ce qu'est le sel afin de reconstruire le hachage pour tester le mot de passe. Ceci est contourné en stockant l'entrée dans l'authdb sous la forme <algorithm>$<salt>$<hash> . De cette façon, l'entrée authdb peut être utilisée par tout code qui y a accès.
vous manquez l'étape importante - le sel. Il s'agit d'un bit unique (par utilisateur, idéalement) de données supplémentaires que vous ajoutez au mot de passe avant de le Hasher.
votre idée (salting) est bien connue et est en fait bien implémentée dans le langage PHP. Si vous utilisez le crypt() fonction il permet de spécifier une chaîne de hachage, une méthode pour chiffrer (dans certains cas), et un sel. Par exemple,
$x = crypt('insecure_password', $salt);
renvoie un mot de passe hashé et salé prêt à être stocké. Les mots de passe sont fissurés de la même façon que nous vérifions s'ils ont raison: nous vérifions le hachage de ce que l'utilisateur entre dans le hachage de leur mot de passe dans la base de données. S'ils correspondent, ils sont authentifiés (AFAIK c'est la façon la plus courante de le faire, si ce n'est la seule). pas sûr mots de passe (comme password ) qui utilisent des mots dictionnaires peuvent être fissurés en comparant leur hachage à des hachages de mots de passe communs. Secure les mots de passe ne peuvent pas être crackés de cette façon, mais peuvent toujours être crackés. Ajouter un sel au mot de passe le rend beaucoup plus difficile à craquer: puisque le hacker ne je sais ce qu'est le sel, son attaque au dictionnaire ne marchera pas.
pour un hachage décent, l'attaquant n'inversera pas le hachage, il utilisera une table arc-en-ciel, qui est essentiellement une méthode de force brute rendue utile si tout le monde utilise la même fonction de hachage.
l'idée d'une table arc-en-ciel est que depuis le hachage est rapide, je peux hachage toutes les valeurs possibles que vous pourriez utiliser comme un mot de passe, stocker le résultat, et avoir une carte dont le hachage se connecte à quel mot de passe. Si tout le monde prend juste leurs mots de passe et les hashes avec MD5 alors mon table de hachage est bon pour n'importe quel jeu de mots de passe, je peux obtenir mes mains sur!
c'est ici que le salage entre en jeu. Si je prends le mot de passe que l'utilisateur entre et ajoute des données qui sont différentes pour chaque utilisateur, alors cette liste de hachages prédéterminés est inutile puisque le hachage est à la fois du mot de passe et de quelques données aléatoires. Les données pour le sel peuvent être stockées juste à côté du mot de passe et même si je reçois les deux il ne m'aide pas à obtenir le mot de passe en arrière puisque je dois encore à essentiellement brute forcer le hachage séparément pour chaque utilisateur simple - Je ne peux pas former une seule table arc-en-ciel pour attaquer tous les hachages à la fois.
bien sûr, idéalement un attaquant n'obtiendra pas la liste des mots de passe hashés en premier lieu, mais certains employés y auront accès, il n'est donc pas possible de sécuriser entièrement la base de données des mots de passe.
en plus de fournir du sel (ou de la graine), le md5 est un algorithme de hachage complexe qui utilise des règles mathématiques pour produire un résultat qui n'est spécifiquement pas réversible en raison des changements mathématiques et de la perte de données dans le débit.
md5 (ou mieux: algorithmes de hachage en général) sont utilisés pour stocker les mots de passe en toute sécurité dans la base de données. La chose la plus importante à savoir sur les Hash est: les hash ne sont pas des cryptages en soi. (ce sont des chiffrements à Sens Unique tout au plus). Si vous chiffrer quelque chose, vous pouvez récupérer les données avec la clé que vous avez utilisé. Un hachage génère une valeur de longueur fixe à partir d'une entrée arbitraire (comme une chaîne), qui peut être utilisée pour voir si la même entrée a été utilisée.
Hashes sont utilisés pour stocker des données sensibles, entrées à plusieurs reprises dans un dispositif de stockage. Ce faisant, personne ne peut recréer l'entrée originale à partir des données de hachage, mais vous pouvez hachez un mot de passe entrant et le comparer à la valeur dans la base de données, et voir si les deux sont les mêmes, si oui, le mot de passe était correct.
vous avez déjà souligné, qu'il est possible de casser l'algorithme, soit en utilisant une base de données de valeur/paires de hachage ou en produisant des collisions (différentes valeurs résultant de la valeur de hachage). Vous pouvez l'obscurcir un peu en utilisant un sel, modifiant ainsi l'algorithme. Mais si le sel est connu, il peut être utilisé pour casser l'algorithme de nouveau.
j'aime cette question. Mais je pense que vous avez vraiment répondu vous-même.
le site que vous avez mentionné utilise des recherches de dictionnaires de md5 connus, non vendus - il ne" craque " rien.
votre exemple est presque bon, sauf que votre application doit être capable de régénérer le md5 en utilisant le même sel à chaque fois.
votre exemple semble utiliser un des sels aléatoires, qui échouera 2 de 3 fois si vous essayez de comparez le hachage du mot de passe d'un utilisateur à une entrée.
les gens vous diront D'utiliser aussi SHA1 ou SHA256 pour avoir un hash 'plus fort' - mais les gens diront aussi qu'ils sont tous 'cassés.
cette documentation est trompeuse -- elle enseigne un concept" vulnérable "et la présente comme étant" sécuritaire " parce qu'elle (le mot de passe enregistré) ressemble à du charabia. Juste des trucs sur internet qui ne mourront pas. Le lien suivant devrait clarifier les choses (vous en avez déjà trouvé une bonne partie, il semble. Du bon travail.)
assez avec les tables arc-en-ciel: ce que vous devez savoir sur les systèmes de mots de passe sécurisés parle de MD5 (et pourquoi il ne doit pas être utilisé) avec le sel (par exemple comment contrecarrer les attaques arc-en-ciel) ainsi que fournit des informations utiles (comme "utiliser le système de mot de passe de quelqu'un d'autre. Ne pas construire votre propre"). C'est une assez bonne vue d'ensemble.
C'est ma question sur les aspects de la collision md5, légèrement liée à votre question:
y a-t-il une différence entre md5 et sha1 dans cette situation?
la partie importante est dans les 3 premières lignes, qui est: vous doit mettre votre sel avant le mot de passe, si vous voulez obtenir une protection plus forte, pas après .
pour répondre simplement au titre de votre question, la seule utilisation réelle de md5 de nos jours est le hachage de grandes chaînes (telles que des fichiers) pour produire des sommes de contrôle. Ils sont généralement utilisés pour voir si les deux chaînes sont identiques (en termes de fichiers, les sommes de contrôle sont fréquemment utilisées à des fins de sécurité pour s'assurer qu'un fichier distribué n'a pas été altéré, par exemple).
pour répondre à chacune de vos questions en ligne:
Comment fait le mot de passe le chiffrement? Comment devriez-vous utiliser le cryptage de mot de passe pour qu'il soit réellement utile?
secure password hashing fonctionne en prenant le mot de passe sous forme de texte clair, puis en appliquant une fonction de hachage coûteux à elle, salé avec un cryptographiquement sécurisé sel aléatoire à elle. Voir la question Secure hash and salt for PHP passwords pour plus de détails à ce sujet.
Qu'en est-il de cette idée?
hachage de Mot de passe n'a pas besoin d'être compliqué comme ça, et ne devrait pas être. Évitez de penser à vos propres algorithmes et de s'en tenir aux algorithmes de hachage éprouvés et testés déjà là-bas. Comme la question liée ci-dessus le mentionne, md5() pour le hachage de mot de passe est obsolète depuis de nombreuses années maintenant, et il faut donc l'éviter.
votre méthode pour générer un sel" aléatoire" d'un tableau de trois sels différents n'est pas le caractère aléatoire que vous recherchez. Vous avez besoin d'un aléatoire unique qui est adapté pour cryptographiquement sécurisé (c.-à-d. en utilisant un générateur de nombres pseudo-aléatoires cryptiquement sécurisé (CSPRNG)). Si vous utilisez PHP 7 et plus, alors la fonction random_bytes peut être utilisée pour générer un sel cryptographique sécurisé (pour les utilisateurs de PHP 5, la bibliothèque random_compat peut être utilisée).