Allow admins to always be able to edit Emails when "Edit email after signup" is disabled

Contribute Feature
1

Edited for significant clarifications, better thought out suggestion criteria to better assist with fellow community members to understand the benefit of this feature improvement.

Update the Email Editable setting to allow additional options as to the who can edit email addresses, as the setting is designed e.g.

  • All Users
  • Users Only [Normal Admins, or Moderators cannot without using the rails console or changing the setting.]
  • Staff Only
  • Admins Only

If the setting is on [which it is by default], introduce a Sudo-Mode guardrail to perform the action as admin [Not the user the account being edit belongs to]; This allows for this setting to be introduced with some key points mentioned below to be secured against unwanted changes.

Reasoning/Why this needs done

If you want to set the setting off because you either want to have control over this e.g. they need to request the change, you do it for security practice, or some other reason, but for some reason need to edit the email; With this setting off even admins cannot edit the emails.

That is where it introduces a new issue. If one or more use case applies.

To Edit Emails for users currently; You can either 1) Turn it on in another tab, and quickly edit the email, or 2) Open Rails console and manually change the email.

For most regular day-to-day operations administrators, this can lead to an unwanted technical challenge. if you just rely solely on doing everything in the Rails Console, when the setting does exist.

Why extra guardrails could help make this feature a reality;

  • If left on because of a technical implication Compromised users could have their emails changed.
  • Admins could make errors, or unauthorized changes.
  • Users will feel that those with said access are secured from changes done maliciously.

This was talked about last in 2015, and while it is true, you can edit emails, you cannot edit them on the admin view, it tells you to go to the user preferences view, which I do, and well, even as an admin I cannot due to the constraints of this setting.

image
image1025Ă—291 11.5 KB

1 Like
2

yea i disagree very strongly here. while your specific use-case may seem straightforward enough to you, implementing a simple override in the UI for this would introduce a significant security risk for a very minor convenience gain.

the friction is a security feature!

so the inconvenience of having to use the rails console or toggle a site-wide setting is in fact, a critical security feature, since it acts as a “security brake” and forces an administrator to do a deliberate, high-friction process for a very sensitive operation.

changing a user’s email address is equivalent to handing over the keys to their account, since the new email address can be used to trigger a password reset, effectively locking the original user out and giving the new email owner complete control.

some primary attack vectors this friction prevents:

  • compromising admin accounts! - this is the most significant risk. if an attacker gains access to an admin’s account (through phishing, password reuse, etc), a simple UI button or toggle whatever, would allow them to silently and easily take over any other user’s account including other staff; the requirement for shell access via rails console provides a strong layer of security

  • social engineering! - this opens the door to social engineering. an nefarious intended user could impersonate a legitimate user and persuade an admin to change the email address for them; again the current high-friction process makes an admin much more likely to verify or consider the authenticity of the request

  • insider threat - a malicious admin could abuse this feature to take over accounts

for these kind of infrequent, high-risk administrative actions, the rails console is appropriate beause it ensures that teh person performing the action has server access and not a compromised session. plus the action is deliberate and requires specific technical knowledge (and it is logged in shell history).

1 Like
3

Appreciate the concern, but I think you might be misunderstanding the entire picture here. Including a serious hole in your argument about “security”

You can already edit the emails if this setting is toggled on; Which it is by default

Compromising admin accounts! - this is the most significant risk. if an attacker gains access to an admin’s account (through phishing, password reuse, etc), a simple UI button or toggle whatever, would allow them to silently and easily take over any other user’s account including other staff; the requirement for shell access via rails console provides a strong layer of security

If an admin is compromised, the intruder could just enable the setting that already exists today, and do the things you mentioned.

changing a user’s email address is equivalent to handing over the keys to their account, since the new email address can be used to trigger a password reset, effectively locking the original user out and giving the new email owner complete control.

for these kind of infrequent, high-risk administrative actions, the rails console is appropriate beause it ensures that teh person performing the action has server access and not a compromised session. plus the action is deliberate and requires specific technical knowledge (and it is logged in shell history).

Not always, and like I said in the opening post. You can just toggle the setting on and off to enable the edit function, the only issue is, toggling the setting, which is meant to be off [on by default], introduces the ability for users that are not admins to edit their email, while a simple edit is being made.

1 Like
4

ok i see your point now about when that setting is toggled.

i still strongly think the rails console is the way to go here. a plugin may perhaps be possible.

5

When the setting is ON

“Allow users to change their e-mail address after registration”

This enables editing for ALL users (and admins) The simple feature request is; Allow the setting to be for - for example: “Admins Only, Admins + Users, or Users”

IF I just “Turn it on” it enables site-wide ability for anyone [Or admins] to change a user’s email. While enabled.

Putting a setting, which already partially exists, to apply to admins only allows for simple functionality which already exists to not just be an All or None scenario

1 Like
6

ok thinking about this more, i guess a sudo-type high friction UI method may be the way to go, since that setting is “insecure” for the edit window and not all admins have access to the rails console (thinking hosted sites for example).

perhaps something like when an admin tries to save the new email, a modal dialog should appear forcing them to re-enter their own password to confirm the action (or a 2FA Challenge if enabled). it goes without saying this action must be recorded in the staff logs in detail. i think a mandatory user verification is still required somehow to give a legitimate user a chance to report an account takeover, and a notification should also be sent to the new email address confirming the change? :thinking:

i’m am just very against the idea of admin just being able to change email addresses at the request of users. there has to be some layer of friction or complexity with verification.

1 Like
7

Yeah the feature is def in need of some love, and updates. Right now if you do turn it on, you can as an admin edit any user account’s email, with no additional guards. I like your 2FA or Password idea.

1 Like
8

thank your for making me think about the email editable feature though. this is an interesting and somewhat complex discussion to consider! :slight_smile:

i’m not sure a plugin would be really be possible here. i think it would require a core change to how security is handled in Discourse. but i also think a “sudo admin” mode could be beneficial in some other high-level admin functions. :thinking:

1 Like
9

I have made an edit to the original post to significantly improve the wording, and add in those extra suggestions about guarding the change :wink: I think it would improve things significantly overall.

1 Like