comme discuté sur IRC je voulais discuté avec vous d’un problème lié au fonctionnement des inscription coté public sur nos SPIP.
Actuellement le mail de confirmation reçu par le visiteur contient :
un login/mdp
un lien de confirmation
Le lien de confirmation est actuellement inutile sauf par confort d’utilisation ; l’inscription est confirmée au moment ou l’utilisateur s’authentifie (au niveau du code aussi via confirmer_statut_inscription() appelée dans ecrire/inc/auth.php/auth_init_droits() ).
Pour des raisons de sécurité, nous avons développé ce plugin avec Rastapopoulos (http://contrib.spip.net/Mot-de-passe-des-l-inscription). Avec, seul le lien de confirmation est envoyé dans le mail, le mdp est choisi à l’inscription.
Sans m’étendre il est plus sécurisé de laisser l’utilisateur choisir son mot de passe que d’en générer un aléatoire envoyé par mail (HTTPS>SMTP(S)).
A termes il est envisagé d’intégrer ce fonctionnement dans le core de SPIP. Hors en l’état actuel, avec le plugin il est possible de créer un compte avec une adresse email invalide (!) : le login et le mdp, choisi à l’inscription, permettent de valider le compte en s’authentifiant.
D’ou mon idée de rendre réellement obligatoire (comme sur tous les sites web) le passage par le lien de confirmation de l’adresse mail.
Techniquement ca se traduirait par les modifications suivantes :
déplacer l’appel à confirmer_statut_inscription() qui est dans ecrire/inc/auth.php/auth_init_droits() (appelé a chaque login) dans ecrire/action/confirmer_inscription.php
modifier auth_init_droits() pour refuser l’authentification pour $row[‘statut’] == ‘nouveau’
Est ce envisageable ?
D’avance merci pour le temps que vous y consacrerez
la reflexion est intéressante car en effet il devient de moins en moins sérieux d'envoyer ce mot de passe par email en clair.
En ce qui me concerne je serai plutot pour une suppression complète des mots de passe (ou disons que ça serait un mode de secours dérogatoire), l'authentification se faisant systématiquement par l'envoi d'un email avec un lien à cliquer :
Login : tu rentre ton email, submit > tu reçois un mail > tu clic et tu est logué
Tant que le core continue à envoyer le mot de passe par email, difficile de changer le moment où on valide un statut, car cela restreindrait le fonctionnement nominal : la possession du mot de passe implique bien la reception du mail.
A partir de ce moment là il y a plusieurs façon de faire pour votre plugin :
- avoir 2 étapes : etape 1 tu ne rentre que l'email et tu reçois un mail avec un lien à cliquer qui te donne accès à un formulaire de choix de mot de passe (pourquoi continuer à demander un login ?)
Perso c'est ce que je préfèrerai car c'est un processus plus engageant.
Au départ l'utilisateur ne rentre qu'un email, c'est le plus simple possible et quand on lui présente le formulaire de choix de mot de passe il est déjà dans le processus d'inscription, il a déjà donné son email et donc il sera moins tenté de s'arrêter en cours.
A contrario il est montré que plus un formulaire d'inscription comporte d'informations à remplir, plus il arrête d'utilisateurs.
- inscrire les auteurs en statut 5poubelle au lieu de nouveau, ce qui fait qu'ils ne peuvent pas se loger et le plugin fournit une action de confirmation spécifique qui se charge de valider et activer le compte
Cela dit en reflechissant il est peut-être possible de faire un compromis, en modifiant le core pour que
1/ l'action confirmer appelle elle aussi la fonction confirmer_statut_inscription()
2/ le login avec statut appelle une autorisation dédiée avec le statut en argument, qui par défaut enverra true pour tous les statuts sauf 5poubelle mais qu'il sera possible de passer à false pour nouveau aussi, via surcharge
Cela devrait permettre de garder le fonctionnement inchangé pour le core et de faire ce que vous voulez sur le plugin
2/ le login avec statut appelle une autorisation dédiée avec le statut en argument, qui par défaut enverra true pour tous les statuts sauf 5poubelle mais qu’il sera possible de passer à false pour nouveau aussi, via surcharge
ajout de l’autorisation autoriser_auteur_authentifier_dist dans ecrire/inc/autoriser.php :
Sur ce point là, un référentiel de sécurité (RGS je sais plus quoi) auquel j'ai été confronté récemment indique qu'il faut privilégier une connection avec un login plutôt qu'avec un email, qui est une donnée publique trop facile à obtenir.
Juste mes deux brouzoufs.
