Discussion :

[alvanoto]

Bonjour,

J'ai créé un formulaire avec un emplacement pour un mot de passe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<input type="password" name="mdp" value="votre mot de passe" onclick= "this.value=''"/>

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?



je précise que lors de la création du champ PASS, j'ai choisi VARCHAR.

[sabotage]

IL n'est pas normal que les mots de passe puissent apparaître en clair dans une table

Il n'est pas souhaitable.

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.

[psychostyle]

on peut utilisé le md5(variablemotdepasse) vous le faite bien avant l'insertion dans la base de donné

[sabotage]

md5() n'est pas recommandé.

[DjiLow]

Tiens petite question sabotage.
Si md5() n'est pas recommandé quel algorithme utiliser ?
Merci

[grunk]

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 inutile

[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

[10_GOTO_10]

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

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.

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à).

[grunk]

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

Il est très simple de contourner le problème par un peu de javascript.
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

[10_GOTO_10]

Il est très simple de contourner le problème par un peu de javascript.
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.

Relis ce que j'ai écrit plus haut.

[grunk]

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

ma conclusion est que c'est totalement inutile

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.

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

[10_GOTO_10]

ca empèche d'avoir le mot de passe en clair sur le réseau, c'est tout.

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.

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.

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.

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.

Je n'ai jamais dit ça, pas de généralisation hâtive, SVP.

[sabotage]

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

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.

[DjiLow]

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.

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

[alvanoto]

j'ai rajouté MR5 et ça a marché. Comme je débute, je vais me contenter de ça. Merci à tous pour vos réponses