bitcoincashresearch.org에서는 포럼의 특정 수준의 탈중앙화를 제공하고자 합니다. 여기에는 필요하다고 판단하는 누구나 포럼의 특정 인스턴스를 다른 도메인으로 재구축할 수 있는 가능성이 포함됩니다.
이를 가능하게 하려면 데이터베이스(DB) 백업을 정기적으로 공개해야 합니다. 하지만 이메일, IP 주소 등 사용자의 개인 정보를 노출하는 문제가 발생합니다.
이러한 개인 정보를 DB 백업에서 수동으로 제거할 수는 있지만, 정기적인 백업의 경우 가장 지혜롭거나 깔끔한 선택지는 아닌 것 같습니다.
이와 관련하여 작동할 수 있는 솔루션이나 유사한 사례가 있는지 알고 계신 분이 계신가요?
꽤나 기이한 엣지 케이스네요!
IP 주소와 이메일 주소를 제거하기를 원하시나요? 이메일 주소가 없으면 사용자가 계정을 되찾을 방법이 전혀 없게 됩니다 (비밀번호를 사용했다면 로그인倒是 할 수 있지만, 변경 사항을 검증할 방법이 없기 때문에 이메일 주소를 다시 입력할 수 없게 됩니다).
최소한 이메일 주소는 포함해야 하는 유용한 백업을 만드는 방법을 찾을 수 없습니다.
Discourse 포럼의 공개 SQL 덤프를 아래에서 확인할 수 있습니다: Index: if-archive/info/intficforum
여기서 몇 가지 아이디어를 얻을 수 있습니다.
이것이 다소 기이한 예외적인 경우처럼 보일 수 있다는 점에는 동의합니다. 하지만 이 아이디어는 포럼의 중앙 집중화를 방지하는 방향으로 작용하므로 그렇게까지 기이하지는 않다고 생각합니다.
일부 포럼에서는 이것이 매우 중요하지 않을 수 있지만, 다른 포럼에서는 중요한 문제가 될 수 있습니다.
또한 백업에서 사용자 이름과 비밀번호(그 외 정보 포함)를 제거하면, 해당 사용자가 새 인스턴스에 로그인할 수 없게 된다는 점에도 동의합니다.
그래서 그것이 가장 현명한 방식은 아니라고 말한 것입니다.
아마도 제 질문을 다시 표현해야 할 것 같습니다.
사용자의 개인 정보를 노출하지 않으면서도 누구나 해당 포럼 인스턴스를 재구성할 수 있도록 데이터베이스 백업을 공개하는 데 알려진 방법이나 권장 절차가 있습니까?
몇 가지 맥락을 추가하고 싶습니다. 매우 구체적인 필요 사항/사용 사례가 있습니다.
중요한 콘텐츠를 담고 있는 운영용 디스커스(운영 포럼)가 있으며, 시간이 지남에 따라 이 콘텐츠의 중요성은 더욱 커질 것입니다. 이를 사용하는 생태계의 특성상, 단일 장애점(SPOF)을 피하는 것이 매우 중요하다는 점을 우리는 학습했습니다.
현재의 내보내기(export) 기능의 경우, 인증 정보를 제외한다면 사이트 전체 콘텐츠를 공개적으로 게시할 수 있어야 합니다. 그러나 @pfaffman이 지적했듯이, 이렇게 하면 사용자가 더 이상 인증할 수 없는 되돌릴 수 없는 단절이 발생하며, 내보낸 사이트는 읽기 전용이 됩니다.
따라서 레안드로(Leandro)가 필요로 하는 것은 디스커스에서 사용자가 전통적인 계정/비밀번호 방식 대신 암호학적 챌린지를 통해 로그인할 수 있도록 하는 기능이라고 생각합니다. 그런 다음 내보내기 시에는 계정 중 해당 부분만 포함하고, 이메일이나 비밀번호 해시 등 다른 정보는 포함하지 않습니다. 이렇게 하면 사이트의 대체 복사본에서 이 기능을 활용한 사용자는 로그인하여 이메일/표준 계정 복구 절차를 거칠 수 있게 됩니다.
이러한 전체 공개를 수행할 때, 이메일이나 비밀번호 해시 등 전통적인 계정 인증 정보를 포함하지 않는 것이 매우 중요할 것입니다. 이 중요성 때문에, 이 기능이 포함된 디스커스의 어떤 버전에서도 민감한 정보는 사이트 데이터의 나머지 부분과 별도로 보관하여 실수로 내보내는 일이 불가능하도록 해야 합니다.
이 설명이 조금 더 맥락을 파악하는 데 도움이 되기를 바랍니다.
또한 이러한 변경 사항들은 분명히 자명한 것이 아닙니다. 피드백, 문제점 및 대안에 대한 의견을 들어보는 것이 좋겠습니다. 아마도 생태계 측면에서 자원을 모아 해당 아이디어를 구현한 포크를 만들 수 있을지도 모릅니다.
Webauthn support에 설명된 대로 webauthn을 비밀번호 없는 인증 방식으로 지원하도록 추가하면 가능합니다.
그리고 노출하지 않으려는 필드에서 백업 파일을 정리하는 서비스를 추가하면 됩니다.
로그인에 대한 또 다른 해결책입니다.
아, 그리고 일반 사용자는 로그인 상태라면 이메일 주소 변경에 대한 승인이 필요하지 않으므로, 이메일 주소를 제거한 덤프는 데이터베이스에 있는 어떤 자격 증명(가장 쉬운 것은 비밀번호)으로 로그인해야 하는 모든 사용자에게 괜찮을 것입니다.
이메일 주소를 제거하거나 암호화하는 플러그인(합리적인 수준에서 쉽게 수행할 수 있는 방법에 대해 알고 있다고 생각합니다)이 이 문제를 해결해 줄 것입니다.
제가 만든 플러그인에서 일부 필드를 다음과 같이 암호화했습니다:
UserEmail 모델을 유사하게 오버라이드하여 이메일 주소를 암호화하는 것이 가능할 수 있다고 생각합니다. UserEmail 모델에는 코드가 많지 않고 변경되는 빈도도 매우 낮을 것으로 예상되므로, 이 변경이 너무 위험하지는 않을 수 있습니다. 아니면 아예 작동하지 않을 수도 있습니다.
IP 주소를 필터링하는 것은 조금 더 까다로울 수 있습니다. 사용자 모델을 오버라이드하기가 어려울 것이라고 생각하기 때문입니다. 이를 위해 해당 IP를 어떤 방식으로든 제거하는 플러그인을 만들 수 있습니다.
@Falco님과 @pfaffman님, 피드백과 조언에 진심으로 감사드립니다.
Webauthn을 조사하여 해당 방향으로 진행할 수 있는지 확인해 보겠습니다. @pfaffman님의 플러그인도 마찬가지입니다.
몇일 안에 코멘트, 질문, 또는 결론을 가지고 다시 연락드리겠습니다.
지평선에 보이는 또 다른 가능성은 증강 PAKE (Password-Authenticated Key Exchange, 비밀번호 인증 키 교환)의 사용입니다. 이를 통해 비밀번호는 데이터베이스에서 사실상 복구할 수 없도록 만들 수 있을 뿐만 아니라 네트워크를 통해 전송되지도 않습니다.
불행히도 이러한 방법들은 모두 여전히 실험적 암호학의 영역에 머물러 있으며, 쉬운 배포를 위한 준비가 되어 있지 않습니다. iOS iCloud 동기화는 PAKE를 사용합니다.
이메일/비밀번호 로그인을 유지하되, 백업된 데이터베이스에서 누구나 모든 사용자의 계정으로 로그인할 수 있도록 하려면, 각 사용자에게 <username>@email.invalid 형식의 이메일을 생성하는 방법을 사용할 수 있습니다.
비밀번호와 로그인과 관련하여, Discourse가 소금이 포함된 암호화된 비밀번호를 사용한다고 가정할 때(직접 확인하지는 않았지만 그렇게 가정합니다), 라이브 데이터베이스에서 123456과 같은 비밀번호를 설정하고, 데이터베이스에서 생성된 암호화된 비밀번호와 소금을 확인한 후(비밀번호를 원래대로 되돌리거나 가짜 계정으로 진행하십시오), 새로운(복제된) 데이터베이스에서 모든 사용자의 암호화된 비밀번호와 소금을 이전에 확인한 값으로 설정하는 명령을 실행할 수 있습니다. 이렇게 하면 모든 사용자는 동일한 암호화된 비밀번호와 소금을 가지게 되며, 결과적으로 이전에 사용했던 동일한 비밀번호를 갖게 됩니다. 따라서 foo 사용자의 경우, 이메일 foo@email.invalid과 비밀번호 123456으로 로그인할 수 있습니다.
이 외에도, 사적인 메시지(필요하지 않은 경우)를 삭제하는 것이 좋습니다. 민감한 데이터가 포함되어 있을 수 있기 때문입니다.
마지막으로, (관리자) 설정과 같이 기밀 데이터가 포함되어 있을 수 있는 필드를 확인해 보는 것이 좋습니다.