Dealing with a hacked user account should not require the console

Support Self-hosting
1

Hi all,

one of our users had their account compromised. The workflow to mitigate that was far from ideal.

The rails console was needed for:

  • Force changing the e-mail address
  • Force changing the password to something random to force a password reset via e-mail
  • Killing all active sessions

Furthermore, we found that the e-mail change was only visible in the outbound e-mail logs and nowhere else.

The AI spam-detector caught that spam for new accounts, but wasn’t enabled for this trust level and number of posts. Maybe it would be a good idea to include the option to enable the AI spam-detector for changing countries and/or no post in over a year.

Thanks all for the great software over the years, despite minor flaws like this.

1 Like
2

All of those actions can also be performed from Admin > Users page. I am not sure what gave you the impression that it was only possible from console?

2 Likes
3

Changing the e-mail there sends a prompt for confirmation to the new one, but does not remove the old one immediately.

The deactivate account button may have been right, but it’s not clearly labeled whether that enforces a password reset via e-mail.

I still wasn’t able to find a kill all sessions button and for password change via impersonate in theory works, but it is really messy especially when users have their account set to a language that the admin/moderator doesn’t speak.

2 Likes
4

If you have plausible reasons that a user’s email is compromised which in turn has resulted in their discourse account being compromised, You can as an administrator change their email and remove the old email.

You can simply mark an account as deactivated which will force a re-verification of email and essentially nuke all existing sessions.

3 Likes
5

No, I tried that and I could not do that because it generated a confirmation e-mail for the new e-mail address and until that would have been clicked, the old one was still in the database and likely valid.

6

In such a case, suspension can be used instead.

1 Like
7

I opened this as a bug report/feature request on purpose to possibly make it better later, the concrete task is already been done and the user got his account back.

8

I’m not so sure this is a bug. This is not even an edge case imo. Users being careless about their data or identity is not a common occurrence and there are enough safeguards present. Making this process easier would potentially have more side effects. This is not something people should have to deal with on a daily basis and if situation is critical enough, administrators know their way around mitigation. Maybe the copy could be improved a bit but definitely not in favour of adding more options to the ui.

2 Likes