login password et MD5: oui mais pourquoi ?

WRInaute impliqué
bonjour

dans le cadre d'une identification de login ou les mot de passes sont stockés dans la base de donnée:

pourquoi faut il crypter (hacher) les mots de passe en MD5 (ou autres)...je ne vois pas du tout l'intérêt si je suis le seul à pouvoir voir en clair les mot de passe des internautes de ma base de donnée

avez vous un avis sur le sujet?
merci ;-)

bon week end
 
WRInaute impliqué
C'est un problème de sécurité, tu dis être le seul à voir les mdp, mais es tu sûr de la sécurité de tous les scripts que tu utilises?? si un de ceux-ci à une faille qui permette d'accéder à la base, le hackeur aura accès aux mots de passe lui aussi si ils sont en clair, mais si ils sont en hachés (md5) ils ne lui seront d'aucune utilité
 
WRInaute impliqué
DadouDuck a dit:
si ils sont en hachés (md5) ils ne lui seront d'aucune utilité

Faux il est très simple de trouver des sites qui permettent de décrypter des MD5. Si on connait le cryptage, on connait forcément la manière de décrypter.
exemple : -http://www.authsecu.com/decrypter-dechiffrer-cracker-hash-md5/decrypter-dechiffrer-cracker-hash-md5.php
 
WRInaute discret
Si on connait le cryptage, on connait forcément la manière de décrypter.

Pas exactement : pas de décryptage possible, mais seulement la possibilité de vérifier si la traduction du hash md5 en question correspond à une traduction dans les dictionnaires md5 existants. En clair (sans mauvais jeu de mot), si le mot de passe est bateau, il a de grandes chances d'être connu, par contre s'il s'agit d'un mdp long et complexe (caractères spéciaux, chiffres, majuscules ...) je pense q'il n'y a aucun moyen de décrypter à la vollée, ou même en étant très patient :wink:

Pour la petite histoire, je crois que c'est une obligation légale de ne pas archiver les mots de passe de vos utilisateurs en clair dans les bdd des sites. Pourtant, vous verrez que même de "gros" sites proposent de vous renvoyer par mail "votre" mot de passe en clair si vous l'avez oublié : il ne le pourraient pas si le mot de passe était archivé en md5 ! Lorsque les mdp sont en md5 la seule possibilité, est de générer un nouveau mot de passe aléatoire, et de l'envoyer au visiteur en l'invitant à le changer pour ... s'en souvenir cette fois. Bref, tous les sites qui se souviennent clairement de votre mdp sont hors la loi.
 
WRInaute occasionnel
hyadex a dit:
DadouDuck a dit:
si ils sont en hachés (md5) ils ne lui seront d'aucune utilité

Faux il est très simple de trouver des sites qui permettent de décrypter des MD5. Si on connait le cryptage, on connait forcément la manière de décrypter.
exemple : -http://www.authsecu.com/decrypter-dechiffrer-cracker-hash-md5/decrypter-dechiffrer-cracker-hash-md5.php

Oui, c'est très simple si on choisit un mot de passe qui est dans le dictionnaire ou qui est simple à deviner.

Sinon, c'est très difficile.

Raison pour laquelle il ne faut pas choisir des mots de passe trop simple.

Ce système permet d'identifier:

Code:
pilote
Pilote
PilOte
pilote77

mais pas

Code:
pil0te (avec zéro à la place du O)
2pil4lote

et encore moins

Code:
t5jzd9

Quant à la question de l'auteur de ce post, garder les mots de passe ne clair sur son serveur est irresponsable, et comme les utilisateur le sont tout autant et qu'ils utilisent les mêmes mots de passe partout, quelqu'un qui hackerait le serveur obtiendrait les données "adresse email + mot de passe" et pourrait s'amuser un peu avec tout ça.

à plus
 
WRInaute impliqué
bonjour

merci pour vos réponses, je comprends mieux...

donc finalement le mieux c'est de faire soit même un algorythme de cryptage simple genre XOR , non?

bonne journée
 
WRInaute passionné
Il suffit d'utiliser la technique du "grain de sable" couplé avec md5, et il n'y a plus aucun problème ;)
 
WRInaute impliqué
WRInaute passionné
Cette technique empêche l'utilisation d'un dictionnaire pour décrypter une chaine MD5.
J'aurais plutôt du parler de "grain de sel", mais bon peut importe... la technique reviens à faire :

Code:
md5($graindesel . $password);

Une lecture intéressante :
-http://info.crypto.free.fr/graindesel.php
 
WRInaute discret
Une lecture intéressante :
-http://info.crypto.free.fr/graindesel.php
+1 :mrgreen:

Page effectivement pratique pour comprendre le rôle d'un grain de sel :D
C'est vrai que c'est "la" parade contre les dictionnaires ! (mais pas une raison pour des mdp trop simples :wink: )
 
WRInaute occasionnel
webmasterdemonsite a dit:
merci pour les liens

j'ai utilisé md5 plus un gros grain de sel ;-)

C'est une bonne chose, mais le problème n'est pas très différent, car le code de ton site contient la recette pour générer le md5 avec le grain de sel.

Donc si tu te fais hacker ton site, le pirate pourra générer les md5 à partir de son dictionnaire, en utilisant ta prodécure de génération, grain de sel inclu, et ensuite les comparer à ceux de ta base de données.

Donc là encore, la seule parade, c'est un mot de passe béton.

La même chose est valable pour mcrypt, si la clé de chiffrement est intégré à ton code, il suffit d'avoir le code sous la main pour déchiffrer.
 
WRInaute impliqué
Oui, enfin, il faut qu'il ait quand même accès au code, c'est à dire au moins accès au FTP pour pouvoir le lire, sinon, je ne vois pas bien comment il pourrait avoir la clé.
 
WRInaute impliqué
C'est un peu se que je disais au début.
Le cryptage MD5 est facilement décritpable. A partir du moment ou on connait la manière de crypter on peut facilement trouver celle pour décrypter.
Pour preuve en est que si l'on souhaite crypter une information, c'est forcément pour pouvoir la réutiliser plus tard, donc en la cryptant et décryptant à l'aide d'une clé.
 
WRInaute impliqué
Le MD5 n'est pas un cryptage, mais un hachage , ce qui par définition n'est pas réversible, contrairement à un cryptage, pour casser un MD5 tu n'as que les algos de "Brute force" utiliser un dictionnaire de mots pour tester toutes les combinaisons possibles pour obtenir le mot de passe : http://fr.wikipedia.org/wiki/MD5

Les bibliothèques mcrypt de PHP permettent d'augmenter de manière signification la difficulté de casser le cryptage, par exemple l'algo Blowfish que j'utilise permet un cryptage allant jusqu'a 448 bits, et la bon courage à celui qui n'a pas la clé :mrgreen: http://fr.wikipedia.org/wiki/Blowfish
 
WRInaute occasionnel
DadouDuck a dit:
Les bibliothèques mcrypt de PHP permettent d'augmenter de manière signification la difficulté de casser le cryptage, par exemple l'algo Blowfish que j'utilise permet un cryptage allant jusqu'a 448 bits, et la bon courage à celui qui n'a pas la clé :mrgreen: http://fr.wikipedia.org/wiki/Blowfish

Très bien, mais dans le cas d'espèce, on parle de la manière de conserver les mots de passe des utilisateurs d'un site web, et pour ce faire, la clé doit se trouver dans ton code, donc c'est une porte blindée sur un mur en carton :wink:
 
WRInaute occasionnel
Pour éviter de ce faire pirater autant commencer par sécurisé la moindre connexion avec la base de données.
- Est-ce que les données que le formulaire m'envoie sont sans risque ?
- Est-ce que j'ai bien fait de mettre ma variable POST directement dans ma requête SQL ?

Autant de questions qui permettent d'augmenter la sécurité du site dans sa globalité...
 
WRInaute impliqué
bruno212 a dit:
Très bien, mais dans le cas d'espèce, on parle de la manière de conserver les mots de passe des utilisateurs d'un site web, et pour ce faire, la clé doit se trouver dans ton code, donc c'est une porte blindée sur un mur en carton :wink:

:roll: Absolument pas, le code n'est pas directement accessible, pour qu'il le soit, il faudrait qu'il ait accès au FTP du site, sinon, comment peut il lire le code si il n'a pas accès aux fichiers sources, mais la on entre dans la sécurité serveur.

En plus, dans ma manière de conserver les mots de passes utilisateurs, je créé une clé différente par utilisateur, la seule manière d'avoir les clés c'est d'avoir accès à la BDD, et concernant les requêtes SQL, comme je les fait avec PDO::prepare je suis assez bien couvert niveau injection SQL
 
WRInaute occasionnel
Petit rappel: la question initiale était de savoir pourquoi il est nécessaire de ne pas conserver en clair les mots de passe des utilisateurs.

Ce à quoi il a été répondu qu'en cas de piratage du site (par accès FTP ou par défaillance de l'interface de gestion de l'hébergeur, par exemple), en cryptant ou "hachant" les mots de passe, le pirate n'aurait pas accès à ces mots de passe.

On parle bien ici de la manière de protéger les mots de passe des utilisateurs en cas de piratage de la BDD et / ou du site en entier.

à plus
 
WRInaute impliqué
Sur la question initiale je suis d'accord, mais il n'a jamais été répondu de problème de piratage par accès FTP, mais de sécurisation du code et de défaillances des scripts utilisés et des problèmes d'injections SQL qu'il pourrait y avoir. A partir du moment ou il y a un accès FTP possible par un hackeur toutes les méthodes seront réversibles.

Donc en mettant de coté le hack FTP, qui n'a du coup plus rien a voir avec la sécurisation du code, si le MDP est crypté en BDD, un hackeur ne peut retrouver facilement le mot de passe originel
 
WRInaute impliqué
bonjour

- tout mes formulaire sont en htmentities
- md5 + grain de sel
- quand au hack possible de mon ftp, je peut pas y faire grand chose...

me faire pirater ma bdd + mon ftp me parait improbable (bien que possible)

de toute facon si un hacker balaise s'en prend à mon site, je ne pourrais pas faire grand chose...

merci pour vos réponses ;-)
 
WRInaute passionné
bruno212 a dit:
C'est une bonne chose, mais le problème n'est pas très différent, car le code de ton site contient la recette pour générer le md5 avec le grain de sel.

Donc si tu te fais hacker ton site, le pirate pourra générer les md5 à partir de son dictionnaire, en utilisant ta prodécure de génération, grain de sel inclu, et ensuite les comparer à ceux de ta base de données.

Le grain de sel serait dans ce cas la un chiffre généré aléatoirement (comme sur mon WWW).
Sa changerais le donne, non ? (ou du moins compliquerais la donne ?)

me faire pirater ma bdd + mon ftp me parait improbable (bien que possible)

En même temps tout est relié...
Dés lors qu'on a accès à ton espace FTP on à accès à ta BDD (il suffirait de regarder les mots de passe stockés dans des fichiers de configuration de script, comme "config.php").
 
WRInaute occasionnel
webmasterdemonsite a dit:
mais si le grain de sel est aléatoire, faut bien le stocker quemque part aussi non?

Oui, car tu en as besoin pour vérifier le mot de passe que l'utilisateur donne au moment de la connexion.
 
WRInaute passionné
bruno212 a dit:
webmasterdemonsite a dit:
mais si le grain de sel est aléatoire, faut bien le stocker quemque part aussi non?

Oui, car tu en as besoin pour vérifier le mot de passe que l'utilisateur donne au moment de la connexion.

Tu l'enregistre dans ta base de donnée.
Après il suffit de faire une requete du genre : select salt from tablemembre where login='$login'

Mais bon après si la BDD est piraté... :roll:
 
WRInaute occasionnel
660595992_small.jpg

sur ce topic.
 
WRInaute accro
Salut,
Tiens c'est vrai que pour originale qu'elle soit la question n'est pas dénuée d'intérêt car si l'on peut répondre que c'est pour pas qu'un hacker connaisse le mot de passe d'un membre on peut rapidement objecter qu'il n'en a pas besoin puisqu'il est déjà dans MYSQL et que donc il peut très bien modifier le mot de passe de l'utilisateur dont il veut usurper temporairement l'identité puis, une fois son forfait accompli, il lui suffit de réinjecter l'ancien hash.
Donc : oui mais pourquoi ?
 
WRInaute occasionnel
serval2a a dit:
Salut,
Tiens c'est vrai que pour originale qu'elle soit la question n'est pas dénuée d'intérêt car si l'on peut répondre que c'est pour pas qu'un hacker connaisse le mot de passe d'un membre on peut rapidement objecter qu'il n'en a pas besoin puisqu'il est déjà dans MYSQL et que donc il peut très bien modifier le mot de passe de l'utilisateur dont il veut usurper temporairement l'identité puis, une fois son forfait accompli, il lui suffit de réinjecter l'ancien hash.
Donc : oui mais pourquoi ?

Voler une liste de noms d'utilisateur avec l'adresse email et le mot de passe qui correspondent me semble très intéressant.

Les gens utilisent souvent les mêmes pour toutes leurs inscriptions, y compris à la banque, leur compte mail, etc. Plus on en sait, plus il est facile d'arnaquer.
 
Discussions similaires
Haut