cs_stay
Messages postés493Date d'inscriptionjeudi 7 juillet 2005StatutMembreDernière intervention24 mai 20174 29 janv. 2008 à 17:53
Ton site web a planté complètement !!!
Je croix que tu as compris le principe de CMS.
Mais tu dois aussi partir sur le faite que de codé en php3 et en HTML n’est plus suffisent.
Si tu veux créer un gros projet tu dois être plus ambitieux.
Tu dois crée un code parfais et lisible avec des commentaires.
Pour mois un bon CMS utilise une très grand nombres de langages.
Si tu veux taper fort voilà quelque chose de simple (user friendly) pour un internaute utilisent un CMS.
satan2006
Messages postés21Date d'inscriptionjeudi 16 mars 2006StatutMembreDernière intervention21 janvier 2008 21 janv. 2008 à 17:22
Okai merci beaucoup la V2.1 est bientot finie!
cs_yoman64
Messages postés592Date d'inscriptionsamedi 19 janvier 2002StatutMembreDernière intervention 4 décembre 2008 21 janv. 2008 à 17:15
Niveau débutant, et hash le mot de passe n'est pas récupérable justement, c'est ça le but...
satan2006
Messages postés21Date d'inscriptionjeudi 16 mars 2006StatutMembreDernière intervention21 janvier 2008 21 janv. 2008 à 17:02
Je vous remerci tout de même pour vos commentaire! Je mettrai ici la V2.1 quand elle sera prète!
et pour hashé un mot de passe! J'ai pas très bien compris au niveau de la récupération!
Si quelqu'un pouvait m'expliquer!
Je demanderai aussi aux personne de me donner le niveau de la source parce que c'est quand même en fonction du niveau de l'utilisateur ( je parle du niveau codage expert intermédiaire ou débutant )
Je vous remercie de porter attention a mon projet!
lmame
Messages postés12Date d'inscriptionmercredi 15 janvier 2003StatutMembreDernière intervention 9 mai 2008 21 janv. 2008 à 13:26
Oui pour le md5() c'était juste pour donner une méthode basique de cheminement et de code pour php. Comme ce genre de chose se retrouve très aisément dans les codes / tutos sur internet ça permets déjà de lui donner une idée.
Après bien évidemment ce n'est pas la panacée le md5, loin de là pour les raisons déjà données :)
Ensuite pour la sécurisation totale d'un soft ça peut aller beaucoup plus loin, du log systématique des query / login / accès à l'utilisation de logs générés par mod_security que l'on peut installer pour Apache. Mais bon comme vous l'avez dit, tout est une question de juste milieu tout de même :)
neigedhiver
Messages postés2480Date d'inscriptionjeudi 30 novembre 2006StatutMembreDernière intervention14 janvier 201119 21 janv. 2008 à 12:56
Non non, tu as bien compris, mais tu dis avec tes mots ce que j'ai dit avec les miens.
Ce que je disais, c'était qu'il fallait faire un compromis : le meilleur algo en fonction des performances.
Donc ça peut tout à fait dépendre du nombre de connexions (=identifications/login, pas uniquement les inscriptions), de la fréquentation, des performances du serveur, de la charge de celui-ci, tout ça tout ça. Faut trouver un bon compromis.
Pour ce qui est de compliquer le brute force, il y a plein de méthodes, tu en donnes une bonne. On peut aussi ajouter le salt au mot de passe avant de le hasher. Avant, après, entre chaque caractère, un peu avant et un peu après, on peut le hasher avant de l'ajouter, on peut hasher le mot de passe, ajouter le salt hashé et hasher encore... Bref, les possibilités sont quasiment infinies...
Tiens, ça me donne une idée de source ça...
cs_yoman64
Messages postés592Date d'inscriptionsamedi 19 janvier 2002StatutMembreDernière intervention 4 décembre 2008 21 janv. 2008 à 12:37
Salut neigedhivers,
En fait après avoir lu un article en ce qui concerne le stockage de mot de passe par hash, le plus performant c'est jamais ce qu'on veut, au contraire :).
Plus l'algo est lent, plus le hash est long a calculer, plus quelqu'un va avoir de la difficulter à le bruteforcer ensuite puisqu'il doit calculer le hash de chaque possibilité. Et puis le calcul du hash sur un CMS c'est négligeable, c'est pas comme si il allait avoir 2000 connexions/inscriptions par minute.
J'ai peut être mal compris ce que tu voulais dire par contre, répond moi si je me trompe!
cs_yoman64
Messages postés592Date d'inscriptionsamedi 19 janvier 2002StatutMembreDernière intervention 4 décembre 2008 21 janv. 2008 à 12:32
Salut,
Si j'ai paru aggressif je m'en excuse, ce n'était pas mon intention.
Le cryptage est une mauvaise idée dans la mesure ou si tu ne connais pas bien la sécurité tu n'es pas en mesure de savoir ou de créer un algorythme sûr pour le stocker, donc le hash est tout indiqué. D'autant plus qu'un cryptage c'est souvent (pas toujours) plus rapide a casser que de calculer les centaines de millions de possibilités d'un hash md5.
LMAME tu as parfaitement bien expliqué le fonctionnement d'un hash :) toutefois je conseillerais d'utiliser plutot le sha1 qui donne un hash de 160bit au lieu de 128bit pour md5. Le nombre de dictionaires avec leurs correspondances md5 qu'on trouve sur le net (ou qu'on peut acheter) grandi toujours, donc le bruteforçage est une réalité de plus en plus présente (évidament le risque n'est pas très grand, je dis pas le contraire, lol).
En fait a mon avis le meilleur moyen de stocker un mot de passe est de le hasher une première fois, ensuite de lui ajouter un salt (une chaine prédéfinis), et de le réhasher, donc aucun brute force possible, en fait oui mais ça tombe dans l'irréel vu le nombre de possibilités a calculer une première fois , et une deuxieme fois, et pour ça il doit déja trouver le salt, et être conscient que c'est un hash de hash (vu que le cms est open-source ça aide, mais bon sans le salt il ira pas loin)!
Bonne continuation
neigedhiver
Messages postés2480Date d'inscriptionjeudi 30 novembre 2006StatutMembreDernière intervention14 janvier 201119 21 janv. 2008 à 12:28
Salut,
Pour compléter ce que dit Lmame :
Concernant la longueur du mot de passe, il est totalement inutile de la limiter. Cela n'apporte rien à personne, si ce n'est une plus grande facilité pour un hacker qui utilise un brute force. Plus le mot de passe est long, plus les caractères sont spéciaux, plus c'est difficile à trouver.
Un mot de passe uniquement numérique se casse "assez facilement". Si on rajoute des lettres, majuscules/minuscules, on augmente la difficulté. Si on rajoute des caractères non alphanumériques (!%$£=- etc) on augmente encore la difficulté. Et plus le mot de passe est long, plus on continue d'augmenter la difficulté.
Voilà pour ce qui est de l'intérêt de la non limitation du nombre de caractères (ou alors, à 30, mais pas 8, c'est vraiment trop peu).
Pour ce qui est de la méthode : tu hésites entre générer un mot de passe aléatoire modifiable plus tard, et ne pas limiter le nombre de caractères... Ca n'a rien à voir.
Commence par ne pas limiter la longueur du mot de passe, ou alors à une grande longueur (30 par exemple ; et encore, on peut tout à fait choisir une phrase comme "mot de passe", d'où le mot anglais passphrase).
Ensuite, soit l'utilisateur choisit son mot de passe à l'inscription, soit le mot de passe est généré aléatoirement et envoyé par mail.
Pourquoi ne pas envisager les deux possibilités et laisser l'administrateur la méthode qu'il préfère ?
Voire même une troisième possibilité : l'admin choisit le mot de passe en inscrivant manuellement les membres (pour un site privé par exemple).
Il faut de toute façon que le mot de passe soit modifiable ensuite par l'utilisateur, puisque c'est la loi qui le demande (cf site de la CNIL).
Enfin, il existe plusieurs algorithmes pour 'hasher' un mot de passe. md5 le fait sur 32 octets, sha1 sur 40, et d'autres encore sur davantage. A toi de choisir le plus performant sans sacrifier les performances.
lmame
Messages postés12Date d'inscriptionmercredi 15 janvier 2003StatutMembreDernière intervention 9 mai 2008 21 janv. 2008 à 12:01
Euh... Je ne pense pas que nous ayons été très agressifs :)
D'autre part, tu dis que tu travailles sur la V2 et sur les points signalés, très bien, il faut comprendre que nous revevons ici car on reçoit des notifications par mail, on ne passe pas sur ton site tous les jours pour voir où tu en es ce sujet sert à ça...
Pour les mots de passe, je pense que tu fais une confusion.
Si l'on te parle de crypter le mot de passe, c'est lors du stockage dans la base de données pour qu'il ne soit pas "en clair" dedans.
Je donne un exemple en md5:
Lors de l'inscription, ton utilisateur choisit comme mot de passe "coucou", tu le récupères dans ton code PHP et tu calcules sa signature en md5 (il suffit d'utiliser la fonction php md5() ) ce qui donne "721a9b52bfceacc503c056e3b9b93cfa" (normalement). L'avantage du md5 c'est que tu peux calculer une signature, mais tu ne peux pas, en partant d'une signature, retrouver le mot de passe originel (sauf en utilisant des dictionnaires ou le brute force, mais c'est une autre histoire).
Donc tu stockes dans ta base de données la signature "721a9b52bfceacc503c056e3b9b93cfa" pour cet utilisateur.
Quand ton utilisateur reviens et se loggue, il entre son mot de passe "coucou", tu calcules la signature du mot de passe qu'il a rentré (coucou) en md5 et tu la compares à la signature md5 qui est dans ta base de données.
En faisant comme ça, tu protèges tes utilisateurs car si la bdd se fait voler ou exploiter (sql injections ou autres) au moins les mots de passe seront cryptés.
Comme tu le vois, il n'y a donc aucune relation entre cryptage, et nombre de caractères dans le mot de passe ici :)
Si l'utilisateur décde de changer de mot de passe, tu peux toujours vérifier que l'ancien est correct avant de le changer pour un nouveau. En revanche, tu ne pourras pas toi le récupérer.
Ce que font la plupart des sites c'est qu'en cas de perte du mot de passe, ils l'écrasent par une chaîne aléatoire et qu'ils envoient le nouveau mot de passe sur le mail donné lors de l'inscription.
satan2006
Messages postés21Date d'inscriptionjeudi 16 mars 2006StatutMembreDernière intervention21 janvier 2008 21 janv. 2008 à 11:20
si vous avez fait un tour sur le site de TWC vous remarquerai que la V2 est en cours de construction et que la correction des erreures de sécurité sont entrain d'être traiter! Je travaille dur sur le déroulement de l'histoire de ce CMS!
Deplus il ne sert a rien de devenir agressif! car pour information mais je ne parle d'ésormais plus de prototype. Ensuite pour les mot de passe je ne sait pas encore quoi faire au niveau du cryptage! Soit j'en défini un a l'inscription que l'utilisateur pourra toujour modifier ou alors je ne limite pas le nombre de caractère!
neigedhiver
Messages postés2480Date d'inscriptionjeudi 30 novembre 2006StatutMembreDernière intervention14 janvier 201119 18 janv. 2008 à 12:16
Non mais lol... 8 caractères c'est suffisant... Ben pas pour moi. J'en utilise régulièrement 13.
Que le mot de passe soit difficile à retenir pour l'utilisateur, à la limite, c'est son problème. Mon mot de passe du moment fait 13 caractères, avec des caractères spéciaux et des majuscules. Et je le retiens aussi bien qu'il est facile à taper. Mais c'est pas pour autant qu'il est facile à deviner.
C'est pas le problème du webmaster la complexité du mot de passe : par contre, c'est son problème de s'assurer que la sécurité est optimale, ce qui n'est pas le cas en limitant la taille du mot de passe. C'est aussi son problème de le stocker de manière à ce qu'il soit protégé, donc en le hashant, c'est le minimum (autant utiliser sha1 plutôt que md5)
cs_yoman64
Messages postés592Date d'inscriptionsamedi 19 janvier 2002StatutMembreDernière intervention 4 décembre 2008 18 janv. 2008 à 11:37
8 c'est pas beaucoup personnelement mes mots de passe font souvent plus de 10 charactères...
Je vois pas l'interêt de limiter, si l'utilisateur l'oubli alors il n'a qu'à le redéfinir... On ne devrait pas forcer l'utilisateur à avoir un mot de passe de moin de 8 charactères.
En plus tes mots de passe sont stockés en clair dans la base, très mauvaise idée... et tu ne sécurise toujours pas tes requêtes avec mysql_real_escape_string.
C'est bien beau dire que ce n'est qu'un prototype et que tu feras mieu plus tard, mais rien ne t'empêche de tenir compte des remarques que l'on te fait ici. Toutes les remarques ci-dessus sont excellentes et tu devrais les écouter. Lorsque tu poste un script tu dois être prêt a l'améliorer au besoin, sinon il est totalement inutile ;) .
satan2006
Messages postés21Date d'inscriptionjeudi 16 mars 2006StatutMembreDernière intervention21 janvier 2008 18 janv. 2008 à 11:24
Le problème des mot de passes trop long est qu'ils sont dotant plus difficiles a retenir qu'il y a de caractères. puis 8 caractères pour un mot de passe c'est suffisant Fait le calcul du nombre de possibilitées!!!
neigedhiver
Messages postés2480Date d'inscriptionjeudi 30 novembre 2006StatutMembreDernière intervention14 janvier 201119 17 janv. 2008 à 23:39
Mais pourquoi tant de sites limitent le nombre de caractères pour le mot de passe ? C'est la nouvelle notion de sécurité ?
Tant que c'est pas uniquement des caractères alphanumériques... (un peu comme ici quoi...)
webdeb
Messages postés488Date d'inscriptionsamedi 5 avril 2003StatutMembreDernière intervention31 mars 20094 14 janv. 2008 à 12:52
Les @ sont à proscrire également !!!
lmame
Messages postés12Date d'inscriptionmercredi 15 janvier 2003StatutMembreDernière intervention 9 mai 2008 14 janv. 2008 à 09:42
Salut :)
Même remarque pour la sécurité, en Mysql il suffit de penser juste au typage et à mysql_real_escape_string (enfin, en gros...), autant le faire dès le départ que de se fader tous ses fichiers (quand on a pas de POO, c'est là qu'on voit que ça sert :) ).
Autre chose, toujours au niveau de la sécurité, apparemment le mot de passe est en "clair" dans la base de données. Déjà tu pourrais le stocker en md5() là aussi en une fonction tu sécurises un peu plus.
Sinon le fait de mettre des "@" devant toutes les commandes mysql juste pour cacher la misère en cas de plantage me paraît pas trèèèès judicieux :)
Autant faire une classe pour ça et traiter l'erreur éventuel (surtout si comme tu le dis c'est un proto et que tu veux savoir où et pourquoi ça plante).
Pour stocker les infos bdd tu crées un fichier php (system/data.php) mais sans vérifier s'il a bien été crée (ou si tu as les droits pour dans le dossier en question) ou pas et ensuite tu l'utilises dans pas mal de fichiers. Là encore pas de tests à l'ouverture en création du fichier.
Autre chose, dans system/modules.php (et aussi ailleurs):
if(empty($name) OR empty($actif))
if ( $actif 'Oui' AND $name 'Navigation')
tu devrais voir les opérateurs de comparaison booléens, || pour le OR et && pour le AND.
satan2006
Messages postés21Date d'inscriptionjeudi 16 mars 2006StatutMembreDernière intervention21 janvier 2008 13 janv. 2008 à 13:58
Tu a raison en certians points! Mais ce n'est que la première version je peut toujour améliorer m'injection mysql. Ce n'est qu'un prototype pour le moment. Je me suis égallement rendu compte d'une érreur d'otant plus grave. Je ne vérifie pas l'adresse mail ( érreur d'inatention ) et bien entendu je ne vérifie pas non plus que la date est valide ( pour l'inscription. ) J'ai pas fais attention dans le while pour l'inscription c'est vrai qu'il ne sert pas a grand chose. pour ta deuxième remarque je ne voi pas vraiment l'utilité c'est plus une question de gout. et pour ta première remarque j'ai effectué ca style de vérification pour indiquer au visiteur qu'il a besoin de l'un et de l'autre pour ce connecter et détecter le quel des deux n'a pas été entré.
Sinon tu a éffectué de très bonne remarque. J'en tiendrai compte pour la V2 pour le moment je fini le développement du prototype. Je pence faire 2 ou 3 version de test des différents développement. mais c'est en faisant petit a petit qu'on y arrive.
cs_yoman64
Messages postés592Date d'inscriptionsamedi 19 janvier 2002StatutMembreDernière intervention 4 décembre 2008 13 janv. 2008 à 12:08
Salut,
J'ai regardé brievement le code et quelques petits détails me sautes aux yeux.
1. Dans le fichier /inc/login.php
Tu devrais remplacer ton if ( empty($pseudo) ) { suivis du else if ( empty($motdepasse) ) {
Par un simple if ( empty($pseudo) || empty($motdepasse)) { puisque de toute manière les deux conditions afficherais le meme contenu.
2. Dans ce genre de code la POO améliorerait beaucoup la clarté du code, surtout quant à la base de données, une classe d'abstraction de base de données serait bien. (évidement c'est subjectif, ça ne regarde que moi)
3. TU NE SÉCURISE PAS TES REQUETES. ça m'a frappé, tu sécurises pas les données que tu passes dans tes requetes mysql, l'injection mysql est très dangereuse, je te suggère de t'informer sur mysql_real_escape_string. C'est une erreur très grave.
4. Dans la page d'inscription :
# $resultmembre = @mysql_query("SELECT * FROM `membres` WHERE `id`='".$id."'");
# if(@mysql_num_rows($resultmembre) > 0) {
#
# while ( $membres = @mysql_fetch_assoc($resultmembre) )
# {
# $id2 = $membre['id'];
# echo "Ce pseudo éxiste déja dans notre base de donnée.
Recommencer son inscription ou Revenir a l'accueil";
# }
Ton while ne sert a rien, je me trompe ?.
J'ai essayer de pas être trop dur, je ne veux que t'aider hein ;). Ton projet est interessant, mais je vais attendre la prochaine version pour tester,
Bonne continuation
29 janv. 2008 à 17:53
Je croix que tu as compris le principe de CMS.
Mais tu dois aussi partir sur le faite que de codé en php3 et en HTML n’est plus suffisent.
Si tu veux créer un gros projet tu dois être plus ambitieux.
Tu dois crée un code parfais et lisible avec des commentaires.
Pour mois un bon CMS utilise une très grand nombres de langages.
Si tu veux taper fort voilà quelque chose de simple (user friendly) pour un internaute utilisent un CMS.
http://builder.yaml.de/
Bonne chance ?
21 janv. 2008 à 17:22
21 janv. 2008 à 17:15
21 janv. 2008 à 17:02
et pour hashé un mot de passe! J'ai pas très bien compris au niveau de la récupération!
Si quelqu'un pouvait m'expliquer!
Je demanderai aussi aux personne de me donner le niveau de la source parce que c'est quand même en fonction du niveau de l'utilisateur ( je parle du niveau codage expert intermédiaire ou débutant )
Je vous remercie de porter attention a mon projet!
21 janv. 2008 à 13:26
Après bien évidemment ce n'est pas la panacée le md5, loin de là pour les raisons déjà données :)
Ensuite pour la sécurisation totale d'un soft ça peut aller beaucoup plus loin, du log systématique des query / login / accès à l'utilisation de logs générés par mod_security que l'on peut installer pour Apache. Mais bon comme vous l'avez dit, tout est une question de juste milieu tout de même :)
21 janv. 2008 à 12:56
Ce que je disais, c'était qu'il fallait faire un compromis : le meilleur algo en fonction des performances.
Donc ça peut tout à fait dépendre du nombre de connexions (=identifications/login, pas uniquement les inscriptions), de la fréquentation, des performances du serveur, de la charge de celui-ci, tout ça tout ça. Faut trouver un bon compromis.
Pour ce qui est de compliquer le brute force, il y a plein de méthodes, tu en donnes une bonne. On peut aussi ajouter le salt au mot de passe avant de le hasher. Avant, après, entre chaque caractère, un peu avant et un peu après, on peut le hasher avant de l'ajouter, on peut hasher le mot de passe, ajouter le salt hashé et hasher encore... Bref, les possibilités sont quasiment infinies...
Tiens, ça me donne une idée de source ça...
21 janv. 2008 à 12:37
En fait après avoir lu un article en ce qui concerne le stockage de mot de passe par hash, le plus performant c'est jamais ce qu'on veut, au contraire :).
Plus l'algo est lent, plus le hash est long a calculer, plus quelqu'un va avoir de la difficulter à le bruteforcer ensuite puisqu'il doit calculer le hash de chaque possibilité. Et puis le calcul du hash sur un CMS c'est négligeable, c'est pas comme si il allait avoir 2000 connexions/inscriptions par minute.
J'ai peut être mal compris ce que tu voulais dire par contre, répond moi si je me trompe!
21 janv. 2008 à 12:32
Si j'ai paru aggressif je m'en excuse, ce n'était pas mon intention.
Le cryptage est une mauvaise idée dans la mesure ou si tu ne connais pas bien la sécurité tu n'es pas en mesure de savoir ou de créer un algorythme sûr pour le stocker, donc le hash est tout indiqué. D'autant plus qu'un cryptage c'est souvent (pas toujours) plus rapide a casser que de calculer les centaines de millions de possibilités d'un hash md5.
LMAME tu as parfaitement bien expliqué le fonctionnement d'un hash :) toutefois je conseillerais d'utiliser plutot le sha1 qui donne un hash de 160bit au lieu de 128bit pour md5. Le nombre de dictionaires avec leurs correspondances md5 qu'on trouve sur le net (ou qu'on peut acheter) grandi toujours, donc le bruteforçage est une réalité de plus en plus présente (évidament le risque n'est pas très grand, je dis pas le contraire, lol).
En fait a mon avis le meilleur moyen de stocker un mot de passe est de le hasher une première fois, ensuite de lui ajouter un salt (une chaine prédéfinis), et de le réhasher, donc aucun brute force possible, en fait oui mais ça tombe dans l'irréel vu le nombre de possibilités a calculer une première fois , et une deuxieme fois, et pour ça il doit déja trouver le salt, et être conscient que c'est un hash de hash (vu que le cms est open-source ça aide, mais bon sans le salt il ira pas loin)!
Bonne continuation
21 janv. 2008 à 12:28
Pour compléter ce que dit Lmame :
Concernant la longueur du mot de passe, il est totalement inutile de la limiter. Cela n'apporte rien à personne, si ce n'est une plus grande facilité pour un hacker qui utilise un brute force. Plus le mot de passe est long, plus les caractères sont spéciaux, plus c'est difficile à trouver.
Un mot de passe uniquement numérique se casse "assez facilement". Si on rajoute des lettres, majuscules/minuscules, on augmente la difficulté. Si on rajoute des caractères non alphanumériques (!%$£=- etc) on augmente encore la difficulté. Et plus le mot de passe est long, plus on continue d'augmenter la difficulté.
Voilà pour ce qui est de l'intérêt de la non limitation du nombre de caractères (ou alors, à 30, mais pas 8, c'est vraiment trop peu).
Pour ce qui est de la méthode : tu hésites entre générer un mot de passe aléatoire modifiable plus tard, et ne pas limiter le nombre de caractères... Ca n'a rien à voir.
Commence par ne pas limiter la longueur du mot de passe, ou alors à une grande longueur (30 par exemple ; et encore, on peut tout à fait choisir une phrase comme "mot de passe", d'où le mot anglais passphrase).
Ensuite, soit l'utilisateur choisit son mot de passe à l'inscription, soit le mot de passe est généré aléatoirement et envoyé par mail.
Pourquoi ne pas envisager les deux possibilités et laisser l'administrateur la méthode qu'il préfère ?
Voire même une troisième possibilité : l'admin choisit le mot de passe en inscrivant manuellement les membres (pour un site privé par exemple).
Il faut de toute façon que le mot de passe soit modifiable ensuite par l'utilisateur, puisque c'est la loi qui le demande (cf site de la CNIL).
Enfin, il existe plusieurs algorithmes pour 'hasher' un mot de passe. md5 le fait sur 32 octets, sha1 sur 40, et d'autres encore sur davantage. A toi de choisir le plus performant sans sacrifier les performances.
21 janv. 2008 à 12:01
D'autre part, tu dis que tu travailles sur la V2 et sur les points signalés, très bien, il faut comprendre que nous revevons ici car on reçoit des notifications par mail, on ne passe pas sur ton site tous les jours pour voir où tu en es ce sujet sert à ça...
Pour les mots de passe, je pense que tu fais une confusion.
Si l'on te parle de crypter le mot de passe, c'est lors du stockage dans la base de données pour qu'il ne soit pas "en clair" dedans.
Je donne un exemple en md5:
Lors de l'inscription, ton utilisateur choisit comme mot de passe "coucou", tu le récupères dans ton code PHP et tu calcules sa signature en md5 (il suffit d'utiliser la fonction php md5() ) ce qui donne "721a9b52bfceacc503c056e3b9b93cfa" (normalement). L'avantage du md5 c'est que tu peux calculer une signature, mais tu ne peux pas, en partant d'une signature, retrouver le mot de passe originel (sauf en utilisant des dictionnaires ou le brute force, mais c'est une autre histoire).
Donc tu stockes dans ta base de données la signature "721a9b52bfceacc503c056e3b9b93cfa" pour cet utilisateur.
Quand ton utilisateur reviens et se loggue, il entre son mot de passe "coucou", tu calcules la signature du mot de passe qu'il a rentré (coucou) en md5 et tu la compares à la signature md5 qui est dans ta base de données.
En faisant comme ça, tu protèges tes utilisateurs car si la bdd se fait voler ou exploiter (sql injections ou autres) au moins les mots de passe seront cryptés.
Comme tu le vois, il n'y a donc aucune relation entre cryptage, et nombre de caractères dans le mot de passe ici :)
Si l'utilisateur décde de changer de mot de passe, tu peux toujours vérifier que l'ancien est correct avant de le changer pour un nouveau. En revanche, tu ne pourras pas toi le récupérer.
Ce que font la plupart des sites c'est qu'en cas de perte du mot de passe, ils l'écrasent par une chaîne aléatoire et qu'ils envoient le nouveau mot de passe sur le mail donné lors de l'inscription.
21 janv. 2008 à 11:20
Deplus il ne sert a rien de devenir agressif! car pour information mais je ne parle d'ésormais plus de prototype. Ensuite pour les mot de passe je ne sait pas encore quoi faire au niveau du cryptage! Soit j'en défini un a l'inscription que l'utilisateur pourra toujour modifier ou alors je ne limite pas le nombre de caractère!
18 janv. 2008 à 12:16
Que le mot de passe soit difficile à retenir pour l'utilisateur, à la limite, c'est son problème. Mon mot de passe du moment fait 13 caractères, avec des caractères spéciaux et des majuscules. Et je le retiens aussi bien qu'il est facile à taper. Mais c'est pas pour autant qu'il est facile à deviner.
C'est pas le problème du webmaster la complexité du mot de passe : par contre, c'est son problème de s'assurer que la sécurité est optimale, ce qui n'est pas le cas en limitant la taille du mot de passe. C'est aussi son problème de le stocker de manière à ce qu'il soit protégé, donc en le hashant, c'est le minimum (autant utiliser sha1 plutôt que md5)
18 janv. 2008 à 11:37
Je vois pas l'interêt de limiter, si l'utilisateur l'oubli alors il n'a qu'à le redéfinir... On ne devrait pas forcer l'utilisateur à avoir un mot de passe de moin de 8 charactères.
En plus tes mots de passe sont stockés en clair dans la base, très mauvaise idée... et tu ne sécurise toujours pas tes requêtes avec mysql_real_escape_string.
C'est bien beau dire que ce n'est qu'un prototype et que tu feras mieu plus tard, mais rien ne t'empêche de tenir compte des remarques que l'on te fait ici. Toutes les remarques ci-dessus sont excellentes et tu devrais les écouter. Lorsque tu poste un script tu dois être prêt a l'améliorer au besoin, sinon il est totalement inutile ;) .
18 janv. 2008 à 11:24
17 janv. 2008 à 23:39
Tant que c'est pas uniquement des caractères alphanumériques... (un peu comme ici quoi...)
14 janv. 2008 à 12:52
14 janv. 2008 à 09:42
Même remarque pour la sécurité, en Mysql il suffit de penser juste au typage et à mysql_real_escape_string (enfin, en gros...), autant le faire dès le départ que de se fader tous ses fichiers (quand on a pas de POO, c'est là qu'on voit que ça sert :) ).
Autre chose, toujours au niveau de la sécurité, apparemment le mot de passe est en "clair" dans la base de données. Déjà tu pourrais le stocker en md5() là aussi en une fonction tu sécurises un peu plus.
Sinon le fait de mettre des "@" devant toutes les commandes mysql juste pour cacher la misère en cas de plantage me paraît pas trèèèès judicieux :)
Autant faire une classe pour ça et traiter l'erreur éventuel (surtout si comme tu le dis c'est un proto et que tu veux savoir où et pourquoi ça plante).
Pour stocker les infos bdd tu crées un fichier php (system/data.php) mais sans vérifier s'il a bien été crée (ou si tu as les droits pour dans le dossier en question) ou pas et ensuite tu l'utilises dans pas mal de fichiers. Là encore pas de tests à l'ouverture en création du fichier.
Autre chose, dans system/modules.php (et aussi ailleurs):
if(empty($name) OR empty($actif))
if ( $actif 'Oui' AND $name 'Navigation')
tu devrais voir les opérateurs de comparaison booléens, || pour le OR et && pour le AND.
13 janv. 2008 à 13:58
Sinon tu a éffectué de très bonne remarque. J'en tiendrai compte pour la V2 pour le moment je fini le développement du prototype. Je pence faire 2 ou 3 version de test des différents développement. mais c'est en faisant petit a petit qu'on y arrive.
13 janv. 2008 à 12:08
J'ai regardé brievement le code et quelques petits détails me sautes aux yeux.
1. Dans le fichier /inc/login.php
Tu devrais remplacer ton if ( empty($pseudo) ) { suivis du else if ( empty($motdepasse) ) {
Par un simple if ( empty($pseudo) || empty($motdepasse)) { puisque de toute manière les deux conditions afficherais le meme contenu.
2. Dans ce genre de code la POO améliorerait beaucoup la clarté du code, surtout quant à la base de données, une classe d'abstraction de base de données serait bien. (évidement c'est subjectif, ça ne regarde que moi)
3. TU NE SÉCURISE PAS TES REQUETES. ça m'a frappé, tu sécurises pas les données que tu passes dans tes requetes mysql, l'injection mysql est très dangereuse, je te suggère de t'informer sur mysql_real_escape_string. C'est une erreur très grave.
4. Dans la page d'inscription :
# $resultmembre = @mysql_query("SELECT * FROM `membres` WHERE `id`='".$id."'");
# if(@mysql_num_rows($resultmembre) > 0) {
#
# while ( $membres = @mysql_fetch_assoc($resultmembre) )
# {
# $id2 = $membre['id'];
# echo "Ce pseudo éxiste déja dans notre base de donnée.
Recommencer son inscription ou Revenir a l'accueil";
# }
Ton while ne sert a rien, je me trompe ?.
J'ai essayer de pas être trop dur, je ne veux que t'aider hein ;). Ton projet est interessant, mais je vais attendre la prochaine version pour tester,
Bonne continuation