Permettre aux administrateurs de toujours modifier les e-mails même lorsque « Modifier l'e-mail après l'inscription » est désactivé

Contribuer Fonctionnalité
1

Modifié pour apporter des clarifications significatives et des critères de suggestion mieux réfléchis, afin d’aider les autres membres de la communauté à comprendre les avantages de cette amélioration de fonctionnalité.

Mettez à jour le paramètre Email modifiable pour ajouter des options concernant qui peut modifier les adresses e-mail, comme le prévoit la conception du paramètre, par exemple :

  • Tous les utilisateurs
  • Utilisateurs uniquement [Les administrateurs normaux ou les modérateurs ne peuvent pas le faire sans utiliser la console Rails ou modifier le paramètre.]
  • Personnel uniquement
  • Administrateurs uniquement

Si le paramètre est activé [ce qui est le cas par défaut], introduisez un mécanisme de sécurité de type « mode Sudo » pour effectuer l’action en tant qu’administrateur [et non en tant que l’utilisateur auquel appartient le compte modifié] ; cela permet d’introduire ce paramètre tout en assurant la sécurité contre les modifications non désirées, grâce aux points clés mentionnés ci-dessous.

Raisonnement / Pourquoi cela doit être fait

Si vous souhaitez désactiver ce paramètre, par exemple pour garder le contrôle (les utilisateurs doivent demander la modification, vous le faites par souci de sécurité, ou pour toute autre raison), mais que vous avez tout de même besoin de modifier une adresse e-mail : avec ce paramètre désactivé, même les administrateurs ne peuvent pas modifier les e-mails.

C’est là qu’apparaît un nouveau problème, si l’un ou plusieurs des cas d’usage suivants s’appliquent.

Pour modifier actuellement les e-mails des utilisateurs, vous avez deux options : 1) Activer le paramètre dans un autre onglet et modifier rapidement l’e-mail, ou 2) Ouvrir la console Rails et modifier manuellement l’e-mail.

Pour la plupart des opérations quotidiennes courantes des administrateurs, cela peut poser un défi technique indésirable, surtout si vous vous fiez uniquement à la console Rails pour tout faire, alors que le paramètre existe.

Pourquoi des garde-fous supplémentaires pourraient aider à concrétiser cette fonctionnalité :

  • Si le paramètre reste activé pour des raisons techniques, des utilisateurs compromis pourraient voir leurs e-mails modifiés.
  • Les administrateurs pourraient commettre des erreurs ou effectuer des modifications non autorisées.
  • Les utilisateurs auront le sentiment que ceux qui disposent de cet accès sont protégés contre des modifications malveillantes.

Ce sujet a été discuté pour la dernière fois en 2015. Bien qu’il soit vrai que vous puissiez modifier les e-mails, vous ne pouvez pas le faire depuis la vue administrateur ; le système vous indique d’aller à la vue des préférences utilisateur. Je le fais, mais même en tant qu’administrateur, je ne peux pas le faire en raison des contraintes de ce paramètre.

image
image1025×291 11.5 KB

1 « J'aime »
2

Oui, je suis très fortement en désaccord ici. Bien que votre cas d’usage spécifique puisse vous sembler assez simple, implémenter une simple substitution dans l’interface utilisateur pour cela introduirait un risque de sécurité significatif pour un gain de commodité très mineur.

La friction est une fonctionnalité de sécurité !

L’inconvénient d’avoir à utiliser la console Rails ou d’activer un paramètre au niveau du site est en fait une fonctionnalité de sécurité critique, car elle agit comme un « frein de sécurité » et force un administrateur à suivre un processus délibéré et à forte friction pour une opération très sensible.

Changer l’adresse e-mail d’un utilisateur revient à remettre les clés de son compte, car la nouvelle adresse e-mail peut être utilisée pour déclencher une réinitialisation de mot de passe, verrouillant efficacement l’utilisateur original et donnant au propriétaire du nouvel e-mail un contrôle total.

Quelques vecteurs d’attaque principaux que cette friction empêche :

  • Compromission des comptes administrateurs ! - C’est le risque le plus important. Si un attaquant obtient l’accès à un compte administrateur (via du hameçonnage, la réutilisation de mots de passe, etc.), un simple bouton ou bascule dans l’interface lui permettrait de prendre silencieusement et facilement le contrôle de n’importe quel autre compte utilisateur, y compris ceux d’autres membres du personnel ; l’exigence d’un accès shell via la console Rails fournit une couche de sécurité solide.

  • Ingénierie sociale ! - Cela ouvre la porte à l’ingénierie sociale. Un utilisateur malveillant pourrait se faire passer pour un utilisateur légitime et persuader un administrateur de lui changer son adresse e-mail ; là encore, le processus actuel à forte friction rend un administrateur beaucoup plus susceptible de vérifier ou de considérer l’authenticité de la demande.

  • Menace interne - Un administrateur malveillant pourrait abuser de cette fonctionnalité pour prendre le contrôle de comptes.

Pour ce type d’actions administratives rares et à haut risque, la console Rails est appropriée car elle garantit que la personne effectuant l’action a un accès serveur et non une session compromise. De plus, l’action est délibérée et nécessite des connaissances techniques spécifiques (et elle est enregistrée dans l’historique du shell).

1 « J'aime »
3

Je vous remercie de votre inquiétude, mais je pense que vous avez mal compris la situation dans son ensemble, y compris une faille sérieuse dans votre argumentation concernant la « sécurité ».

Vous pouvez déjà modifier les e-mails si ce paramètre est activé ; ce qui est le cas par défaut.

Compromission des comptes administrateurs ! – c’est le risque le plus important. Si un attaquant accède au compte d’un administrateur (via du hameçonnage, une réutilisation de mot de passe, etc.), un simple bouton ou interrupteur dans l’interface lui permettrait de prendre silencieusement et facilement le contrôle de n’importe quel autre compte utilisateur, y compris ceux d’autres membres du personnel ; l’exigence d’un accès shell via la console Rails constitue une couche de sécurité solide.

Si un administrateur est compromis, l’intrus pourrait simplement activer le paramètre qui existe déjà aujourd’hui et faire les choses que vous mentionnez.

Changer l’adresse e-mail d’un utilisateur équivaut à lui remettre les clés de son compte, car la nouvelle adresse peut être utilisée pour déclencher une réinitialisation de mot de passe, verrouillant ainsi l’utilisateur original et donnant au nouveau propriétaire de l’adresse un contrôle total.

Pour ce type d’actions administratives rares mais à haut risque, la console Rails est appropriée car elle garantit que la personne effectuant l’action dispose d’un accès serveur et non d’une session compromise. De plus, l’action est délibérée et nécessite des connaissances techniques spécifiques (et elle est enregistrée dans l’historique du shell).

Pas toujours, et comme je l’ai dit dans le premier message. Vous pouvez simplement activer et désactiver le paramètre pour activer la fonction de modification. Le seul problème est que l’activation du paramètre, qui est censé être désactivé [activé par défaut], introduit la possibilité pour les utilisateurs qui ne sont pas administrateurs de modifier leur e-mail, tandis qu’une simple modification est en cours.

1 « J'aime »
4

D’accord, je vois maintenant votre point de vue concernant le moment où ce paramètre est basculé.

Je reste convaincu que la console Rails est la meilleure solution ici. Une extension pourrait peut-être être envisagée.

5

Lorsque le paramètre est ACTIVÉ

« Autoriser les utilisateurs à modifier leur adresse e-mail après l’inscription »

Cela permet la modification pour TOUS les utilisateurs (et les administrateurs). La demande de fonctionnalité simple est la suivante : permettre de configurer ce paramètre pour, par exemple : « Administrateurs uniquement », « Administrateurs + Utilisateurs » ou « Utilisateurs ».

Si je l’active simplement, cela permet à n’importe qui [ou aux administrateurs] de modifier l’e-mail d’un utilisateur sur l’ensemble du site, tant que le paramètre est activé.

L’ajout d’un paramètre, qui existe déjà partiellement, pour l’appliquer aux administrateurs uniquement, permet d’éviter que cette fonctionnalité simple, qui existe déjà, ne se limite à un scénario du type « Tout ou Rien ».

1 « J'aime »
6

ok, en y réfléchissant davantage, je pense qu’une méthode d’interface utilisateur à forte friction, via sudo, pourrait être la meilleure solution, car ce paramètre est « non sécurisé » pour la fenêtre d’édition et tous les administrateurs n’ont pas accès à la console Rails (pensons par exemple aux sites hébergés).

Peut-être quelque chose comme ceci : lorsqu’un administrateur tente d’enregistrer le nouvel e-mail, une boîte de dialogue modale devrait apparaître, l’obligeant à saisir à nouveau son propre mot de passe pour confirmer l’action (ou à relever un défi d’authentification à deux facteurs, si activé). Il va de soi que cette action doit être enregistrée en détail dans les journaux du personnel. Je pense qu’une vérification obligatoire de l’utilisateur est toujours nécessaire d’une manière ou d’une autre pour donner à un utilisateur légitime la possibilité de signaler une prise de contrôle de compte, et une notification devrait également être envoyée à la nouvelle adresse e-mail pour confirmer le changement ? :thinking:

1 « J'aime »
7

Oui, cette fonctionnalité a clairement besoin d’être améliorée et mise à jour. Pour l’instant, si vous l’activez, un administrateur peut modifier l’adresse e-mail de n’importe quel compte utilisateur, sans aucune protection supplémentaire. J’aime bien votre idée de l’authentification à deux facteurs ou du mot de passe.

1 « J'aime »
8

Merci de m’avoir fait réfléchir à la fonctionnalité « email modifiable ». C’est une discussion intéressante et quelque peu complexe à envisager ! :slight_smile:

1 « J'aime »
9

J’ai apporté une modification au premier message pour améliorer considérablement la formulation et ajouter ces suggestions supplémentaires concernant la sécurisation du changement :wink: Je pense que cela améliorera les choses de manière significative dans l’ensemble.

1 « J'aime »