Projet

Général

Profil

Fonctionnalité #13878

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

Ajouté par Robin SALDINGER il y a presque 4 ans. Mis à jour il y a 10 mois.

Statut:
Complément d'Informations
Priorité:
3-Mineur
Assigné à:
Version cible:
Backlogs Produits - Inscription Backlog
Début:
07/05/2020
Echéance:
Version applicable MC:
Tags Courrier:

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 ko) Annotation 2020-05-15 111045.png écran de reconnexion suite à expiration du MDP Emmanuel DILLARD, 15/05/2020 11:15
5195

Historique

#1 Mis à jour par Emmanuel DILLARD il y a presque 4 ans

  • Tracker changé de Régression à Fonctionnalité
  • Statut changé de A qualifier à R&D - A étudier

Lié à l'injection SQL du Param

#2 Mis à jour par Emmanuel DILLARD il y a presque 4 ans

  • Statut changé de R&D - A étudier à Etude planifiée

#3 Mis à jour par Emmanuel DILLARD il y a presque 4 ans

  • Description mis à jour (diff)

#4 Mis à jour par Emmanuel DILLARD il y a presque 4 ans

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

#6 Mis à jour par Emmanuel DILLARD il y a presque 4 ans

  • 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 Mis à jour par Emmanuel DILLARD il y a presque 4 ans

  • Statut changé de Etude planifiée à 17
  • Assigné à changé de EDI PO à 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 Mis à jour par Henri QUENEAU il y a presque 4 ans

  • Statut changé de 17 à A traiter
  • Assigné à changé de Robin SALDINGER à 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 Mis à jour par Henri QUENEAU il y a presque 4 ans

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 Mis à jour par Emmanuel DILLARD il y a presque 4 ans

  • Statut changé de A traiter à 17
  • Assigné à changé de EDI PO à 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 Mis à jour par Henri QUENEAU il y a presque 4 ans

  • Assigné à changé de Henri QUENEAU à Robin SALDINGER

#13 Mis à jour par Emmanuel DILLARD il y a presque 4 ans

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 Mis à jour par Robin SALDINGER il y a plus de 3 ans

  • Assigné à changé de Robin SALDINGER à Henri QUENEAU

#16 Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Priorité changé de 1-Majeur à 2-Sérieux

#18 Mis à jour par Emmanuel DILLARD il y a presque 3 ans

  • Statut changé de 17 à Complément d'Informations

#19 Mis à jour par Emmanuel DILLARD il y a presque 3 ans

  • Projet changé de Backlog à Backlog Courrier
  • Version cible changé de Inscription Backlog Courrier à Inscription Backlog

#21 Mis à jour par Emmanuel DILLARD il y a plus d'un an

  • Assigné à changé de Henri QUENEAU à Sarah BAZIN

#22 Mis à jour par Emmanuel DILLARD il y a 10 mois

  • Priorité changé de 2-Sérieux à 3-Mineur

#23 Mis à jour par Sarah BAZIN il y a 10 mois

  • Assigné à changé de Sarah BAZIN à Nathanaël TRAVIER

Formats disponibles : Atom PDF