Discussion :

[doof]

Désolé, j'arrive un peu tard

Il y a juste un point qui me chagrine vis a vis de l'utilisation de RSA (ou plutot que l'admin puisse recuperer le pass). Le hash md5 de par son coté iréversible n'est pas utilisé au hasard pour stoquer des mdp, en effet, il garantit l'intimité des données confiées au webmaster. Je suis d'accord que ca n'apporte pas un niveau de sécurité supplémentaire pour l'espace membre du site en question mais surtout pour l'utilisateur qui peut donner en toute confiance des infos personelles et confidentielles sans que personne ne les connaissent (dont l'admin du site).

Qu'en pensez vous ?

[Sub0]

Tu as raison de vouloir discuter de ce point doof! Il se trouve en réalité que nous conseillerons d'utiliser des mdp aléatoires si le cryptage RSA est utilisé pour le stockage. Et puis de toute façon, celui qui donne un mdp sensible (comme le n° de sa CB par exemple, ou le code d'identification permettant l'accès de son compte bancaire via le net ou d'autres comptes membre d'autres sites) doit se douter que par un moyen ou un autre, l'admin est capable d'obtenir toutes les données de son site si il désire. Après tout, l'admin est le propriétaire de la base...

Bref, malgré cela, je tiens à conserver la possibilité d'encryptage RSA du mot de passe, déjà parce-que selon moi, il appartient au webmaster et non aux membres de choisir la manière dont seront stockées les données dans la base, et ensuite parce que c'est necessaire dans certain cas de pouvoir obtenir le mot de passe en clair, non pas pour hacker le compte du membre, mais pour lui redonner si il le perd...

Par exemple, je travaillais en patenariat pour une PME qui m'a demandé le développement d'un espace membre (projet que j'ai terminé récemment). Le mot de passe est généré aléatoirement. Le problème est qu'il ne leur est pas possible de modifier le mot de passe d'un membre une fois l'inscription effectuée. De plus, ils voulaient que le membre puisse obtenir son mot de passe par mail en cas de perte. Dans ces conditions, seul l'encodage était envisageable pour protéger le mot de passe, puisque le script doit décoder le mdp de la base pour l'envoyer en clair au membre. Un cryptage RSA serait inutile puisque la clé de décryptage devrait se trouver dans le code source...

Il est clair que la meilleure solution est la hashage du mot de passe, puis vient le chiffrement RSA, l'encodage et enfin, la sauvegarde en clair. Bien entendu, le webmaster devra choisir le mode de stockage le plus sécurisé possible. En ce qui concerne le mdp encrypté en RSA (ou encodé), il sera vivement conseiller d'utiliser des mots de passe générés aléatoirement. Dans le cas contraire, il appartiendra à l'administrateur du site d'avertir les membres des risques encourus.

Cordialement, subØ

[doof]

C'est vrai aussi qu'en y réfléchissant, l'utilisateur ne peut pas savoir la technique utilisée par le webmaster. le webmaster ne peut en aucun cas garantir formelement la confidentialité du mdp quand bien meme il n'y aurait pas acces lui-meme. Autant laisser le choix si ca peut apporter des avantages. (je suis moi-meme assez partagé sur ce point )

[Sub0]

Comparons-nous à un constructeur d'automobiles qui fabriquent des véhicules capables de rouler à plus de 200km/h. Il est clair que c'est extrèment dangereux et interdit de conduire à ces vitesses, mais n'empêche que la responsabilité engagée est celle du conducteur (le webmaster) en cas d'accident ou d'arrestation... pas celle des passagers (les membres), et encore moins celle des ingénieurs qui ont conçu le moteur (les développeurs)...

[doof]

Tout dépend en fait a qui s'adresse ce script d'authentification. Je ne suis pas persuadé de le webmaster soit dans tous les cas le seul maitre sur les procédés utilisés, qu'il puisse avoir acces a tout et qu'on puisse lui faire une confiance absolue. Il peut y avoir une équipe d'admins et en son sein des "taupes".

Prenons pour exemple AOL, dernierement, ils ont arrété 2 des principaux diffuseurs de spams qui opéraient sur leur résau, a eux 2, ils étaient responsables de plusieurs dizaines de millions de spams journaliés. Et bien ils fesaient tout simplement partit de "l'équipe d'administration". Ils avaient accés aux mails et revendaient les listes.

Tout ca pour dire que la sécurité se joue certes sur un bon filtrage de l'acces mais aussi sur la sauvegarde et la conficendialité des données "sensibles". Un mot de passe n'est pas forcement sensible mais j'en connais qui utilisent toujours le meme, et dans le cadre de leur boulot, ca peut donc etre capital dans ce cas si les enjeux en valent la peine.

Mais bon, je ne vois pas de solution miracle, il faut peser le pour et le contre, tout depend dans quel cadre on se trouve. Encore une fois, autant laisser le choix

[Sub0]

On est d'accord. Je suis content de te compter parmis les participants doof. Même si le projet n'est pas une nouveauté en lui-même, il rendra service à beaucoups de webmasters. On peut même imaginer que ce développement devienne une référence dans le domaine!
J'en profite pour lancer un appel à ceux qui se sentent partant pour réaliser un (ou plusieurs) kit graphique pour ce projet. J'ai déjà développé quelque chose compatible IE et Mozilla et j'aimerai l'avis de designers et/ou webmasters intérressés... J'ai aussi développé des fonctions en Javascript pour faciliter, optimiser la saisie des champs des formulaires, l'affichage des erreurs., etc... Je cherche donc un pro du JS (je sais qu'il yen a ici! ) qui serait intérressé et aurait un peu de temps de libre pour en discuter. Merci!

[Sub0]

Salut!

KoO m'a répondu par mail. Voici ses suggestions en ce qui concerne la v1:

1 ------------------------------------------------
Préfixer les variable de config, ou les mettre dans un tableau. Quand
on lit le code, c'est par exemple pas très evident que $bypass_act est
défini dans le fichier de config.

2 ------------------------------------------------
N'afficher le lien de déconnection que si on est connecté....

3 ------------------------------------------------
Le code if($_SERVER['HTTP_HOST']=='127.0.0.1'){
est à remplacer par :
if(($_SERVER['HTTP_HOST']=='127.0.0.1') ||
($_SERVER['HTTP_HOST']=='localhost')){

4 ------------------------------------------------
Ca serait pas mal de regrouper les fonctions de connection à la base
dans une classe, Je ne développerai pas plus, je pense que tu comprend
pourquoi.

5 ------------------------------------------------
Personnelement j'évite toujours les history.back(), donc ca serait
souhaitable de mettre une option dans la config pour spécifier une URL
de retour, si on aime pas cette fonction JS

6 ------------------------------------------------
Lorsque La création du compte echoue, ne pas afficher le mess d'erreur
et le lien pour revenir en arrière, mais l'ancien formulaire + le
message d'erreur, ca fait une page de moins à télécharger pour l'utilisateur.

7 ------------------------------------------------
Peut-être ajouter une option pour afficher ces erreurs en JS (alert)

8 ------------------------------------------------
Commenter les champs de la base dans ta doc. Et fait une doc des
fonction genre phpdocumentor, ca fait jamais de mal :p

9 ------------------------------------------------
En faisant un retour dans l'historique, j'ai réussi à créer 2
fois le meme compte :
-> Je m'inscri
-> j'ai le message qui me dit que j'ai 2heures pour activer mon compte
-> je refresh, hop 2 comptes avec le meme pseudo dans la base !
tu devrais aussi rendre le champ login unique
ALTER TABLE `membres` ADD UNIQUE `login` ( `login` )

10 -----------------------------------------------
Dans la génération d'image, on ne distingue pas le Ø du O

11 -----------------------------------------------
Faire une vérif des formulaires de saisie en JS, ca evite de poster
pour rien

12 -----------------------------------------------
Peut-être prévoir utérieurement une classe ou des fonctions pour
d'autres bases, tous le monde n'est pas sous MySql.

++

Excelentes remarques! Merci KoO!!

[Swoög]

Excellentes Remarques en effet !

la 11 doit être doublé d'une vérification PHP au cas où le Javascript est désactivé...

[wamania]

Salut tout le monde

Je suis le projet depuis le debut, meme si je n'est pas encore montré le bout de mon nez.
J'intervient pour vous dire que j'ai deja utilisé 1 classe (enfin groupe de classes) que je trouvent super bien, cetain connaisse surement, c'est ez_sql
En réalité, il y a autant de classes que de bdd gérée : mySQL, Oracle8, Inerbase/Firebase, PostgreSQL, SQLite (PHP), SQLite (C++), MS-SQL.
Je l'ai un peu étudié et modifiée.
Voici un extrait du readme "License: FREE / Donation (LGPL - You may do what you like with ezSQL - no exceptions.)"
Voila, je crois comprendre qu'il souhaite que toute personne la désirant la télécharge sur son site

www.justinvincent.com

Si ça vous tente, ayant un bonne connaissance de cette classe, je me propose l'adapter espmem.

Wamania

[wamania]

Resalut

J'ai pensé à qq chose aussi. Bon evidemment, c'est pas pour tout de suite, mais je crois qu'il serait intéressant, une fois le RSA installé, de réfléchir à des mods pour les différents forum existants (au moins phpBB et IPB). Car dans un site, il y a souvent les deux (espace membre + forum), souvent indépendant, mais protégés par le même mot de passe.
Voila, si l'idée vous plaît, je pense pouvoir, avec du boulot, le faire pour phpBB, que je connais assez bien.

Wamania

[Sub0]

Salut wamania!
Effectivement, l'idée me paraît pas mal du tout, mais on verra tout ça pour la suite... Et puis, pour le moment, nous allons proposer le hashage du mot de passe en md5 dans les options, ce qui permettrait d'avoir directement le login compatible avec phpbb2... à+

ps: Super la solution pour adapter le projet à d'autres base de données!

[Sub0]

Salut!

wamania a fait du beau travail au niveau de l'option pour choisir le type de bdd!

A ce sujet, je pense qu'il serait bien aussi de proposer une solution sans bdd, avec des fichiers.

A votre avis, quelle serait la meilleure structure à utiliser? csv? un fichier par enregistrement? etc...

Merci de votre aide!

[m@]

csv pour la facilité d'export.

[Sub0]

oui, je pense aussi que le format CSV le fera...
Cela dit, comment interdir l'accès de ce fichier? Comment le protéger pour que l'appli soit la seule à pouvoir y accèder?

Je pensais à une autre solution, certe, moins conventionnelle, mais plus adaptée:
Il sagirait d'avoir, dans un dossier, un fichier par membre, le fichier ayant le nom de l'ID et l'extension PHP.
Au niveau du contenu, la 1ère ligne du fichier serait: <?php die('Accès refusé!');?>
Et les autres lignes seraient les données de l'enregistrement, à raison d'une ligne pour chaque colonne.
L'avantage serait que l'on ne modifierait qu'un seul et même fichier pour un membre, ce qui éviterait la perte de données de tous les membres en cas d'échec.
L'avantage serait aussi qu'il suffirait d'un explode('\n',$data) pour obtenir $row.
La 1ère ligne permet de bloquer l'affichage des données vu que le fichier porte l'extension PHP.
Et pour la conversion de ces fichiers en table et inversement, créer 2 fonctions suplémentaires.

Vos commentaires sont les bienvenus évidemment!

[Swoög]

la plupart des serveurs proposent la fonctionnalitée des htaccess... il suffit de mettre le fichier dans un dossier avec le restriction Deny From All...

ou alors, que PHP soit le proprio du fichier, et que ses droits soient : 0700...

[Sub0]

la plupart des serveurs proposent la fonctionnalitée des htaccess... il suffit de mettre le fichier dans un dossier avec le restriction Deny From All...

ou alors, que PHP soit le proprio du fichier, et que ses droits soient : 0700...

Je n'aime pas utiliser ce genre de méthodes justement... Je vais m'expliquer.
Malgré tout, pourrais-tu donner un exemple de code pour faire des tests?
Par exemple, comment créer un fichier htaccess à l'installation de l'appli...
La plupart des serveurs? Comment ça, ils ne proposent pas tous cette fonctionalité? pourquoi?

En ce qui concerne le chmod(0700); je vais essayer pour voir si c'est un bon moyen...
Mais il faut aussi pouvoir accéder aux fichiers avec d'autres scripts (de gestion par exemple),
et pouvoir ouvrir, sauvegarder et modifier ces fichiers à partir du serveur ftp si nécessaire...
Lors d'un déménagement de l'appli sur un autre serveur, il faudra redéfinir les droits des fichiers, etc...
Merci de détailler un peu les avantages et inconvéniants.

Cordialement, subØ

[Swoög]

certains serveurs ont en effet désactivé (ou modifier, cf Free) cette fonction, c'est dommage! pourquoi ? modification : pour des raisons de simplicité (cf Free toujours )
Suppression ? je sais pas, peut-être pour des raisons de sécurité (bien que ça m'étonnerais)
Et puis il y a aussi les serveurs non-Apache, qui ne possèdent pas cette fonctionnalité...

Pour ce qui est de la création, ça se crée exactement comme un fichier texte ! C'est juste le nom (.htaccess) qui est spécial !!

Avantages : Totalement sûr (géré par le serveur !)

Inconvénient : Innexistant, Désactivité ou Modifié sur certains serveurs...

Pour le chmod, les points que tu as cité sont des inconvénients dont il faut tenir compte !!!! en effet, avec ma technique, pas moyen (normalement) d'accéder au fichier via FTP etc... (À moins que ce ne soit vis-à-vis du nom d'utlisateur et non de PHP que se font les restrictions <== là problème au niveau de la config du serveur !)

Pour le déménagment, d'appli, ça suppose un passage pour le ftp pour déménager les fichiers, ces derniers mettent généralement le chmod à 0777 donc, il suffirait de reposer la restriction au prochain accès à l'espace membre...

Sinon : Avantage : totalement sûr également (géré par le système..)

[Sub0]

Merci Swoög pour ces explications!

Je suis, pour l'instant, plus tranquille avec la méthode des fichiers PHP... Quoiqu'il en soit, nous en sommes à la version2, nous aurons donc le temps de trouver de meilleurs solutions, surtout que la plupart des développeurs participant au projet ne se sont pas encore prononcés...

[m@]

les droits 0700 restent la méthode la plus sûre puisque gérée au niveau du système. -> seuls php peut accéder au fichier.

après, à la réflexion, le moyen le plus universel est l'utilisation de fichier PHP.
définissant les variables pour chaque utilisateur, ou un tableau. on est comme ça sûr que les valeurs ne s'afficheront pas.

avec une fonction d'export CVS se serait parfait.

par contre pour le msg d'erreur s'affichant au départ, je serais plus pour un header 404 ou 403

[wamania]

Oui, je pense aussi qu'un fichier php est le plus universel, meme si j'aime bcp mes petits htaccess.
Je vais regarder tout ça.