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.
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 לייקים
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 לייקים
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 לייקים
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.