해킹된 사용자 계정을 처리하려면 콘솔이 필요하지 않아야 합니다

안녕하세요,

우리 사이트 사용자 중 한 명의 계정이 탈취당했습니다. 이를 완화하기 위한 워크플로우는 이상적이지가 않았습니다.

다음 작업들을 위해 Rails 콘솔이 필요했습니다:

  • 이메일 주소를 강제 변경
  • 비밀번호를 무작위로 강제 변경하여 이메일을 통한 비밀번호 재설정을 유도
  • 모든 활성 세션 종료

또한, 이메일 변경 사항은 발신 이메일 로그에서만 확인되고 다른 어디에서도 확인되지 않는다는 것을 발견했습니다.

AI 스팸 탐지기는 신규 계정의 스팸을 차단했지만, 해당 신뢰 수준과 게시글 수에서는 활성화되어 있지 않았습니다. 국가 변경 또는 1년 이상 게시글이 없는 경우를 대상으로 AI 스팸 탐지기를 활성화할 수 있는 옵션을 포함하는 것이 좋은 아이디어일 것 같습니다.

이러한 작은 결함에도 불구하고 지난 수년간 훌륭한 소프트웨어를 제공해 주셔서 감사합니다.

이 모든 작업은 관리자 > 사용자 페이지에서도 수행할 수 있습니다. 콘솔에서만 가능하다는 인상을 받으신 이유가 무엇인지 정확히 알 수 없네요.

여기서 이메일을 변경하면 새 이메일로 확인 요청이 전송되지만, 기존 이메일은 즉시 삭제되지 않습니다.

계정 비활성화 버튼이 정답이었을 수도 있지만, 이메일을 통한 비밀번호 재설정을 강제하는지 명확하게 표시되지 않습니다.

여전히 모든 세션 종료 버튼을 찾을 수 없었고, impersonate를 통한 비밀번호 변경은 이론상으로는 작동하지만, 특히 사용자가 관리자/모더레이터가 이해하지 못하는 언어로 계정을 설정한 경우 매우 복잡합니다.

사용자의 이메일이 해킹되어 이로 인해 Discourse 계정까지 해킹된 것으로 판단되는 타당한 이유가 있다면, 관리자로 해당 사용자의 이메일을 변경하고 기존 이메일을 삭제할 수 있습니다.

계정을 비활성화 상태로 표시하면 이메일 재인증이 강제되고, 기존에 존재하던 모든 세션이 사실상 제거됩니다.

아니요, 그렇게 시도해 보았지만, 새로운 이메일 주소에 확인 이메일이 생성되어 해당 링크를 클릭할 때까지 기존 이메일이 데이터베이스에 남아 있고 여전히 유효할 가능성이 높았기 때문에 실행할 수 없었습니다.

이러한 경우, 중단(suspension)을 대신 사용할 수 있습니다.

나중에 더 개선할 수 있도록 의도적으로 버그 보고서/기능 요청으로 등록했습니다. 구체적인 작업은 이미 완료되었으며, 해당 사용자는 계정을 되찾았습니다.

이것이 버그라고 확신하기는 어렵습니다. 제 생각에는 이건 에지 케이스조차 아닙니다. 사용자가 자신의 데이터나 신원 관리에 소홀한 경우는 흔하지 않으며, 이미 충분한 안전 장치가 마련되어 있습니다. 이 과정을 더 쉽게 만들면 오히려 더 많은 부작용이 생길 수 있습니다. 이는 사용자가 매일 마주해야 할 상황이 아니며, 상황이 충분히 심각하다면 관리자는 완화 조치를 어떻게 해야 하는지 알고 있을 것입니다. 복사본(메시지)을 조금 개선하는 것은 괜찮을 수 있지만, UI에 더 많은 옵션을 추가하는 방향으로 개선해서는 안 됩니다.

또한, 정지를 먼저 해제하지 않고 정지 시간을 늘리는 버튼은 없습니다.

모든 세션을 인증 해제하고 비밀번호와 이메일 주소를 변경하도록 강제하는 버튼을 제공하는 것에 대해 뭐가 문제인가요? 다른 소프트웨어에서 그런 기능을 본 적이 있습니다.

직원들이 이번에는 악의로 이를 악용하고 있습니다.

최근 관리자용 사용자 이메일 주소에 대한 더 많은 제어 기능을 요청하는 기능 요청을 제출했는데, 이 요청은 해당 사용 사례도 함께 해결할 수 있습니다:

네, 흔한 일은 아닙니다(다행히도). 하지만 이것이(또는 유사한 상황이) 발생하면 매우 심각하며 빠른 대응이 필요합니다. 그때가야 Bash나 Rails 콘솔을 어떻게 사용하는지 배우거나, 지원 티켓을 발행해야 할 시점이 아닙니다!

하지만 그 사이 계정을 비활성화하는 데는 rails 콘솔을 사용할 필요가 없습니다. 여러 Discourse 커뮤니티를 관리해 온 거의 10년 동안 rails 콘솔이 필요한 상황을 한 번도 겪어본 적이 없습니다(커뮤니티 마이그레이션이나 일괄 작업을 제외하고는요). 추가 피해를 막기 위해 데이터베이스에 직접 변경 사항을 적용하는 것이 더 안전한 선택일 수 있는 경우가 있을 수 있다는 점은 이해합니다. 하지만 사용자 프로필이나 관리자 페이지에 더 많은 옵션을 추가하는 것이 적절한지 확신할 수 없습니다. 두 곳 모두 이미 매우 복잡한 상태이므로요.

맞습니다 - 그리고 이는 상당히 효과적으로 그들을 제지할 수 있습니다.

또한, 관리자가 강제로 계정을 병합한 후 문제 있는(이제 비주인공인) 이메일 주소를 삭제하는 것도 효과적일 것이라고 꽤 확신합니다 - 그리고 다른 상황에서도 이메일 변경을 강제하는 데 사용할 수 있습니다. 하지만 이는 매우 임시방편적인 해결책입니다.