[sécurité - inscription] : éviter l'envoi de mot de passe en clair par email et laisser l'utilisateur choisir son mot de passe #3778

Open
opened 5 years ago by g0uZ · 12 comments
g0uZ commented 5 years ago

Tout est dans le titre :-)

J'ai déjà fait les modifications sur un SPIP 3.1.1 [22913] ; grosso modo cela consiste à :

  • ajouter un champ au formulaire d'inscription pour le mot de passe (pas de champ de confirmation prévu)
  • appliquer les mêmes vérifications/tests sur le mot de passe que lors de la création/l'édition d'un auteur coté privé
  • supprimer les informations login/mot de passe des emails d'inscriptions

dans le core :

  • squelettes-dist/formulaires/inscription.html
  • squelettes-dist/formulaires/inscription.php
  • ecrire/action/inscrire_auteur.php
  • prive/modeles/mail_inscription.html

coté plugins :

  • plugins/notifications/modeles/mail_inscription.html
  • plugins/notifications/paquet.xml // faire attention lors de la mise à jour du plugin notification (suppression information login/mot de passe du mail de confirmation) à faire correspondre la balise compatibilité à la version du core correspondante

Pour faire mieux en matière de sécurité, on pourrait encore :

  • hacher le mot de passe coté client avec du javascript (comme pour le formulaire de login)
  • remplacer "l'autologin" lors de l'accès au lien de confirmation du compte par un simple message de confirmation (oblige l'utilisateur à se servir du mot de passe)

Est ce qu'on peut déjà intégrer ce changement dans la branche 3.1.2 et dans la future version du plugin notification ?

D'avance merci pour vos retours :-)

Tout est dans le titre :-) J'ai déjà fait les modifications sur un SPIP 3.1.1 [22913] ; grosso modo cela consiste à : - ajouter un champ au formulaire d'inscription pour le mot de passe (pas de champ de confirmation prévu) - appliquer les mêmes vérifications/tests sur le mot de passe que lors de la création/l'édition d'un auteur coté privé - supprimer les informations login/mot de passe des emails d'inscriptions dans le core : * squelettes-dist/formulaires/inscription.html * squelettes-dist/formulaires/inscription.php * ecrire/action/inscrire_auteur.php * prive/modeles/mail_inscription.html coté plugins : * plugins/notifications/modeles/mail_inscription.html * plugins/notifications/paquet.xml // faire attention lors de la mise à jour du plugin notification (suppression information login/mot de passe du mail de confirmation) à faire correspondre la balise compatibilité à la version du core correspondante Pour faire mieux en matière de sécurité, on pourrait encore : * hacher le mot de passe coté client avec du javascript (comme pour le formulaire de login) * remplacer "l'autologin" lors de l'accès au lien de confirmation du compte par un simple message de confirmation (oblige l'utilisateur à se servir du mot de passe) Est ce qu'on peut déjà intégrer ce changement dans la branche 3.1.2 et dans la future version du plugin notification ? D'avance merci pour vos retours :-)
b_b commented 5 years ago
Owner

Merci pour la proposition :)

L'idée est bonne, mais je doute sur deux points :

  1. on va se retrouver avec des pass de merde genre toto
  2. plus important : c'est amha "un frein" à l'inscription, ça demande à la personne de réfléchir, trouver le bon pass, alors qu'aujourd'hui, tu entres ton mail et hop

À discuter.

Merci pour la proposition :) L'idée est bonne, mais je doute sur deux points : 1) on va se retrouver avec des pass de merde genre toto 2) plus important : c'est amha "un frein" à l'inscription, ça demande à la personne de réfléchir, trouver le bon pass, alors qu'aujourd'hui, tu entres ton mail et hop À discuter.
Poster

ce que je disais sur IRC :

  1. dépend de l'admin du spip, il a les variables disponibles pour forcer des mot de passe long

  2. choisir un mot de passe, c'est quand même la base. Et surtout la création de mot de passe automatique c'est un vrai frein à l'accès (imo spip propose pas, par défaut, de form de changement de mdp coté public) donc faut se souvenir d'un truc aléatoire ou aller taper dans ses emails a chaque connexion...

  3. on peut aussi ajouter un truc "fancy" en javascript pour informer (uniquement) l'utilisateur en affichant un score de complexité lisible facilement à coté/en dessous du champ du mot de passe

ce que je disais sur IRC : 1) dépend de l'admin du spip, il a les variables disponibles pour forcer des mot de passe long 2) choisir un mot de passe, c'est quand même la base. Et surtout la création de mot de passe automatique c'est un vrai frein à l'accès (imo spip propose pas, par défaut, de form de changement de mdp coté public) donc faut se souvenir d'un truc aléatoire ou aller taper dans ses emails a chaque connexion... 2) on peut aussi ajouter un truc "fancy" en javascript pour informer (uniquement) l'utilisateur en affichant un score de complexité lisible facilement à coté/en dessous du champ du mot de passe

Hello,

Même si c'est effectivement plus facile de s'inscrire d'un seul coup de mail, il me paraît indispensable de remplacer ce système d'envoi de mdp en clair, qui est contre toutes les bonnes pratiques en termes de sécu aujourd'hui.

Hello, Même si c'est effectivement plus facile de s'inscrire d'un seul coup de mail, il me paraît indispensable de remplacer ce système d'envoi de mdp en clair, qui est contre toutes les bonnes pratiques en termes de sécu aujourd'hui.

Comme vu sur IRC, il existe donc déjà un plugin pour ça :
http://zone.spip.org/trac/spip-zone/browser/plugins/inscription_motdepasse/trunk

Qui n'a toujours pas de doc depuis 2 ans, mea culpa…

À re-tester et améliorer (à priori Guillaume va ajouter les surcharges de squelettes emails pour ne plus afficher le mot de passe).

Et si on pense donc que c'est vraiment mieux pour la sécurité (et je le pense aussi, pour l'instant), on pourrait intégrer les modifications de ce plugin directement dans le noyau, en 3.2 par exemple, et bloquer sa compat à la version 3.1.

Comme vu sur IRC, il existe donc déjà un plugin pour ça : http://zone.spip.org/trac/spip-zone/browser/_plugins_/inscription_motdepasse/trunk Qui n'a toujours pas de doc depuis 2 ans, mea culpa… À re-tester et améliorer (à priori Guillaume va ajouter les surcharges de squelettes emails pour ne plus afficher le mot de passe). Et si on pense donc que c'est vraiment mieux pour la sécurité (et je le pense aussi, pour l'instant), on pourrait intégrer les modifications de ce plugin directement dans le noyau, en 3.2 par exemple, et bloquer sa compat à la version 3.1.
Poster

Il faudrait faire un article minimaliste sur contrib, les MAJ sont faites : http://zone.spip.org/trac/spip-zone/browser/plugins/inscription_motdepasse/trunk

Il resterait à :

  • éviter l'autologin via le lien de confirmation de l'email
  • hacher le mot de passe clientside (possible ?)
Il faudrait faire un article minimaliste sur contrib, les MAJ sont faites : http://zone.spip.org/trac/spip-zone/browser/_plugins_/inscription_motdepasse/trunk Il resterait à : - éviter l'autologin via le lien de confirmation de l'email - hacher le mot de passe clientside (possible ?)
Collaborator

j'ai écrit la documentation de base et crée le zip
https://contrib.spip.net/ecrire/?exec=article&id_article=4802

n'hésitez à la modifier

j'ai écrit la documentation de base et crée le zip https://contrib.spip.net/ecrire/?exec=article&id_article=4802 n'hésitez à la modifier
Poster

super ! merci erational !

pour mémoire :

[20/05/2016 11:04] tu crois qu'on peut hasher le mdp coté client en javascript sans que ce soit une usine a gaz ?
[20/05/2016 11:04] mmh aucune idée… :(
[20/05/2016 11:04] faudrait intégrer le sel dans le formulaire envoyé, comme pour le login...

à faire et à intégrer un jour dans le core ? :-)

super ! merci erational ! pour mémoire : [20/05/2016 11:04] <g0uZ> tu crois qu'on peut hasher le mdp coté client en javascript sans que ce soit une usine a gaz ? [20/05/2016 11:04] <RastaPopoulos> mmh aucune idée… :( [20/05/2016 11:04] <g0uZ> faudrait intégrer le sel dans le formulaire envoyé, comme pour le login... à faire et à intégrer un jour dans le core ? :-)

"spip propose pas, par défaut, de form de changement de mdp coté public"

Une demande en ce sens à été faite pour que "invités" qui s'inscrivent aient une possibilité de gestion similaire à celle des auteurs, notamment en ce qui concernent leurs données personnelles (dont le mot de passe)
https://core.spip.net/issues/3483

Cette contrib apporte une amélioration mais oublie un détail ; en cas de perte du mot de passe c'est le retour à la case départ, l'invité se retrouvera :

  • avec un mot de passe tordu qu'il collera sur un post it ou enregistrera dans son navigateur,
  • un sentiment de frustration en ne pouvant pas à nouveau le choisir
"spip propose pas, par défaut, de form de changement de mdp coté public" Une demande en ce sens à été faite pour que "invités" qui s'inscrivent aient une possibilité de gestion similaire à celle des auteurs, notamment en ce qui concernent leurs données personnelles (dont le mot de passe) https://core.spip.net/issues/3483 Cette contrib apporte une amélioration mais oublie un détail ; en cas de perte du mot de passe c'est le retour à la case départ, l'invité se retrouvera : - avec un mot de passe tordu qu'il collera sur un post it ou enregistrera dans son navigateur, - un sentiment de frustration en ne pouvant pas à nouveau le choisir
Poster

Je ne sais pas quelle version de SPIP tu utilises, mais pour moi le "problème" dont tu parles est réglé : le lien reçu par un visiteur lors de la perte d'un mot de passe lui permet bien de le changer lui même.

Ce formulaire n'est par contre accessible que dans le cas ou la "demande d'un mot de passe perdu" est faite.

Je ne sais pas quelle version de SPIP tu utilises, mais pour moi le "problème" dont tu parles est réglé : le lien reçu par un visiteur lors de la perte d'un mot de passe lui permet bien de le changer lui même. Ce formulaire n'est par contre accessible que dans le cas ou la "demande d'un mot de passe perdu" est faite.

Au temps pour moi, la discussion avait été initiée de manière plus globale sur les "invités" lors de la sortie de la version 3.0.19 mais j'avais peut être testé sur une version + ancienne.
N’étant plus en charge de nos sites et ceux-ci ayant migré sous un cms concurrent, mes souvenirs sont plutôt moyens :-)
En tout cas, merci pour cette précision.

Au temps pour moi, la discussion avait été initiée de manière plus globale sur les "invités" lors de la sortie de la version 3.0.19 mais j'avais peut être testé sur une version + ancienne. N’étant plus en charge de nos sites et ceux-ci ayant migré sous un cms concurrent, mes souvenirs sont plutôt moyens :-) En tout cas, merci pour cette précision.
Owner

Version cible mise à 80. Inscription

**Version cible mise à 80. Inscription**
There is no content yet.
cy.altern added the
Inscription
label 1 week ago
cy.altern removed this from the (deleted) milestone 1 week ago
Sign in to join this conversation.
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.