Discussion :

[Swoög]

pas mal du tout !

1 -> as-tu eu le temps de faire 2/3 benchs entre crack et ton script ?

non, je suis sûr deux projets en même temps là .... désolé, mais je ferai des bench, j'en ai des sûr les include à faire aussi

2 -> je rajouterais des mixs avec les nombres

je vois pas trop où... là je test la présence des chaînes dans le pass... si on met des nombres au milieu, comme ça casse, ça renforce le mot de passe...

3 -> plutôt que d'essayer les différents mélanges nom/prénom à la main, je ferais plut^tot un ereg sur le nom et le prenom

bonne idée, (ch'uis vraiment stupide parfois... )

4 -> sub0 >> pour les commentaires, je les mettrais plutôt après les variables, avis perso.

5 -> une étude très intéressante sur les pswd : http://www.klein.com/dvk/publications/passwd.pdf

cordialement

voyons ça .....

[Sub0]

pour les commentaires, je les mettrais plutôt après les variables, avis perso.

J'ai justifié pourquoi je les ai mises avant (pour éviter le décalage). Et vous? Ya-t-il une raison particulière ou c'est juste pour le côté esthétique du code?

[Swoög]

Perso juste le côté esthétique, et l'habitude que le code soit avant les commentaire.....

[Sub0]

ok. Dans ce cas, comme nous prevoyons de faire un script d'install au final, on mettra les commentaires après le code.
Je reconnais que j'ai aussi l'habitude d'avoir le code avant...

[m@]

l'habitude aussi
pour l'esthétique, ça rend en effet mieux devant

[Sub0]

Merci à tous les deux pour votre aide!
Voici la liste des améliorations à apporter pour la V2. En gris, ce qu'il reste à faire...
http://sub0.developpez.com/html/maj_v2.htm
Si vous voulez participer pour réaliser l'une de ces tâches, contactez-moi!
Très cordialement, sub0

[Swoög]

Je viens de regarder la liste, je pense pouvoir m'occuper des points :

2/6/9/10/23 et 24

plus également, les 16 et 17 je pense...

Si ça convient, me le dire Merci

[m@]

je ne promets rien, je passerai en dernier s'il reste vraiment des trous à boucher

[Sub0]

Salut!

Nous avons "tchatté", Bob, Swoög et moi à propos de la sécurité...
Voici un petit résumé de notre discution:

Pour obtenir une sécurité optimale, il est indispensable de ne pas fournir le mot de passe par mail;
• Le mot de passe sera donné sur le site à l'inscription.
• Un mail permettant d'activer le compte sera envoyé au membre.
• Les mails ne devront jamais contenir d'hyperlien;
Les membres devront se connecter au site et fournir l'identifiant d'activation contenu dans le mail.
• En cas de perte de mot de passe, le membre devra répondre à une question secrète;
Lors de son inscription, le membre devra donc choisir dans une liste une question et y répondre.
• Je suppose qu'il faudra crypter tout ça dans la bdd...

A propos, je suis à la recherche d'une source Delphi d'encryptage/décryptage RSA,
ou bien je vais être obligé de convertir le code du script PHP...

Si vous avez des remarques, des suggestions, des questions, n'hésitez pas!

Cordialement

[Koo]

salut
je vient de lire unpeu les 2 derniere pages post, et je suis d'accord sur qui a été dis sur les chiffres dans le mot de passe et la lib crack.

Je pense aussi que ca serait pasmal de s'inspirer de windoz server et ca gestion des comptes utilisateurs. Par exemple, conserver l'historique des X derniers mots de passe, imposer une durée de vie etc ...


Un autre point qui n'a pas été évoqué pour l'instant et qui va généralement de paire avec l'authentification, c'est les droits de l'utilisateur.
Deja au sein d'ESPMEM, on pourrai distinguer un admin supreme, des modérateurs qui pourrait pas exemple suspendre des comptes, et les utilisateurs.
Ensuite pour l'application qui utilise ESPMEM, des fonctions toutes pretes pour vérifier les droits, les champs qui vont bien dans la table...
Est-ce que vous pensez que ca serait intéressant de rajouter ca, ou alors ca cadre pas trop avec l'application actuelle ?


Bon c'est con, mais créer un cookie pour conserver le login ou login + mdp (ou pas de cookie, c'est à l'admin de décider)


Un petite option qui pourrait être envisageable aussi, c'est que l'utilisateur puisse spécifier une liste d'IP pour son compte. Si l'ip du client qui tente de se logger est différente de celle spécifiée, l'accès est réfusée. Ca peut etre util par exemple si on est derrière un proxy, ou dans une appli intranet où chaque poste a une IP fixe.


et juste sur l'histoire des commentaires après le code, je trouve ca assez étrange, d'ailleur quand on commente une fonction c'est toujours en entete et jamais a la fin. Ca risque d'en perturber plus d'un

[Sub0]

Salut KoO!

Nous avons une bonne liste de modifs pour la V2!

Effectivement, les options que tu proposes (l'historique des mdp, durée de vie, etc) sont biens!
Faut voir si elles sont vraiment utiles dans notre cas...

En ce qui concerne les droits d'utilisateurs, c'est une excelente idée aussi! Ce sera pour la V3.

Pour la création d'un cookie, nous l'avons éliminé d'office pour des raisons de sécurité, mais c'est à l'admin d'en décider en effet!
A prévoir pour la V3...

Pour une liste d'IP, l'idée est intérressante je trouve! Pour la V3 aussi...

Et pour les commentaires avant ou après, il sagit de commenter l'utilité des paramètres.
J'avais envie de les mettre avant pour éviter le décalage lorsque l'admin définirait ses paramètres:

Code :

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

$cfg['site_name']  = 'Mon site';       //  Nom de votre site

ou bien:

Code :

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

/* Nom de votre site  */   $cfg['site_name']  = 'Mon site';

Merci!

[Koo]

a ok ct commentaire juste pour les variables, j'avais pas capté. Ue dans ce cas la, plutot

Code :

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

$cfg['site_name']  = 'Mon site';       //  Nom de votre site

[Sub0]

oui, j'ai précisé justement car il me semblait bien que tu avais confondu avec l'en-tête des fonctions...

Au niveau de la gestion des comptes utilisateurs, ya-t-il d'autre comme option intérressante à part l'historique des mdp et la durée de vie d'un mdp...?

[Swoög]

Si un compte est souvent "attaqué"

on peut peut-être proposé à l'utilisateur de changer de "login'"

désolé pour hier soir : pb de connexion

[Sub0]

Comme l'admin recevra un mail d'alerte au bout d'un certain nombre d'echec d'identification, il pourra prendre des mesures... (blocage de l'IP du pirate, changement de login pour le membre, ...). Je ne pense pas que l'on ait autre chose à ajouter à ce niveau, non? Enventuellement, une blacklist d'IP... et à l'inverse, comme vient de le proposer KoO, une liste d'IP exclusives...

pas de pb! J'ai fais le résumé de notre discution!

[wamania]

Salut sub0
Désolé de ne pas avoir donner de nouvelle avant.
Je ne pourrais pas tester et te donner les dernieres classes avant fin aout, desolé.
Cependant, tu as ce qu'il faut pour commencer (la classe MySQL fonctionnelle), il suffira juste de mettre les autres dans le repertoire fait pour.
Pour le regroupage des fichiers, il y a un moyen simple, il suffit d'include ou tu veux (dans fonction.php par exemple) la classe que tu veux, c'est à dire qu'au lieu de déclarer $bdtype = 'mysql', puis dans db.php inclure mysql.php, tu peux directement include mysql.php, ou celle que tu veux, et virer db.php.
Voila, je continue à bosser dessus (sur les classes), mais je ne donnerais pas de nouvelles avant fin aout.
Bonne continuation

[Faaalllllling]

Au pire ya toujours Pear::DB qu'est pas mal ou bien les classes phpBB

[Sub0]

Salut!

En ce qui concerne l'intégration de différents types de bdd, ce sera prévu pour la V3. Donc, Wamania, tu as le temps de pofiner. En fait, tu le verras dans la V2, j'ai choisi de faire au plus simple: Un fichier PHP par type de base. Chaque fichier contiendra les 6 fonctions dont nous avons besoin actuellement:

• Debug
• OpenBase
• CloseBase
• Query
• Fetch_Array
• Num_Rows

Par exemple, unitbdd1.php pour MySQL, unitbdd2.php pour MSSQL, unitbdd3.php pour PostGreSQL, etc...
Il suffira d'inclure le script correspondant à la base de données souhaitée.
En effet, nous n'avons pas besoin d'utiliser de classe pour la base de données, puisque nous utilisons qu'une seule instance (1 base, 1 table, 1 connexion). Je pense que cela sera plus simple à gérer au final, surtout pour le développement du type de bdd avec fichiers.
Si vous avez des remarques, n'hésitez pas!

Très cordialement

[Sub0]

Salut!

J'ai pas mal progressé, presque fini:
http://sub0.developpez.com/html/maj_v2.htm

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

Pas bonne idée finalement. On trouvera sans doute une meilleure solution, comme l'affichage des messages dans un div centré par exemple (avec Javascript).

N°7 - Ajouter une option pour afficher les erreurs en JS avec alert().

On revient à la même solution que pour la tâche N°6... De plus, la N°12 permet de vérifier la saisie des champs avant l'envoi du formulaire. La fonction alert() est utilisée pour afficher les erreurs, mais j'aimerais plutôt utiliser un div centré là aussi...

N°8 - Commenter les champs de la base dans la doc. Et faire une doc des fonctions genre phpdocumentor.

Quelqu'un serait-il intérressé pour faire la N°8?

N°17 - Ajouter session_regenerate_id() pour lutter contre les vols de sessions.

idem

N°18 - Ajouter une option "grain de sel" (nombre) pour augmenter la dureté du mdp dans le cas d'un mdp choisi par le membre.

Reportée pour la V3

N°20 - Ajouter un formulaire permettant de configurer l'application.

idem

N°22 - Chiffrer avec JS l'envoi du mot de passe au serveur (md5+permutation).

Arf! Je préfère plutôt insister sur la nécessité d'utiliser SSL, non? Qu'en pensez-vous?

à+

[Swoög]

Salut !

OK avec toutes les propositions, et surtout la dernière, pour la N°17, je peux essayer de le faire, en fait, il faut ajouter un regenerate_id(); au début de chaque page page utilisant les sessions (après chaque session_start() quoi ?)

C'est bien ça ???

pour la N°20, même si elle est reportée, je pense que pour l'adapter, il sera plus facile de faire "comme phpBB", àa savoir, stocker la configuration dans une table de BDD...

Comme ça ça sera plus simple à modifier, qu'un fichier....