Conseils pour un espace membre réussi ?

[psychoreflex]

Bonjour à tous,

J'ai besoin de disposer d' un espace membre pour mon site.
Je n'ai jamais programmé cela, donc je viens chercher vos conseils.
Ce parce que je veux prendre en compte du mieux possible la sécurité et tous les éléments qui sont importants mais que je ne connais pas forcément.

Exemple : Je voudrais placer un système de code chiffré à recopier pour vérifier que celui qui s'inscrit est bien un humain.
Il existe déjà des codes tout fait, avez vous une adresse ou des conseils sur ce sujets (système meilleur que d'autre etc...).

Quels sont les risques à prendre en considération, en terme de piratage, lorsque l'on crée un espace membre?
Il faut penser à gérer les doublons, mais encore ?

Vous l'aurez compris, je souhaite un espace membre qui soit de qualité, donc je suis à l'écoute de tous vos conseils avisés.

Merci d'avance

 

[doic]

Petit conseil tout bête pour certains, mais moi je me suis fait avoir :
Je crypte les mots de passe dans ma base SQL..

ERREUR !

A chaque fois qu'un membre paume sont password, je ne peux pas lui communiquer, j'ai donc du faire un système de changement de mot de passe, avec re-validation par mail... etc...

Bref, même si ça a l'air moins pro, ou moins sécurisé, garde les mots-de-passe de tes membres en clair dans ta base. Tant que les infos de tes membres ne sont pas des secrets (genre, coordonnées bancaires par ex) tu ne prends pas de risque...

Autre chose: pense à avoir une clé d'index assez longue dans ta colonne login, sinon, même sans doublon, deux login commençant par les mêmes lettres risquent de poser problème...

C'est tout ce qui me vient comme ça... ce sont les problèmes que j'ai eus et que je ne souhaite pas aux autres! ;-)

 

[psychoreflex]

C'est exactement le genre de réponse que j'attend. Merci Doc :wink:


Allez-y les autres, faites nous part de vos conseils et expériences en matière d'espace membre !

 

[phpmikedu83]

Même si c'est plus contraignant, je suis carrément contre les mots de passe en clair dans la base de donnée!!!
Si ça pose pas de problème sur ton site, ça peut en poser sur d'autres avec les données présentes dans ta BDD...

 

[doic]

Même si c'est plus contraignant, je suis carrément contre les mots de passe en clair dans la base de donnée!!!
Si ça pose pas de problème sur ton site, ça peut en poser sur d'autres avec les données présentes dans ta BDD...

Tu peux développer stp?
Je ne suis pas opposé à ce que tu dis, mais pour l'instant, j'ai vu plus de Pb que d'avantages à crypter les mdp...
Donc si tu pouvais me donner des contre-exemples, ce serait génial...

 

[sgaze]

Même si c'est plus contraignant, je suis carrément contre les mots de passe en clair dans la base de donnée!!!
Si ça pose pas de problème sur ton site, ça peut en poser sur d'autres avec les données présentes dans ta BDD...

+1

Les mots de passe des utilisateurs sont ultra privés et ne doivent pas être vus. Je pense que tu es un webmaster honnête mais ce n'est pas le cas de tous. Et sachant qu'un même mot de passe est parfois utilisé pour plusieurs inscriptions...

 

[psychoreflex]

Et à part les mots de passe cryptés, quoi d'autre ?

 

[Mumuri]

tu peux peut etre mettre en place une fonction de codage décodage à partir d'une clé privée que tu définis toi méme .
(je n'ai pas de détail cependant)

comme çà ca serai codé dans la base et en plus tu pourrais renvoyer son mot de passe au membre.

 

[psychoreflex]

Bonne idée merci

Et à part les mots de passe cryptés, quoi d'autre ?

 

[doic]

tu peux peut etre mettre en place une fonction de codage décodage à partir d'une clé privée que tu définis toi méme .
(je n'ai pas de détail cependant)

comme çà ca serai codé dans la base et en plus tu pourrais renvoyer son mot de passe au membre.

D'accord avec Mumuri...
Mais au final, tu as bien accès aux passwords de tous tes membres, d'où le problème soulevé par Sgaze... (je le reconnais)

Au final, la solution la plus "honnête" est bien de crypter (md5 par ex) les passwords, et de proposer aux membres de les modifier. C'est aussi ultra-contraignant du point de vue des utilisateurs, qui préfèrent - j'en suis sûr - qu'on leur renvoie leurs passwords par mail...

Je retiendrais donc la solution intermédiaire, de crypter le password avec une clé privée, ce qui permet de ne pas avoir en permanence les passwords en clair dans la base, tout en ayant la possibilité de les envoyer par mail...

Désolé Psychoreflex de m'étendre là-dessus, mais il vaut mieux y réfléchir à deux fois plutôt que de se lancer, comme moi il y'a un an, dans un développement que tu voudras modifier par la suite ! :roll:

 

[psychoreflex]

Pas de problème Doc, c'est noté.

Et à part les mots de passe cryptés, quoi d'autre ?

 

[phpmikedu83]

Même si c'est plus contraignant, je suis carrément contre les mots de passe en clair dans la base de donnée!!!
Si ça pose pas de problème sur ton site, ça peut en poser sur d'autres avec les données présentes dans ta BDD...

+1

Les mots de passe des utilisateurs sont ultra privés et ne doivent pas être vus. Je pense que tu es un webmaster honnête mais ce n'est pas le cas de tous. Et sachant qu'un même mot de passe est parfois utilisé pour plusieurs inscriptions...

Exact, merci de l'avoir précisé ;-) Mais ce qui compte le plus pour moi là dedans, c'est la sécurité et non l'honnêteté, car je pourrais très bien voir les pass et être honnête avec ces données là, ça ne me pose aucun PB :lol:

 

[haderach]

Une autre remarque bête :
Il faut vérifier que les pages accessibles uniquement aux membres ne sont pas accessible par un internaute lambda.

Eviter par exemple de passer en parametre de la page le ID du user!!

 

[psychoreflex]

ça n'est pas une remarque bête, c'est toujours utile d'y penser.

D'autres feed-back sur vos expériences de création d'espace membre s'il vous plaît.

**edit** Pour ce que je veux faire il n'y a pas de pages réservées, c'est la participation aux définitions qui doit être réservée, mais toutes les pages restent visibles avec ou sans identification.

 

[psychoreflex]

En fait, si l'on décomposait le travail, qu'est ce que cela donnerait ?

1) placer un système de session qui récupère les variables d'identification après que le visiteur se soit identifié.

2) Placer une formulaire d'inscription avec génération automatique de mot de passe ou laisser le choix à l'utilisateur en forcant le choix d'un mot de passe avec lettres et chiffres.

3) placer dans ce même formulaire un système de chiffre à recopier pour confirmer que ce n'est pas un robot qui remplit le formulaire.

4) créer la ou les tables.

5) vérifier les doublons lors de l'inscription.

6) créer une zone "mon compte" où l'utilisateur peut modifier ses informations.


Question 1 : Quelles étapes ai-je omis ?

Question 2 : Pourriez-vous m'aider à détailler chacun de ses points ?


Comme ça je me fait un petit cahier des charges bien propre et je me lance dans le code.
Merci

 

[psychoreflex]

Mouif
Pas passionnant le sujet dirait-on.


Tant pis je vais faire un htpass avec apache.
Et pour avoir le code faudra m'envoyer un courrier.
ça fera que 5 jours d'attente allez retour, moins par chronopost.

 

[forummp3]

ben a par l'inscription, le reste tu met les options que tu veux.
Un conseil aussi, met un anti-flood a l'inscription, sinon je peux m'inscrire 1000 fois en une journée et flooder ta base de membre.

 

[psychoreflex]

flooder ?
Je ne sais pas ce que ça veut dire, désolé.

L'anti flood, ne serait-ce pas ce code chiffré généré par PHP sur fond d'image, dont je parle dans un autre message et qui empêche un robot de s'inscrire?
Si c'est de cela dont tu parles, je me demande bien où je vais trouver le code (si ce n'est pas de cela dont tu parles, je me le demande aussi mais je me demande aussi alors de quoi tu parles).

 

[psychoreflex]

Bon après recherche dans google, apparemment on parle de la même chose.
Je dois utiliser la librairie GD éventuellement en lui ajoutant quelques trucs du style "recopiez le chiffre de l'image et ajoutez 4" ou un truc comme ça.

 

[Genesys]

Pêle-mêle :

- Le CAPTCHA est inutile dans le cas présent. Il vaudrait mieux commencer l'inscription en demandant à l'utilisateur de confirmer son adresse e-mail. Une fois celle-ci confirmée, les autres étapes de l'inscription lui seraient présentées.
- En cas d'oubli du mot de passe, proposer à l'utilisateur de créer un nouveau mot de passe (instructions envoyées par mail) plutôt que de lui transmettre directement son mot de passe. Crypter les mots de passe dans une base de données est une bonne habitude à prendre.
- Choix du login : nom d'utilisateur ou adresse e-mail ? Soupeser les avantages et les inconvénients de l'un ou l'autre.
- Vérification de la longueur et de la complexité du mot de passe.
- Prendre garde au vol de sessions : vérifier le cas échéant l'IP et/ou le browser de l'utilisateur authentifié.
- Tracking de l'utilisateur, si on en voit une utilité. Au minimum, stocker la date de dernière connexion.
- Gestion des droits des utilisateurs et, éventuellement des groupes d'utilisateurs, dans le cas où un utilisateur lambda ne disposerait pas des mêmes droits qu'un utilisateur epsilon.
- Case à cocher "Remember me" pour une connexion automatique.
- Comme souvent, le back-office pour blacklister un utilisateur, le forcer à saisir un nouveau mot de passe, le (dé)placer dans un groupe, etc...

Il y a du taff... Bon courage !

 

[psychoreflex]

Super réponse merci

En effet je m'attendais à du taf, comme ça je vois mieux quoi faire.
Tu penses qu'il vaut mieux imposer à l'utilisateur un mot de pass tiré au hasard sur un modèle prédéfini (une lettre, un chiffre,une majuscule etc...) ou le laisser choisir ?

Pour l'identification j'opterais plutot pour le couple email +mot de passe tout en laissant la possiblité à l'utilisateur de choisir un pseudo.

Tracking de l'utilisateur, si on en voit une utilité. Au minimum, stocker la date de dernière connexion

Pourquoi par exemple ?

 

[forummp3]

flooder ?
Je ne sais pas ce que ça veut dire, désolé.

L'anti flood, ne serait-ce pas ce code chiffré généré par PHP sur fond d'image, dont je parle dans un autre message et qui empêche un robot de s'inscrire?
Si c'est de cela dont tu parles, je me demande bien où je vais trouver le code (si ce n'est pas de cela dont tu parles, je me le demande aussi mais je me demande aussi alors de quoi tu parles).

Flooder, ca veut dire faire plein de fois la meme operation, par exemple m'inscrire mille fois. Donc il faut faire une verification sur l'ip pour eviter qu'une ip rentre par exemple maximum 3 inscriptions par jours (si la personne se trompe de pseudo, si une famille veut s'inscrire, si des amis sont dans la meme maison ...).
Parce que si mille personne s'inscrivent 1000 fois, ca va vite saturer ta base.

 

[forummp3]

Super réponse merci

En effet je m'attendais à du taf, comme ça je vois mieux quoi faire.
Tu penses qu'il vaut mieux imposer à l'utilisateur un mot de pass tiré au hasard sur un modèle prédéfini (une lettre, un chiffre,une majuscule etc...) ou le laisser choisir ?

Pour l'identification j'opterais plutot pour le couple email +mot de passe tout en laissant la possiblité à l'utilisateur de choisir un pseudo.

Tracking de l'utilisateur, si on en voit une utilité. Au minimum, stocker la date de dernière connexion

Pourquoi par exemple ?

Il vaut mieux que tu lui genere a l'inscription et que tu lui envoie par mail pour verifier le mail, sinon, si tu fait une activation par mail, il faudrait ensuite verifier a chaque fois que la personne vient sur la zone membre si le mail est validé, donc un test inutile.
Par la suite la personne pourra changer son mot de passe dans sa zone membre.

 

[phpmikedu83]

flooder ?
Je ne sais pas ce que ça veut dire, désolé.

L'anti flood, ne serait-ce pas ce code chiffré généré par PHP sur fond d'image, dont je parle dans un autre message et qui empêche un robot de s'inscrire?
Si c'est de cela dont tu parles, je me demande bien où je vais trouver le code (si ce n'est pas de cela dont tu parles, je me le demande aussi mais je me demande aussi alors de quoi tu parles).

Flooder, ca veut dire faire plein de fois la meme operation, par exemple m'inscrire mille fois. Donc il faut faire une verification sur l'ip pour eviter qu'une ip rentre par exemple maximum 3 inscriptions par jours (si la personne se trompe de pseudo, si une famille veut s'inscrire, si des amis sont dans la meme maison ...).
Parce que si mille personne s'inscrivent 1000 fois, ca va vite saturer ta base.

Flooder, c'est aussi poster plusieurs messages à la suite dans un temps très court :lol: