#22 Mots de passe des comptes communautaires en clair

Closed
opened 1 month ago by Darks · 10 comments
Darks commented 1 month ago

Actuellement les mots de passe des comptes communautaires sont en clair dans le code (lien).

Une solution peut être de générer à la volée un mot de passe pseudo-aléatoire. Par défaut nous n’avons pas besoin de nous connecter à ces comptes, et si besoin il reste possible d’éditer le mot de passe via le panel admin.

C’est un ticket facile à résoudre pour quelqu’un qui souhaite se pencher sur la v5 ;)

Actuellement les mots de passe des comptes communautaires sont en clair dans le code ([lien](https://gitea.planet-casio.com/devs/PCv5/src/branch/master/master.py#L127)). Une solution peut être de générer à la volée un mot de passe pseudo-aléatoire. Par défaut nous n'avons pas besoin de nous connecter à ces comptes, et si besoin il reste possible d'éditer le mot de passe via le panel admin. C'est un ticket facile à résoudre pour quelqu'un qui souhaite se pencher sur la v5 ;)
Darks added the
bug
label 1 month ago
Darks added the
easy
label 1 month ago
Darks removed the
bug
label 1 month ago
Darks added the
security
label 1 month ago
Lephenixnoir commented 1 month ago
Owner

… dans ce cas pourquoi ne pas garder le mot de passe en clair puis le changer via le panel admin pour un vrai mot de passe secret avant d’exposer la prod’ ?

... dans ce cas pourquoi ne pas garder le mot de passe en clair *puis* le changer via le panel admin pour un vrai mot de passe secret avant d'exposer la prod' ?
Darks commented 1 month ago
Owner

Parce qu’on est parti du principe que la prod était exposée avant d’être initialisée ?

Y’a bien un moment où faudra passer par le site web pour créer les comptes admin, etc. et à ce moment là le site sera potentiellement exposé.

La sécurité par l’obscurité c’est pas génial en règle générale. Quitte à changer les mots de passe, je préfère que par défaut ils soient sécurisés. ;)

Parce qu'on est parti du principe que la prod était exposée *avant* d'être initialisée ? Y'a bien un moment où faudra passer par le site web pour créer les comptes admin, etc. et à ce moment là le site sera potentiellement exposé. La sécurité par l'obscurité c'est pas génial en règle générale. Quitte à changer les mots de passe, je préfère que par défaut ils soient sécurisés. ;)
Lephenixnoir commented 1 month ago
Owner

Y’a bien un moment où faudra passer par le site web pour créer les comptes admin, etc. et à ce moment là le site sera potentiellement exposé.

Non, c’est à ça que sert le master script… en ligne de commande… ^^

> Y’a bien un moment où faudra passer par le site web pour créer les comptes admin, etc. et à ce moment là le site sera potentiellement exposé. Non, c'est à ça que sert le master script... en ligne de commande... ^^
Lephenixnoir commented 1 month ago
Owner

Après discussion sur la shoutbox, je suggère comme solution de simplement demander interactivement les mots de passe depuis le master script.

Après discussion sur la shoutbox, je suggère comme solution de simplement demander interactivement les mots de passe depuis le master script.
Breizh commented 1 month ago
Owner

Et pourquoi pas permettre aux admins de poster « en tant que », ou, plus simplement (et probablement plus proprement), de changer l’auteur du post/programme (qui sera une fonction utile, notamment pour redonner un programme posté par un compte communautaire à son auteur officiel si celui s’inscrit sur le site).

D’ailleurs, la même fonction pourra être utilisée automatiquement pour passer en anonyme les publications d’un membre « supprimé » (parce que pourquoi conserver un profil complet et bloquer un pseudo pour quelqu’un qui serait définitivement banni, oui qui a supprimé son compte, par exemple).

Et pourquoi pas permettre aux admins de poster « en tant que », ou, plus simplement (et probablement plus proprement), de changer l'auteur du post/programme (qui sera une fonction utile, notamment pour redonner un programme posté par un compte communautaire à son auteur officiel si celui s'inscrit sur le site). D'ailleurs, la même fonction pourra être utilisée automatiquement pour passer en anonyme les publications d'un membre « supprimé » (parce que pourquoi conserver un profil complet et bloquer un pseudo pour quelqu'un qui serait définitivement banni, oui qui a supprimé son compte, par exemple).
Darks commented 1 month ago
Owner

Pour clarifier mon point de vue, ce qui me dérange c’est que sans interaction supplémentaire de notre part, n’importe qui sachant lire peut se connecter à ces comptes communautaires. Par défaut, ce n’est pas sécurisé.

Que l’on doive pouvoir s’y connecter ou non est un autre débat, tout comme la manière dont résout le problème, que ce soit par un input() lors de leur création, la génération d’un mot de passe aléatoire ou encore un système de nologin pour ces comptes.

Quoi qu’il arrive, par défaut, l’internaute lambda ne doit pas pouvoir s’y connecter.

--- Edit ---

Que l’on change à-postériori le mot de passe ou non ne résout pas le problème initial.

Pour clarifier mon point de vue, ce qui me dérange c'est que sans interaction supplémentaire de notre part, n'importe qui sachant lire peut se connecter à ces comptes communautaires. *Par défaut*, ce n'est pas sécurisé. Que l'on doive pouvoir s'y connecter ou non est un autre débat, tout comme la manière dont résout le problème, que ce soit par un `input()` lors de leur création, la génération d'un mot de passe aléatoire ou encore un système de `nologin` pour ces comptes. Quoi qu'il arrive, *par défaut*, l'internaute lambda ne doit pas pouvoir s'y connecter. --- Edit --- Que l'on change *à-postériori* le mot de passe ou non ne résout pas le problème initial.
Breizh commented 1 month ago
Owner

Mon point c’était de purement et simplement interdire la connexion à ces comptes, oui. Du coup c’est pas un autre débat : si on peut pas s’y connecter, problème résolu. Si on décide qu’on peut, alors il faut voir comment gérer leurs mots de passe.

Pour moi bloquer l’accès et permettre aux admins de changer l’auteur d’une publication est le plus logique et flexible. Ça évite de partager un mot de passe qu’il faut changer à chaque mouvent dans le staff, ça limite les risques d’attaque, c’est plus flexible… bref.

Mon point c'était de purement et simplement interdire la connexion à ces comptes, oui. Du coup c'est pas un autre débat : si on peut pas s'y connecter, problème résolu. Si on décide qu'on peut, alors il faut voir comment gérer leurs mots de passe. Pour moi bloquer l'accès et permettre aux admins de changer l'auteur d'une publication est le plus logique et flexible. Ça évite de partager un mot de passe qu'il faut changer à chaque mouvent dans le staff, ça limite les risques d'attaque, c'est plus flexible… bref.
Darks commented 1 month ago
Owner

Non, c’est à ça que sert le master script… en ligne de commande… ^^

La manip que j’avais en tête, c’était ça :

  • on créé les groupes et les comptes communautaires en CLI
  • on fout le site en ligne
  • tout le monde créé son compte perso, comme ça on contourne pas les mécanismes en place (vérification de l’email, trophées, tout le bordel qui va avec)
  • on donne les droits admins aux comptes qui vont bien en CLI
  • on touche plus au master script parce qu’on a un admin qui est dans la place.

Après si faut pouvoir créer des comptes en CLI c’est une autre histoire, mais ça veut dire que si le compte est créé pour une personne tierce on a un mot de passe qui va être transmis, probablement non changé, etc.

La méthode actuelle me paraissait beaucoup plus avantageuse en terme de fiabilité, malgré le fait qu’elle requiert un usage en deux temps du master script.

> Non, c’est à ça que sert le master script… en ligne de commande… ^^ La manip que j'avais en tête, c'était ça : - on créé les groupes et les comptes communautaires en CLI - on fout le site en ligne - tout le monde créé son compte perso, comme ça on contourne pas les mécanismes en place (vérification de l'email, trophées, tout le bordel qui va avec) - on donne les droits admins aux comptes qui vont bien en CLI - on touche plus au master script parce qu'on a un admin qui est dans la place. Après si faut pouvoir créer des comptes en CLI c'est une autre histoire, mais ça veut dire que si le compte est créé pour une personne tierce on a un mot de passe qui va être transmis, probablement non changé, etc. La méthode actuelle me paraissait beaucoup plus avantageuse en terme de fiabilité, malgré le fait qu'elle requiert un usage en deux temps du master script.
Darks commented 1 month ago
Owner

Mon point c’était de purement et simplement interdire la connexion à ces comptes, oui.

Ça se fait facilement avec un groupe nologin en plus :)

> Mon point c’était de purement et simplement interdire la connexion à ces comptes, oui. Ça se fait facilement avec un groupe `nologin` en plus :)
Lephenixnoir commented 1 month ago
Owner

La manip que j’avais en tête, c’était ça :

Ce qui me va, après tout comme on l’a réalisé plus tard on peut créer directement ces comptes avec leurs mots de passe finaux.

Mon point c’était de purement et simplement interdire la connexion à ces comptes, oui.

Ça ne me dérange pas.

Et pourquoi pas permettre aux admins de poster « en tant que », ou, plus simplement (et probablement plus proprement), de changer l’auteur du post/programme (qui sera une fonction utile, notamment pour redonner un programme posté par un compte communautaire à son auteur officiel si celui s’inscrit sur le site).

Poster en tant que, ça me dérange. Le privilège est trop pété, et même si on peut tout faire en principe, je pense qu’il y a une limite à l’outillage qu’on peut se donner.

Changer les auteurs, ça c’est pas un problème. Combiner ça avec un nologin ne me dérange pas.

> La manip que j’avais en tête, c’était ça : Ce qui me va, après tout comme on l'a réalisé plus tard on peut créer directement ces comptes avec leurs mots de passe finaux. > Mon point c’était de purement et simplement interdire la connexion à ces comptes, oui. Ça ne me dérange pas. > Et pourquoi pas permettre aux admins de poster « en tant que », ou, plus simplement (et probablement plus proprement), de changer l’auteur du post/programme (qui sera une fonction utile, notamment pour redonner un programme posté par un compte communautaire à son auteur officiel si celui s’inscrit sur le site). Poster *en tant que*, ça me dérange. Le privilège est trop pété, et même si on peut tout faire en principe, je pense qu'il y a une limite à l'outillage qu'on peut se donner. Changer les auteurs, ça c'est pas un problème. Combiner ça avec un `nologin` ne me dérange pas.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.