Project

General

Profile

Fonctionnalité #13878

Utilisateurs : Réinitialisation des mots de passe suite à injection SQL

Added by Robin SALDINGER about 2 years ago. Updated 11 months ago.

Status:
Complément d'Informations
Priority:
2-Sérieux
Assignee:
Target version:
Backlogs Produits - Inscription Backlog
Start date:
05/07/2020
Due date:
Tags Courrier:
ROADMAP:

Description

Contexte
Je débute un projet avec un client. Je lui fournis le tableau de paramétrage qu'il me renvoi rempli avec ses données (surtout ses users). J'intègre le sql généré par ce tableau dans Maarch Courrier.
En 1904 :

  • a la première connexion, les users créés via tableau se connectaient avec le mdp maarch et étaient invités à changer leur mdp.
    --> OK

  • le superadmin pouvait réinitialiser le mdp des users, qui étaient invités à le modifier à la prochaine reconnexion.
    --> OK

  • Par la suite, a la première connexion, les users créés graphiquement se connectaient avec le mdp maarch et étaient invités à changer leur mdp.
    --> OK

  • Concrètement, à l'injection/création des users et lorsque superadmin réinitialisait manuellement le mdp, le champ "change_password" de la table "users" passait de "f" à "t". Par la suite, on pouvait réinitialiser l'ensemble de mdp de la base via une simple requête sql.
    --> OK

Maintenant en 2003, la logique a changée : on ne parle plus de réinitialisation mais d'un envoi de mail, qui invite à modifier le mot de passe. donc :

  • à la première connexion, les users créés via tableau se connectent avec le mdp maarch : ils ne sont plus invités à modifier leur mdp. Il faut qu'ils se rendent dans "profil" > "modifier mon mdp"
    --> PAS OK : ces users ne sont pas forcés de créer un nouveau mdp, certains ne le feront pas par facilité (c'est sur)

  • le superadmin ne peut que "renvoyer le courriel d'activation", ce qui ne force pas la réinitialisation des mdp des users qui n'auraient pas changés manuellement le leur.
    --> PAS OK : avant le superadmin s'assurait qu'en cliquant sur "reinitialiser le mdp", le mdp serait obligatoirement changé par le user. Il faut également qu'il s'assure que l'adresse mail de l'user est bonne.

  • Par la suite, à la première connexion, les users créés graphiquement ne peuvent pas se connecter tant qu'ils n'ont pas définis leur mdp grâce au mail.
    --> OK :le mdp par défaut est généré aléatoirement, l'user est obligé d'en changer pour pouvoir se connecter

  • De plus, le champ "change_password" de la table "users" a disparu.
    --> PAS OK : On ne peut plus réinitialiser l'ensemble de mdp de la base via une requête sql.

Du coup la question est : comment forcer les utilisateurs à modifier leur mot de passe à la première connexion quand ils ont été intégrés grâce à un tableau de paramétrage (80% des users) ?
Ici on ne peut pas mettre un mot de passe complexe par défaut (sans leur donner) et les inviter à cliquer sur "mdp oublié" à la première connexion car dans le cadre de projets avec des users génériques par exemple, l'adresse mail associée l'est aussi (générique).

Annotation 2020-05-15 111045.png (38.8 KB) Annotation 2020-05-15 111045.png écran de reconnexion suite à expiration du MDP Emmanuel DILLARD, 05/15/2020 11:15 AM
5195

History

#1 Updated by Emmanuel DILLARD about 2 years ago

  • Tracker changed from Régression to Fonctionnalité
  • Status changed from A qualifier to A étudier

Lié à l'injection SQL du Param

#2 Updated by Emmanuel DILLARD about 2 years ago

  • Status changed from A étudier to Etude planifiée

#3 Updated by Emmanuel DILLARD about 2 years ago

  • Description updated (diff)

#4 Updated by Emmanuel DILLARD about 2 years ago

  • Subject changed from Réinitialiser les mots de passe des utilisateurs à la première connexion suite à une injection de PARAM to Utilisateurs : Réinitialisation des mots de passe suite à injection SQL

#6 Updated by Emmanuel DILLARD about 2 years ago

  • Injection SQL : mot de passe par défaut (générer et communiquer les mdp...)
  • Renvoi du courriel d'activation : si suivi lien, chgt mdp, sinon, le mot de passe initial est toujours actif.

-> obliger un utilisateur à changer son mdp (forcer la réinitialisation du mot de passe) flag.

#7 Updated by Emmanuel DILLARD about 2 years ago

  • Status changed from Etude planifiée to 17
  • Assignee changed from EDI PO to Robin SALDINGER

-> utiliser la création via WS et plus par SQL
(contrôles et mécanisme absents en SQL)
https://docs.maarch.org/gitbook/html/MaarchCourrier/20.03/guat/guat_architecture/API_REST/Users.html

Contournement :
Activer l'expiration des mots de passe (ex 1 jour)
Mettre une date antérieure dans password_modification_date des users (< 1 jour)
Pensez à désactiver.

#8 Updated by Henri QUENEAU about 2 years ago

  • Status changed from 17 to A traiter
  • Assignee changed from Robin SALDINGER to EDI PO

Emmanuel DILLARD a écrit :

  • Injection SQL : mot de passe par défaut (générer et communiquer les mdp...)
  • Renvoi du courriel d'activation : si suivi lien, chgt mdp, sinon, le mot de passe initial est toujours actif.

-> obliger un utilisateur à changer son mdp (forcer la réinitialisation du mot de passe) flag.

  • C'est une injection des nouveaux comptes utilisateurs en masse via des requetes sql généré à partir du fichier de paramétrage 2003.
  • le fichier de param ne permet pas de générer aléatoirement un mot de passe
  • le souhait est de :
  • permettre d'envoyer un mail de réinitialisation du mot de passe en masse à tous les utilisateurs en un clic. ou
  • permettre de générer un mail indiquant qu'un compte a été créé pour cette utilisateur.

Emmanuel DILLARD a écrit :

-> utiliser la création via WS et plus par SQL
(contrôles et mécanisme absents en SQL)
https://docs.maarch.org/gitbook/html/MaarchCourrier/20.03/guat/guat_architecture/API_REST/Users.html

Contournement :
Activer l'expiration des mots de passe (ex 1 jour)
Mettre une date antérieure dans password_modification_date des users (< 1 jour)
Pensez à désactiver.

  • lors de la création en WS, le mail est bien généré, sauf que le fichier de param ne permet pas d'injecter en ws. ==> est ce que c'est dans la roadmap des développeur, d'ajouter une fonctionnalité permettant d'injecter en ws?
  • Est ce que l'expiration du mot de passe envoi automatiquement un mail à l'utilisateur?
  • L'idée est que ça soit automatique.

Pour info c'est une demande de JLE

#9 Updated by Henri QUENEAU about 2 years ago

Je viens de faire le test de création d'un compte pour voir si il y a un envoi de mail lors de l'expiration comme demandé ci-dessus:

  • modification dans l'administration de la sécurité et passage de l'expiration du mot de passe à 1 jour
  • injection du compte en sql à 11:00 - 14-05-2020
  • en base de données, modification du champs password_modification_date de la table user du compte nouvellement créé avec la valeur 11:05 - 14-05-2020
  • attente du mot de passe à 11:05 - 14-05-2020
  • aucune réception de mail d'expiration à 11:05 - 14-05-2020 ni à 11:06 - 14-05-2020

==> en faisant ce test, ceci montre que malgré l'ajout d'une date d'expiration, il n'y a pas de mail demandant à la personne de modifier son mot de passe.

#10 Updated by Emmanuel DILLARD about 2 years ago

  • Status changed from A traiter to 17
  • Assignee changed from EDI PO to Henri QUENEAU

Lorsque le mot de passe expire, il n'y a pas de tache d'envoi de notification utilisateur, mais une invite à la connexion.

A tester : invite de connexion de l'utilisateur dont le mot de passe est expiré
(identifiant utilisateur et mdp par défaut injecté via SQL)

-> il n'y a pas de ticket roadmap sur un outil d'injection par WS (user ou autre)
-> l'expiration du mot de passe ne notifie pas l'utilisateur. C'est à l'invite de connexion que le processus s'opère.

Pour que ce soit standard (et automatique), il est nécessaire de passer par injection WS

#12 Updated by Henri QUENEAU almost 2 years ago

  • Assignee changed from Henri QUENEAU to Robin SALDINGER

#13 Updated by Emmanuel DILLARD almost 2 years ago

Nous proposons une réunion pour systématiser l'utilisation et l'injection par WS.
Pour ne pas pérenniser l'injection SQL au bénéfice/ risque peu avantageux

#14 Updated by Robin SALDINGER over 1 year ago

  • Assignee changed from Robin SALDINGER to Henri QUENEAU

#16 Updated by Emmanuel DILLARD over 1 year ago

  • Priority changed from 1-Majeur to 2-Sérieux

#18 Updated by Emmanuel DILLARD 12 months ago

  • Status changed from 17 to Complément d'Informations

#19 Updated by Emmanuel DILLARD 11 months ago

  • Project changed from Backlog to Backlog Courrier
  • Target version changed from Inscription Backlog Courrier to Inscription Backlog

Also available in: Atom PDF