계정에 사용된 이메일 주소를 기억하지 못할 때 비밀번호 재설정을 어떻게 요청해야 하나요?

사용자가 자신의 계정을 찾았다고 가정해 보겠습니다(즉, 해당 계정의 usernameid를 알고 있지만, 비밀번호를 모르고 CTAP2와 같은 1FA 인증 방식도 추가되지 않은 상태라면), 단순히 관련 프로필 URI 뒤에 .json을 붙여서는 해당 계정의 이메일 주소를 확인할 수 없습니다.

따라서 비밀번호 재설정 양식이 이메일 주소를 요구하며 사용자명을 받지 않는 점을 고려할 때, 사용자는 어떻게 비밀번호 재설정을 요청할 수 있을까요?

각종 이메일 계정을 검색해서 포럼 도메인을 찾아볼 수 있지 않을까요? 이메일 주소를 몇 개나 가지고 있나요? :laughing:

다른 방법이 모두 실패한다면…

  • 관리자께 확인을 위한 가능한 이메일 주소 목록을 보내기 (관리자가 올바른 주소로 이메일을 보내면 상당히 안전할 것입니다)
  • a**********t@*****.com과 같이 가린 버전으로 보내줄 의향이 있는지 관리자께 물어보기? 때로는 그것이 도움이 되기도 하지만(정보의 일부가 노출되므로 동의하지 않을 수도 있습니다)

스태프 사용자는 사용자가 등록할 때 사용한 이메일 주소를 볼 수 있습니다. 스태프는 사용자가 로그인할 수 있도록 사용자의 이메일 주소를 알려줄 수 있습니다.

JSON에서는 이메일을 볼 수 없습니다. 실제로는 스태프에게도 상당히 숨겨져 있으며(즉, ‘보기’ 버튼 뒤에 있음), 제 기억이 맞다면 스태프 로그에 기록됩니다.

그것이 가능한가요?

@awesomerobot와 @NateDhaliwal, 이러한 방식의 문제는 최근 community.openAI.com에서 이를 직접 경험했기 때문입니다. 요즘 많은 사람들이 그러하듯 저도 이메일 별칭(alias) 서비스를 이용하고 있었거든요. 하지만 단순히 이메일 주소를 서브어드레싱(sub-addressing)한 경우라면 더 나쁠 것입니다. 이는 일반적인 관행이지만, 기억하기가 사실상 불가능하기 때문입니다. [1] 안타깝게도, 많은 Discourse 인스턴스에서 그렇듯 관리자에게 연락할 수단이 제공되지 않는다는 또 다른 문제도 있습니다.

제 이메일 주소를 발견하지 못했다면, 저는 아무것도 할 수 없었을 것입니다.


  1. ↩︎

안녕하세요 @roke_julian_lockhart,

하지만 사용자 이름도 받을 수 있습니다.

첫 번째 입력 필드는 이메일 또는 사용자 이름을 입력하도록 요청합니다.
첫 번째 필드 아래의 링크는 이메일을 입력했든 사용자 이름을 입력했든 상관없이 작동합니다.

비밀번호를 잊으셨나요 링크도 사용자 이름이나 이메일 모두에서 작동합니다. 단, 관리자가 이메일 주소 사용 여부 숨기기 사이트 설정을 활성화한 경우를 제외합니다.

OpenAI 사이트에서는 비밀번호 재설정 양식에 이메일이 필요하지만, 해당 설정이 비활성화된 다른 사이트에서는 사용자 이름 입력이 가능합니다:

따라서 제가 요청하신 내용을 오해하고 있지 않다면, 이미 요청하신 기능을 지원하고 있는 것으로 보입니다.

@southpaw, 비밀번호 재설정 시 사용자명을 받을 수 있는 기능이 설정 사항이며, 현재 비활성화된 상태인가요? 이렇게 묻는 이유는 제가 실제로 확인한 내용은 다음과 같기 때문입니다:

image

만약 그렇다면, 예를 들어 다음과 같은 문구를 추가하여 이를 더 명확히 표시하는 것이 좋을 것 같습니다:

이 Discourse 인스턴스에서는 사용자명 기반 비밀번호 재설정이 비활성화되어 있습니다.

다만, 제 환경에서도 동일한 현상이 관찰됩니다:

image

제출하신 스크린샷의 양식이 제가 여기에서 관찰하는 양식과 왜 다른지 이해가 되지 않습니다.

다른 사람들이 당신의 이메일 주소를 알아내는 것을 방지하는 것이 이 사이트의 최우선 과제여야 한다는 점에 동의하실 것입니다. 이를 위해 관리자가 활성화할 수 있는 사이트 설정이 있습니다. 이 설정은 이메일 주소를 추측하여 등록된 계정인지 확인하는 시도를 하는 사람들에게 힌트를 제공하지 않음으로써 추가적인 보호 계층을 제공합니다. 이 사이트 설정의 부수적인 효과 중 하나는 비밀번호 찾기 양식이 사용자 이름 입력을 받지 않는다는 것입니다.

제가 제시한 예시는 해당 특정 설정이 비활성화된 사이트에서 가져온 것입니다.
당신이 제시한 두 예시는 해당 특정 설정이 활성화된 사이트에서 가져온 것입니다.

이것이 당신이 차이를 관찰하게 된 이유입니다.

호기심이 생겼습니다. 양식 필드가 사용자 이름을 받지 않는다는 사실 외에, 이 추가 정보가 당신의 계정 복구 여정을 어떻게 더 쉽게 만들어 주었을까요?

@southpaw, 대부분의 웹사이트가 비밀번호 요청이 성공했는지를 단순히 표시하지 않음으로써 이 문제를 우회하기 때문에, 그렇게 해야 한다는 사실에 놀랐습니다. 대신, 사용자는 이메일 주소나 사용자 이름을 입력하고, 메시지가 도착하는 것을 확인하면 유효한 자격 증명을 입력한 것입니다.


많은 Discourse 인스턴스가 서로 다른 버전의 Discourse를 사용하므로, 만약 제가 다른 사이트에서 비밀번호 재설정이 가능한 것을 관찰했다면, OpenAI의 인스턴스가 문자열에 "username"이 추가되지 않은 구버전을 실행하고 있다고 가정했을 가능성이 높습니다. 그 결과, 이 번거로운 과정을 겪지 않아도 되었을 것입니다.

아, 네. 합리적인 경우네요… 다만 이메일 별칭 서비스에서는 각 별칭이 어디에 사용되었는지에 대한 기록을 남겨두어야 하지 않을까요? 애플의 서비스는 그렇게 하는데, 다른 서비스들에 대해서는 직접 사용해 본 적이 없어서 확신할 수는 없어요.

비밀번호 재설정 시 항상 사용자 이름을 허용하도록 하는 기능 요청을 제출해 볼 가치가 있을 것 같아요. 다른 사용자들도 이 문제를 겪고 있다면, 우리가 고려해 볼 수 있는 사항이니까요.

맞습니다. 서비스를 사용하고 계속 사용하려면, 어떤 이메일 주소를 사용했는지 아는 것은 사용자 본인의 책임입니다. 잊어버렸다면 새 계정을 만들어야 합니다. 다른 대안들은 모두 훨씬 나쁩니다. 관리자에게 이메일을 보내는 방법도 있지만(관리자는 이메일 주소를 공개하지 않으므로, 연락하려면 새 계정을 만들어야 합니다), "음, 모르는 이메일 주소로 계정을 만들었어요. 그게 뭔지 모르니까 제가 그 주소를 소유하고 있다는 걸 증명할 수 없어요"라고 말하는 상황이 됩니다. 또는 "secret123이라는 사용자 이름으로 계정을 만들었는데, 어떤 이메일 주소를 썼는지 잊어버렸어요. 알려줄 수 있나요?"라고 물을 수도 있겠죠.

무작위 이메일 주소를 쓸 정도로 편집증적이라면, 그 정보를 대신 기억해 줄 비밀번호 관리자를 사용할 만큼 편집증적일 테니, 그렇지 않다면 답이 없습니다.

@pfaffman, 저는 잊어버린 것이 아닙니다. 오히려 OpenAI가 SSO 통합을 부주의하게 끊어 버렸고, 사용자의 OpenAI 계정에서 상속된 이메일 주소로 조용히 대체했으며, 기본적으로 비밀번호가 연결되지 않았습니다. @awesomerobot이 추측했듯이:

…실제로 그렇습니다. (Addy)는 그렇게 하지만, 이 경우에는 제 자격 증명 관리자(credential manager)에 여전히 제 OpenAI 계정에 연결되어 있던 별칭을 사용했을 뿐입니다.


@pfaffman, 오해가 아니라면, 이것이 단순히 무능함 때문이라는 당신의 가정, 그리고 특히 이메일 미들웨어를 사용했다는 이유로 제가 편집증적이라는 가정에 동의하지 않습니다.

후자의 속성에 대해 좀 더 자세히 설명하자면, 저는 이메일 분류를 위해 별칭 서비스를 사용합니다. 저는 성 요한 구급대(St John Ambulance)의 응급 대응자, 영국 해안경비대(HM Coastguard)의 구조 요원이며, 여러 국가 및 지역 자선 단체(크라이스트로퍼스 트러스트(Crimestoppers Trust)와 네이퍼부드 워치 네트워크(Neighbourhood Watch Network) 포함)의 이사와 위원회 멤버입니다. 이 과정에서 저는 제가 사는 카운티의 [경찰 및 범죄 위원회(Office Of The Police And Crime Commissioner)]와 자주 연락을 취합니다. 또한, 이 모든 것이 제 FOSS(자유 및 오픈 소스 소프트웨어) 업무, 개인 통신(예: SAR), 보안 경보가 모두 들어가는 동일한 이메일 수신함으로 갑니다. 따라서 우선 순위를 위해 이를 분리할 수 있는 것은 저에게 매우 중요합니다.

별칭 서비스를 사용하기 전의 제 수신함은 사적 행위자와 국가적 행위자 모두로부터의 스피어 피싱(spear-phishing) 시도로 가득 차 있었습니다. 이 서비스를 사용하게 된 후, 누가 누구에게 어떤 이메일 주소를 공유했는지를 제어하고 분석할 수 있게 되어, 해당 스팸 양을 이전의 2% 수준으로 줄일 수 있었습니다.

편견은 냉소(sarcasm)보다도 더 낮은 형태의 유머일 수 있다는 점을 고려해 보십시오.

@awesomerobot, 감사합니다. 요청을 등록했습니다:

정말 엉망이네요.

다른 사람의 프라이버시와 안전과 관련된 중요한 업무를 맡고 계신 것 같으니, 우리 대부분보다 훨씬 더 경계할 이유가 많으실 겁니다. 그리고 사실 우리 모두 경계할 이유가 있다고 생각합니다. 한 늙은이의 의견으로는, 우리 대부분은 내가 생각하기에 마땅히 그래야 할 만큼 관심을 기울이지 않고 있는 것 같습니다.

제 말의 요지는, 이메일 주소를 잃어버리면 그 주소에 연결되어 있던 모든 것을 다시 연결하는 것이 어렵거나 불가능할 수 있다고 예상해야 한다는 것입니다. 그렇지 않으면, 귀하가 계정을 관리하고 있든 아니든, 누군가가 귀하의 계정을 장악할 수 있게 됩니다.

즉, 잃어버린 계정에 접속할 수 없는 것보다 더 나쁜 상황은, 특히 사람들의 프라이버시를 보호하는 중요한 업무가 관련되어 있다면, 다른 누군가가 그 계정에 접속할 수 있는 상황이 될 것입니다.

하지만 지구상의 아무도 그렇게 하지 못하도록 하면서 계정을 복구할 수 있는 안전한 방법이 있을 수도 있습니다. 이는 매우 어려운 문제입니다. 아마도 제가 이해하지 못하는 어떤 안전한 해결책을 제안하고 계신 건지 모르겠습니다.

부정하게 받아들여지길 의도한 것은 아닙니다.

이 문장은 관리자가 설정을 기본값에서 변경한 것처럼 읽힙니다. 그러나 해당 설정은 기본적으로 활성화되어 있습니다: Hiding "e-mail taken" on sign-up by default. 따라서 관리자가 명시적으로 비활성화하지 않는 한, 이 설정은 활성화된 상태입니다.

정말 훌륭한 지적입니다. 이는 당연히 비밀번호 복구 도구에서 사용자 이름 입력이 기본적으로 비활성화되어 있다는 의미이기도 합니다. 그래서 저는 이 기능 요청을 더 좋아하게 되었지만, 투표는 한 번만 할 수 있습니다.

@pfaffman, OnMicrosoft/Outlook과 GMail / Google Workspace에서 구현하는 IETF RFC 5233 서브어드레스를 사용하는 경우에도, 자신의 주소가 기록되어 있지 않다면 동일한 문제가 발생합니다.

다만, 제 경우 자격 증명 관리자(credential manager)에 주소를 저장해 두었고, 별칭 관리 도구(aliaser)를 통해 해당 주소를 검색할 수도 있습니다:

잠깐. 비밀번호 재설정 화면이 더 이상 사용자 이름만으로는 작동하지 않는다는 사실을 놓치고 있었네요. 사용자가 비밀번호 재설정으로 괴롭힘을 당하는 경우가 있고, 이를 막기 위해 속도 제한이 적용되어 있다고 생각했기 때문에, 이 변화가 실제로 어떤 문제를 해결하려는 것인지 궁금합니다.

또한, 오랜 기간 유지되는 커뮤니티에서 사용자가 자신의 이메일 주소를 더 이상 기억하지 못하는 경우도 드물지 않다는 것을 경험적으로 알고 있습니다.

그러니까… 가입할 때 사용했던 이메일 주소를 알아야 한다는 제 주장이 완전히 틀렸다는 뜻이죠. 제가 무례하게 굴었고, 겸손하게 사과드립니다.

이제 당신의 문제를 이해한 것 같은데, 당신이 속해 있는 커뮤니티의 소유자들이 의도적으로 만든 문제인 것 같습니다. 새로운 기본 설정의 탓이 일부일 수는 있지만, 그 사람들이 hide_email_address_taken 값을 변경할 수 있다고 생각합니다.

잠깐. 왜 hide_email_address_taken이 사용자 이름이 아니라 이메일 주소를 입력하도록 요구하는 거죠? 사용자 이름으로 비밀번호를 재설정하는 것은 이메일 주소를 노출하지 않습니다. 그게 진짜 문제입니다.

이 문제에는 제가 이해하지 못했던 여러 층위가 있었습니다. 도움이 되지 못한 점 죄송합니다.

저도 방금 제 의견을 추가했습니다. 이 부분은 개선할 수 있을 것 같습니다 :ok_hand:

@pfaffman, 실제로 그 덕분에 자세히 설명할 수 있어서 꽤 기쁩니다. 당신의 혼란은 제 혼란과도 동등합니다. 우리의 사고 과정이 정확히 일치했거든요!

일부 사용자에게 비밀번호 재설정 요청이 쏟아질 수 있다는 점은 이해하지만, IETF RFC 5228을 적용한 상태에서 요청을 별도 폴더로 필터링하는 것은 불가능하지 않을 것입니다. 이는 속도 제한이 부족할 정도로 그렇게 요청이 과다하게 밀려드는 경우라면 말이죠.

안녕하세요,

조금 무례한 질문일 수도 있지만, 이 문제에 대해 혹시

이메일을 잊어버린 경우, 사용자명을 입력하면 해당 사용자명의 이메일을 보여줄 수 있을까요? 누군가 이메일 주소를 확인하려는 위험이 있을 수 있으니, 이메일을 해시 처리하는 것도 방법일 것 같습니다. 예를 들어, 해당 페이지에 가면 이메일/사용자명을 입력하라고 하고, 제가 'ice.d’를 입력하면 관련 이메일이 jh*nd**@gmail.com[1]처럼 표시되는 방식이죠. 또는 '이 IP의 계정으로 커뮤니티에 등록된 이메일 보기’라는 버튼을 두는 것도 좋습니다. 그러면 디바이스 IP를 사용해, 그 디바이스가 비밀번호를 재설정하려는 포럼에 계정이 있으면 j*on***@gmail.com과 같은 이메일을 표시하는 방식입니다.

이 방법이 도움이 될까요?


  1. 실제 이메일이 아닙니다 ↩︎