Version imprimable
Bonjour,
J'ai créé un formulaire avec un emplacement pour un mot de passe:
mais lors de l'insertion dans la table, ce dernier n'est pas crypté (voir capture d'écran).IL n'est pas normal que les mots de passe puissent apparaître en clair dans une table, non? 8OCode:<input type="password" name="mdp" value="votre mot de passe" onclick= "this.value=''"/>
http://img835.imageshack.us/img835/8202/passc.jpg
je précise que lors de la création du champ PASS, j'ai choisi VARCHAR.
Il n'est pas souhaitable.Citation:
IL n'est pas normal que les mots de passe puissent apparaître en clair dans une table
Il est preferable de n'enregistrer qu'une empreinte du mot de passe.
Pour cela tu peux utiliser la fonction hash() et un algorithme de ton choix.
Pour verifier tu comparera le hash du mot de passe saisie à ce que tu as stocké dans la base.
on peut utilisé le md5(variablemotdepasse) vous le faite bien avant l'insertion dans la base de donné
md5() n'est pas recommandé.
Tiens petite question sabotage.
Si md5() n'est pas recommandé quel algorithme utiliser ?
Merci
Sha1,256 par exemple est plus recommandé. Les tables de correspondances pour md5 sont tellement nombreuse qu'il en devient presque inutileCitation:
Envoyé par DjiLow
Généralement j'accumule les algorithmes, du genre
sha1(md5(crc32('le_mot_de_passe_en_question)))
Et jusque ici je n'ai jamais eu de soucis :roll:
Contrairement à ce qu'on pourrait croire, ce n'est pas une bonne solution: deux chaînes pouvant avoir le même hash, cumuler les hashages (différents comme ici ou md5(md5(md5(...)))) ne fais qu'augmenter le nombre de collisions et donc faciliter une attaque par dictionnaire.Citation:
Envoyé par DjiLow
En fait, suite à cette discussion, je me suis un peu renseigné sur le cryptage du mot de passe, et ma conclusion est que c'est totalement inutile:
- Soit quelqu'un arrive a pirater la base et dans ce cas il s'en fiche bien du mot de passe: ce qui l'intéresse c'est les autre informations, nom, e-mail, numéro de carte bleue, etc...
- Soit quelqu'un arrive à espionner le réseau entre l'utilisateur et le serveur final (et quel que soit l'endroit et l'architecture), et dans ce cas, qu'il ait à faire au mot de passe en clair, à son hash, à son hash avec un "grain de sel", le résultat est le même: il lui suffit de renvoyer la même chaîne pour s'authentifier de la même façon que l'utilisateur légal.
La seule utilité que je verrais est pour le cas où un utilisateur serait inscrit à plusieurs endroits avec le même nom et le même mot de passe (ce qui est imprudent, déjà).
Il est très simple de contourner le problème par un peu de javascript.Citation:
Envoyé par 10_GOTO_10
Juste avant l'envoi des données on crypte le mot de passe saisie dans l'algo souhaité et on envoi le mdp cryptée et non le mdp en clair ;)
Non, justement.Citation:
Envoyé par grunk
Relis ce que j'ai écrit plus haut.
Ca ne règle pas l'injection de données ultérieur je suis d'accord , mais ca empèche d'avoir le mot de passe en clair sur le réseau, c'est tout. (je n'aborde volontairement l'éventuel problème d'accessibilité que cela engendre)
Qui plus est en rajoutant un élément variable au hash du mdp transmi , ca va devenir compliqué pour celui voudra outre passer l'identification.
Mais si on suis t'as logique
On pourrait dire de même pour les antivirus , finalement il servent à rien puisque il y'a toujours des virus nouveaux qui ne sont pas détectés.Citation:
ma conclusion est que c'est totalement inutile
Effectivement le hash des mot de passes en base n'est pas la solution à tous les problèmes mais c'est une faille de moins. (une hacker peut très bien rechercher le mot de passe d'une personne particulière dans une bdd pour compromettre son compte).
Note sur le lien vers l'article que tu as donné : La seule solution viable pour se prémunir des faille csrf , c'est l'utilisation de token et la validation manuel des actions par l'utilisateur pas l'utilisation de filtres
Comme tu le dis, c'est tout. Et comme pour un pirate deviner un mot de passe ou deviner le hash d'un mot de passe demande exactement le même travail, ça veut dire que c'est totalement inutile. Je crois qu'on est donc d'accord.Citation:
Envoyé par grunk
Tu ne peux pas: il faut que ton serveur (qui ne connait pas le mot de passe en clair, il ne connait que le hash) puisse authentifier l'utilisateur. Comment le pourrait-il si on rajoute un élément variable ? Et quel élément variable, d'ailleurs ? La date pose des problèmes de synchronisation, dans l'article que j'ai mis en lien ils proposent aussi le captcha mais pour moi c'est tout aussi inutile.Citation:
Envoyé par grunk
Je n'ai jamais dit ça, pas de généralisation hâtive, SVP.Citation:
Envoyé par grunk
Une base peut servir a plein d'autres choses qu'un site marchand.Citation:
Soit quelqu'un arrive a pirater la base et dans ce cas il s'en fiche bien du mot de passe: ce qui l'intéresse c'est les autre informations, nom, e-mail, numéro de carte bleue, etc...
Même sans parler de piratage, une personne peut avoir accès légitime à la base de données utilisateur : si le mot de passe est en clair, il peut utiliser le compte comme le ferrait l'utilisateur.
Tout à fait d'accord avec sabotage, moi le plus gros risque qu'il y ait c'est que quelqu'un accède au site comme un utilisateur, certes c'est moins grave que sur un site marchand mais bon si cette personne n'est pas censé y avoir accès c'est bien pour une raison :mrgreen:Citation:
Une base peut servir a plein d'autres choses qu'un site marchand.
Même sans parler de piratage, une personne peut avoir accès légitime à la base de données utilisateur : si le mot de passe est en clair, il peut utiliser le compte comme le ferrait l'utilisateur.
j'ai rajouté MR5 et ça a marché. Comme je débute, je vais me contenter de ça. Merci à tous pour vos réponses :ccool: