Discussion :

[elitemedia]

Salut,

J'aimerais votre avis sur un processus d'inscription à un espace membre :

Le futur membre s'inscrit via un formulaire en ligne, les données sont envoyées et contrôlés minutieusement.

Ensuite je stocke ces données dans une table qui ne sert qu'aux processus d'inscription. A ce moment la je souhaite que le membre valide son adresse email avec un lien envoyé par email, mais souhaite aussi qu'une fois validé, il recoive un autre email avec ses codes Login et Mot de passe en clair.

J'ai donc pensé à stocker le mot de passe du membre en clair dans ma table exclusivement réservée à l'inscription (J'insiste que ca n'est pas la table définitive et qu'ensuite les données seront déplacées et que la nous stockerons son mot de passe Haché par MD5)

Pensez-vous que cela représente un gros risque de stocker temporairement ce mot de passe en clair en attendant qu'il valide son email et que dès que c'est fait j'ai un autre script qui me Hash le mot de passe et qui déplace les données définitives ?

[RideKick]

bah si tu le stocke pour 2 minutes le temps qu'il aille chercher son mail , et qu'ensuite tu le supprime je vois pas trop ce que tu risque.....

[elitemedia]

Bon c'est sur aussi que le gars peut valider son truc 1 semaine après. Tu peux me confirmer ta première réponse quelque soit le délai sur lequel il validera son inscription ?

[RideKick]

Je pense que si tu stocke juste le login/pass dans cette table ça veut dire que la personne (douée soit elle) qui recupere les valeurs de cette table aura juste les couples login/pass de gens qui ne sont pas encore activés ..... et donc ne pourront acceder a leurs compte et donc ne pourront rien faire ....
donc question securité de mon point de vue ça ne pose pas de problemes

[elitemedia]

Ok, merci.
Si d'autres on des suggestions ou remarque sur la méthode elles-sont bienvenues.

Chrstophe.

[gloubi]

Mon avis, c'est que c'est une très mauvaise idée...
ne pas stocker un mot de passe en clair dans une base de donnée est un principe élémentaire de base, quelque soit la durée du stockage !
Déjà, en tant qu'admin, tu auras toi même accès a ces mots de passe, ce qui déjà est déontologiquement et moralement scandaleux et inadmissible !

La seule solution, c'est d'envoyer le mot de passe et le login en meme temps que le lien d'activation !

En aucun cas tu ne dois stocker le mot de pass en clair sur ton serveur ! JAMAIS ! pas même 1 minute.

[elitemedia]

Oui en fait je pense que tu as raison Gloubi. J'y ai réfléchi tout l'après midi, je me suis dit exactement cela.

En fait je vais donc envoyer le mot de passe en clair par mail avec le lien d'activation, je pense que c'est la meilleure solution.

Vous feriez comment pour l'activation au plus simple ? Moi je pensais à un lien contenant le Hash MD5 du password (qui est unique dans la base) et simplement comparer ce Hash à celui de la base ?

[gloubi]

Pas trop trop d'acord, non pas que ça soit un risque important, mais autant éviter de promener le hash du mot de passe...

fait plutot un hash md5 sur la concaténation de plusieurs données, bien que l'idéal a mon avis soit un d'utiliser un hash md5 de quelque chose qui correspond à rien (genre md5(microtime())), de le stocker dans ta base de donnée et l'envoyer comme code d'activation et vérifier lors de l'activation que celui fournit pas l'utilisateur soit le meme que dans ta BDD...

(si c'est pas un lien direct que tu fournis dans le mail de confirmation, pense a mettre un substr des 5 ou 6 premiers caracteres sur ton hash :p )

[elitemedia]

Oui, c'est aussi une technique interressante. Je pense que je vais faire comme ca.

Qu'entends-tu par le fait de faire un substr sur les 5 ou 6 premiers caractères, enfin pour quelle raisons surtout, tu peux développer ?

[vg33]

Pas trop trop d'acord, non pas que ça soit un risque important, mais autant éviter de promener le hash du mot de passe...

fait plutot un hash md5 sur la concaténation de plusieurs données, bien que l'idéal a mon avis soit un d'utiliser un hash md5 de quelque chose qui correspond à rien (genre md5(microtime())), de le stocker dans ta base de donnée et l'envoyer comme code d'activation et vérifier lors de l'activation que celui fournit pas l'utilisateur soit le meme que dans ta BDD...

Tout à fait d'accord.
Je précise que le piratage du mot de passe n'est jamais anodin, car la plupart des internautes utilisent toujours le même mot de passe pour leurs différents comptes. Vous ne faites pas ça ? Donc avec ce mot de passe, tu peux potentiellement accéder à des services beaucoup plus sensibles.

[gloubi]

Qu'entends-tu par le fait de faire un substr sur les 5 ou 6 premiers caractères, enfin pour quelle raisons surtout, tu peux développer ?

Hé bien si tu envois un mail de confirmation demandant a la personne de revenir sur le site pour saisir une clé d'activation, vaut mieux pas qu'il fasse 32 caractères ton code de confirmation lol (taille d'un hash md5) !

imagine, tu vas sur le site pour rentrer le code que tu as reçu dans ton mail, et le code c'est "ebaf14bdd87e0d48cc021b3d70de4503" :p
Toi ou moi, on va faire copier coller et pas poser de question, par contre, monsieur tout le monde...
Quand c'est ça, tu considères que "ebaf14" (donc substr() des 6 1er caracteres) suffit pour être sur que l'utilisateur t'as bien donné son vrai mail

Bien entendu, le plus simple est d'envoyer dans le mail un lien sur lequel l'utilisateur doit juste cliquer pour activer son compte, auquel cas, tu te fout de la taille du code et donc de ma remarque

[elitemedia]

Ok ok, merci gloubi, la je vois bien le truc maintenant.

Bon donc on récapitule le processus :

- L'utilisateur rempli son formulaire, il envoie > Controle des données recues.
- Les données sont OK, on enregistre en base avec le mot de passe déjà Hashé, en même temps on génère une chaine aléatoire hashée que l'on rentre en base et que l'on envoie parallèlement au client par email avec son login et son mot de passe en clair.
- Il confirme son inscription, je déplace les données dans la table définitive.

J'ai bon ?