# "비밀번호 재설정" 대화상자의 이메일 열거 취약점
**URL:** https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449
**Category:** UX
**Created:** [8월 1, 2023, 7:37오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449 "2023-08-01T07:37:41Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@dobon](https://meta.discourse.org/u/dobon)
#### Post date: [8월 1, 2023, 7:37오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/1 "2023-08-01T07:37:42Z")
_**OWASP 취약점 ID: [WSTG-IDNT-04](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account)**_
**재현 단계** :
1. “이메일 찾기” 대화상자에서 잘못된 이메일을 사용해 보세요:
2. “이메일 찾기” 대화상자에서 올바른 이메일을 사용해 보세요:
**취약점 설명** (OWASP 기준):
- 애플리케이션의 인증 메커니즘과 상호작용하여 유효한 사용자 이름 목록을 수집할 수 있습니다. 이 테스트는 유효한 사용자 이름이 주어졌을 때 해당 비밀번호를 찾을 수 있는지 확인하는 브루트 포스 테스트에 유용합니다.
- 웹 애플리케이션은 잘못된 구성이나 설계 결정의 결과로 시스템에 특정 사용자 이름이 존재하는지를 노출하는 경우가 많습니다. 예를 들어, 잘못된 자격 증명을 제출하면 사용자 이름이 시스템에 존재하는지 또는 제공된 비밀번호가 잘못된지를 나타내는 메시지를 받는 경우가 있습니다. 이렇게 얻은 정보는 공격자가 시스템의 사용자 목록을 확보하는 데 사용될 수 있습니다. 이 정보는 웹 애플리케이션에 대한 공격, 예를 들어 브루트 포스 공격이나 기본 사용자 이름 및 비밀번호 공격에 사용될 수 있습니다.
**권장 수정 사항** :
1. 이메일이 올바르든 잘못되었든 “이메일 찾기” 대화상자의 동작은 동일해야 합니다.
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [8월 1, 2023, 7:52오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/2 "2023-08-01T07:52:13Z")
실제로 `hide email address taken` 관리자 설정이 있으며, 이 설정은 해당 화면의 동작을 변경합니다:
이것이 기본값으로 설정되는 것이 좋을 것 같습니다:thinking:
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [8월 1, 2023, 7:52오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/3 "2023-08-01T07:52:53Z")
관리자 - 설정 - 로그인 - `이메일 주소 사용 중 알림 비활성화`
> ### 이메일 주소 사용 중 알림 비활성화
>
> 가입 또는 비밀번호 찾기 과정에서 특정 이메일 주소로 계정이 존재함을 사용자에게 알리지 않습니다. ‘비밀번호를 잊으셨나요’ 요청 시 전체 이메일 주소를 요구합니다.
관련 링크: [Different password reset for wrong username/email](https://meta.discourse.org/t/different-password-reset-for-wrong-username-email/15909/) (2014년 ;))
편집 @JammyDodger는 40초 더 빨랐습니다
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [8월 1, 2023, 8:10오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/4 "2023-08-01T08:10:59Z")
여러 자료를 살펴본 결과, 이 문제는 이전에 몇 번이나 발생했던 적이 있습니다. 제가 생각하기에 또 다른 중요한 점은 로그인 시도를 제한하는 레이트 리미팅이 있다는 것입니다:
> [@비밀번호 재설정 시 이메일 정보 유출 금지](https://meta.discourse.org/t/do-not-leak-emails-on-password-reset/176149/2?u=jammydodger):
>
> This is not a bug. We have a site setting called hide email address taken that prevents it. There are also rate-limits on sign in so it’s not particularly easy to brute force large numbers of email addresses.
---
### Author:  [@dobon](https://meta.discourse.org/u/dobon)
#### Post date: [8월 1, 2023, 8:11오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/5 "2023-08-01T08:11:30Z")
두 분 모두 감사합니다. 저는 meta.discourse.org에서 이 버그를 우연히 발견했고, 해당 설정에 대해 알지 못했지만, 수정 코드가 이미 작성되어 있고 패치가 매우 간단할 것이라는 점은 다행입니다. OWASP 모범 사례를 준수하려면 이 설정은 항상 활성화되어야 합니다. 이를 비활성화하려는 관리자가 왜 있겠는지 이해할 수 없으며, 그렇게 하면 업계 모범 사례 기준을 명시적으로 위반하는 완전히 불필요한 보안 및 개인정보 보호 취약점이 발생하기 때문입니다. 제가 이해할 수 없는 이유로 레거시 설치 환경에서 이 옵션을 유지해야 한다면, 현재 구성이 업계 표준 모범 사례를 위반하고 있음을 나타내는 경고 메시지를 추가하고, 대신 준수하는 구성을 권장해야 합니다.
---
### Author:  [@dobon](https://meta.discourse.org/u/dobon)
#### Post date: [8월 1, 2023, 8:28오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/8 "2023-08-01T08:28:45Z")
이 스레드를 공유해 주셔서 감사합니다. @awesomerobot 님은 자신의 의견을 가질 권리가 있지만, 업계 표준 모범 사례를 대담하게 무시하고 있으며, 잘 알려져 있고 자주 보고되며 명시적으로 문서화된 버그가 어떻게 "버그가 아니다"라고 주장하고 있습니다. 공개된 업계 표준 모범 사례와 비교할 때, 저는 그 의견이 매우 설득력이 없다고 생각합니다.
최소한 기본값은 더 안전한 구성을 반영해야 하며, 이 옵션을 비활성화하면 포럼에 의도적이고 불필요한 보안 및 개인정보 보호 취약점이 발생한다는 점을 초보 관리자에게 알려줄 수 있는 어떤 표시가 있어야 합니다. OWASP 항목에 대한 링크나 같은 것 말이죠.
누군가 이 옵션을 비활성화하는 것이 더 바람직한 시나리오가 무엇인지 알려줄 수 있을까요? 이 문제가 왜 논쟁의 대상인지 진심으로 알지 못하며, 이 설정으로 구현된 옵트인(opt-in) 보안 모델을 무효화하는 사용 사례를 제가 놓치고 있는지 알고 싶습니다. 만약 그러한 시나리오를 제시할 수 없다면, 이 설정은 항상 활성화되어 있어야 하므로 아예 설정 항목이 아니어야 합니다.
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [8월 1, 2023, 8:45오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/9 "2023-08-01T08:45:43Z")
현재 모든 것이 예상대로 작동하고 있다고 생각하므로, 이를 #contribute:bug로 명확히 분류하기는 어렵습니다. 다만, 우리는 기본 설정을 정기적으로 재평가하고 있으며, 사용자가 제기한 몇 가지 흥미로운 점은 고려할 가치가 있습니다.
대화가 계속될 수 있도록 이 문제를 #contribute:ux로 넘기겠습니다. 👍
---
### Author:  [@awesomerobot](https://meta.discourse.org/u/awesomerobot)
#### Post date: [8월 1, 2023, 1:45오후 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/10 "2023-08-01T13:45:08Z")
> [@dobon](#):
>
> 이 옵션을 비활성화하는 것이 더 바람직한 시나리오가 언제인지 설명해 주실 수 있나요?
단순히… 사람들은 계정을 만들 때 어떤 이메일 주소를 사용했는지 기억하는 데 서투르기 때문에 문제를 해결하려고 관리자에게 연락하는 경우가 많습니다.
이것은 `2단계 인증 강제`나 `최소 비밀번호 길이`와 유사합니다. 일반적인 권장 사항으로는 항상 2단계 인증을 요구하는 것이 있으며, 현재 일반 사용자를 위한 기본값보다 최소 비밀번호 길이 권장 사항이 더 높아진 것으로 보입니다… 하지만 보안 권장 사항과 평균적인 컴퓨터 사용 능력 사이에는 간극이 존재합니다.
기본값 변경에 대해 강하게 반대하지는 않지만, 이것이 사용성(useability)에 영향을 미칠 수 있다는 점을 주목할 가치가 있습니다.
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [8월 3, 2023, 12:42오후 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/11 "2023-08-03T12:42:33Z")
Discourse 기본 설정이 다른 대부분의 사이트처럼 모범 사례를 따르는 것이 맞다고 생각합니다.
제 인스턴스에 적절한 설정이 되어 있는 것으로 보입니다:
> **[x@example.com](mailto:x@example.com)** 계정에 해당하는 경우, 곧 비밀번호 재설정 방법을 안내하는 이메일을 받게 됩니다.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [8월 4, 2023, 12:59오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/12 "2023-08-04T00:59:19Z")
> [@Ed\_S](#):
>
> 이것은 Discourse 기본 설정이 모범 사례를 따르는 것이 좋다고 생각합니다. 거의 모든 다른 사이트가 그렇게 하듯이 말이죠.
이 피드백은 좋지만, [더 많은 데이터로 뒷받침](https://www.similarweb.com/top-websites/)되었으면 합니다:
다음 사이트들은 어떻게 하고 있나요?
- Facebook
- Twitter
- Amazon
- Reddit
- Yahoo
---
### Author:  [@dobon](https://meta.discourse.org/u/dobon)
#### Post date: [8월 4, 2023, 4:27오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/13 "2023-08-04T04:27:36Z")
이 버그에 대해 소중한 의견과 관점을 나눠 주셔서 감사합니다. 제게 있어서는 이는 매우 명확하고 복잡하지 않습니다. 저와 같은 관리자 및 보안 전문가들이 반복적으로 지적해 온, Discourse에 존재하는 잘 알려진 버그가 보안 취약점이 아니라 기능으로 취급되고 있기 때문입니다: [NIST: CWE-200: 권한 없는 행위자에게 민감한 정보 노출](https://cwe.mitre.org/data/definitions/200.html).
산업 표준 모범 사례를 위반하는 이러한 위험한 기본 구성을 정당화하기 위해, 포럼 관리자가 가입에 사용된 이메일이 무엇인지 묻는 사용자 문의로 압도당하는 가상의 상황을 언급하는 것은 논리적이지 않습니다. 이 설정의 구성과 관계없이 ‘비밀번호 찾기’ 페이지를 사용하면 이러한 관리자 상호작용이 필요하지 않기 때문입니다. 더 안전하고 표준에 부합하는 설정이 활성화되면, 사용자는 ‘이메일 찾기’ 대화 상자에서 자신의 이메일을 확인하여 해당 주소가 비밀번호 재설정 이메일을 받았는지 확인하면 됩니다. 이는 대화 상자에 설명된 대로, 그리고 모든 현대적이고 프라이버시를 존중하며 표준에 부합하는 웹 애플리케이션에서 흔히 볼 수 있는 방식입니다. 또한, 이 위반을 다른 사이트들이 _최선책을 위반하고 있을 수도 있다_는 전제에 기반하여 정당화하는 것은 보안 및 데이터 보호 관점에서 논리적이거나 설득력 있는 주장이 아닙니다. 명확한 이득 없이 관리자에게 Discourse 설치를 약간 덜 안전하고 표준에 덜 부합하게 만드는 '기능’을 제공하는 이유가 무엇인지 이해하기 어렵습니다.
그럼에도 불구하고, @sam님이 지시하신 작업을 수행했습니다:
1. **Google** : 사용자 열거(user enumeration)를 _허용하지 않습니다_.
2. **YouTube** : 사용자 열거를 _허용하지 않습니다_ (Google 로그인을 사용하며, Google은 사용자 열거를 허용하지 않기 때문).
3. **Facebook** : 사용자가 이메일/전화번호를 공개적으로 표시하도록 의도적으로 설정한 경우에만 ‘계정 찾기’/‘비밀번호 찾기’ 페이지를 통해 사용자 열거를 공식적으로 허용하며, [이러한 유형의 취약점을 통해 5억 건의 사용자 데이터를 유출한 악명 높은 사례](https://www.wired.com/story/facebook-data-leak-contact-import-flaws/)가 있고, [레이트 리미팅 및 ‘명시적으로 공개로 표시된 경우에만’ 규칙이 내부적으로 준수되지 않았음을 발견한 보안 감사관들에게 수천 달러를 지급한 사례](https://www.websecgeeks.com/2014/02/facebook-user-enumeration-vulnerability.html)도 있습니다.
4. **Instagram** : 사용자 열거를 허용합니다 ([그리고 이로 인해 큰 피해를 입었습니다](https://www.arneswinnen.net/2016/05/instabrute-two-ways-to-brute-force-instagram-account-credentials/)). 이는 제가 Facebook에 대해 언급한 해킹과는 다른 방식입니다.
5. **X _(이 포럼에서는 고인명을 존중해 주세요)_**: 비밀번호 찾기 페이지를 통해 사용자 열거를 허용하지만, 레이트 리미팅과 몇 가지 [쉽게 우회할 수 있는 장벽](https://int0x33.medium.com/day-9-osint-twitter-phone-enumeration-4b8ed782857d)을 구현하고 있으며, [여전히 레이트 리미팅 및 데이터 프라이버시 보호 구현상의 버그로 인해 사용자들의 전화번호가 유출된 악명 있는 사례](https://www.ghacks.net/2022/08/08/twitter-confirms-that-a-data-breach-leaked-email-addresses-and-phone-numbers-of-users/)가 있습니다.
6. **Baidu** : 이메일 찾기 페이지에서 사용자 열거를 허용하며, 캡차(그리고 아마도 레이트 리미팅? 제 중국어 실력이 부족합니다)를 구현합니다. 흥미롭게도, 복구 과정은 간단한 복구 이메일이 아니라 관리팀에 이의를 제기하는 것을 요구합니다. CCP의 중앙 통제 방식에 매우 전형적인 모습입니다.
7. **Wikipedia** : 사용자 열거를 _허용하지 않습니다_.
8. **Yahoo** : 비밀번호 찾기 페이지를 통해 사용자 열거를 허용하지만, 레이트 리미팅과 캡차를 구현합니다. Yahoo가 이 버그를 악용하는 해커들에게 지급하거나 논란에 휩싸인 사례를 찾지는 못했지만, 명백한 이유로 인해 어떤 검색 엔진에서든 Yahoo를 검색하는 것은 매우 어렵습니다.
9. **Yandex** : 로그인 페이지에서 사용자 열거를 허용하며, 이메일 찾기 페이지에서 캡차와 질문(챌린지)을 구현합니다.
10. **Whatsapp** : 사용자 열거를 _허용하지 않습니다_. PC 로그인은 모바일 자격 증명을 통해 이루어집니다. 모바일 자격 증명은 휴대폰 번호에 바인딩됩니다. 로그아웃 버튼도, 로그인 페이지/이메일 찾기 페이지도 없습니다.
11. **XVideos** : 사용자 열거를 _허용하지 않습니다_.
12. **PornHub** : 사용자 열거를 _허용하지 않습니다_.
13. **Amazon _(이커머스 사이트)_**: [비밀번호 찾기 페이지를 통해 사용자 열거를 허용](https://samsclass.info/129S/proj/amp.htm)하며, 이는 [Amazon Web Services’ Cognito 사용자 풀 제품에 대한 자체 모범 사례 권장 사항](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-managing-errors.html)을 직접적으로 위반하는 것입니다. Amazon이 이 버그를 악용하는 해커들에게 지급하거나 논란에 휩싸인 사례를 찾지는 못했지만, 명백한 이유로 인해 어떤 검색 엔진에서든 Amazon을 검색하는 것은 매우 어렵습니다.
14. **Xnxx** : 사용자 열거를 _허용하지 않습니다_. 메인 사이트에는 사실상 로그인 페이지가 없으며, ‘골드’ 사이트는 사용자 열거를 허용하지 않습니다. 일반 사이트의 모바일 버전에서 폐쇄된 로그인 페이지를 발견했는데, 여기에는 ‘이메일 찾기’ 기능이 전혀 없었습니다 (또한 ‘골드’ 웹사이트를 대체하기 위해 폐쇄된 것으로 보입니다).
15. **Tik Tok** : 사용자 열거를 _허용하지 않습니다_. 비밀번호 찾기 페이지에서 MFA(다중 인증)를 강제 적용합니다.
(21. **Reddit** : 사용자 열거를 _허용하지 않습니다_. 산업 표준 모범 사례를 준수하고 있습니다.)
해당 목록의 상위 15개 사이트 중 8/15는 사용자 열거를 허용하지 않습니다 (Reddit을 포함하면 9/16, 그리고 사용자가 의도적으로 공개 승인한 정보만 열거되므로 Facebook은 0.5를 더할 수 있습니다). 또한, 사용자 열거를 허용하는 해당 목록의 사이트 중 최소 3/7은 이러한 결정으로 인해 치명적인 보안 사건을 겪었습니다.
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [8월 4, 2023, 6:22오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/14 "2023-08-04T06:22:08Z")
> [@dobon](#):
>
> 1. **Google** : 사용자 열거(user enumeration)를 허용하지 _않습니다_.
> 2. **YouTube** : 사용자 열거를 허용하지 _않습니다_ (Google 로그인을 사용하며, Google은 사용자 열거를 허용하지 않기 때문).
이는 다소 기만적이라고 할 수 있습니다. 왜냐하면 arguably Google의 주요 제품인 Gmail은 사용자 열거를 허용하기 때문입니다.
이메일 _제공자_에서 계정의 존재 여부를 테스트하는 것은 비교적 간단하므로, 이 목록에 이메일 제공자를 포함시키는 것에도 큰 의미가 없습니다.
> [@dobon](#):
>
> 명확한 이점이 없음에도 관리자에게 Discourse 설치 환경의 보안을 약간 약화시키고 표준 준수도를 떨어뜨리는 '기능’을 제공하는 이유를 이해하기 어렵습니다.
해당 목록의 _다른_ 어떤 플랫폼도 (잠재적으로) 자체 호스팅(self-hosted) 소프트웨어가 아닙니다.
중앙화된 Discourse 플랫폼은 없으며, 사이트 관리자는 _자신의 판단에 따라 자유롭게 선택_할 수 있습니다.
그러나 기본적으로 좋은 설정을 선택하도록 사이트 관리자에게 권장하는 것에는 동의합니다.
이러한 설정을 쉽게 엄격하게 조정할 수 있도록 관리자가 조작할 수 있는 옵션(knob)을 제공하는 것도 좋을 것 같습니다 (이 기능을 마법사(wizard)에 추가하는 것은 망설여집니다).
---
### Author:  [@dobon](https://meta.discourse.org/u/dobon)
#### Post date: [8월 4, 2023, 7:21오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/15 "2023-08-04T07:21:59Z")
가입 페이지가 있는 모든 사이트에 해당되는 것 아닌가요? 이메일 서비스 제공업체에만 국한되는 것이 아닙니다. 가입 페이지가 유사한 프라이버시 및 데이터 취약성의 잠재적 벡터가 될 수 있으므로 보호해야 한다는 점은 이해합니다. 하지만 그것은 이 주제를 논의하면서 다루고 있는 사용자 인증 플로우의 다른 부분입니다. 이 주제에서는 구체적으로 “비밀번호를 잊으셨나요?” 대화 상자에서 발생하는 정보 유출을 다루고 있습니다. 오해하지 마세요: 둘 다 매우 중요하고, 신중한 주의를 기울여야 하며, 프라이버시 및 데이터 취약성을 방지하기 위해 완화 조치가 필요합니다. 일반적으로 가입 폼에는 캡차를 요구하며, ‘비밀번호를 잊으셨나요?’ 엔드포인트에서는 이메일이 유효한지 여부에 관계없이 동일한 응답을 반환하도록 구성해야 합니다. 많은 사이트가 ‘비밀번호를 잊으셨나요?’ 엔드포인트도 캡차로 보호합니다. 두 엔드포인트 모두 속도 제한(rate-limiting)을 적용해야 합니다.
저는 결코 기만적인 의도를 가진 것이 아닙니다. _다른 사이트도 비준수 상태이므로 비준수 상태가 괜찮다_는 것은 논리적으로 타당한 결론이라고 생각하지 않습니다. 저는 단순히 Sam의 요청을 이행하고, 그가 제공한 링크를 사용하여 그가 원했던 '증거’를 제시함으로써 그가 가질 수 있는 우려를 완화하려는 것이었습니다.
[MediaWiki](https://www.mediawiki.org/wiki/MediaWiki) 소프트웨어는 [수만 개의 웹사이트](https://www.mediawiki.org/wiki/Special:MyLanguage/Sites_using_MediaWiki)와 [수천 개의 기업 및 조직](https://www.mediawiki.org/wiki/Special:MyLanguage/MediaWiki_testimonials)에서 사용되고 있습니다. 위키피디아의 기반이 되며, 매우 자체 호스팅(self-hosted) 소프트웨어입니다.
저는 관리자 자유를 확실히 장려하며, 관리자나 사용자의 삶을 더 어렵게 만드는 것을 좋아하지 않습니다. 하지만 이 설정의 '장점’이 어떤 시나리오에서도 '단점’을 능가한다고 생각하지 않으며, 관리자가 실제로 이 '기능’을 원할 만한 경우도 없습니다. 우리가 관리자에게 _ **최대** _ 비밀번호 길이를 강제할 수 없듯이, ‘비밀번호를 잊으셨나요?’ 대화 상자에서 열거 취약성(enumeration vulnerability)을 허용하여 포럼의 보안을 불필요하게 소폭 저하시키는 것도 허용해서는 안 됩니다. 이 옵션을 완전히 제거하고 모든 사용자가 표준 준수 방식을 따르도록 강제하는 것이 좋다고 생각합니다. 솔직히 대부분의 관리자는 이를 알아차리거나 신경 쓰지 않을 것이라고 생각하지만, 이는 모든 Discourse 설치 환경에서 공개 인터넷에 노출된 엔드포인트를 다소 더 안전하게 만들 것입니다. _반드시_ 이 설정을 포함해야 한다면, 더 안전한 위치가 기본값이어야 하며, 덜 안전한 위치는 초보 관리자가 왜 권장되지 않는지 이해할 수 있도록 명확히 구분해야 합니다. 하지만 저는 이 설정을 단순히 리팩토링하여 없애는 것이 최선의 선택이라고 생각합니다. 이를 위한 PR을 제출하는 것은 기꺼이 하겠습니다.
---
### Author:  [@Jonathan5](https://meta.discourse.org/u/Jonathan5)
#### Post date: [8월 4, 2023, 7:53오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/16 "2023-08-04T07:53:41Z")
> [@dobon](#):
>
> 이것은 이메일 서비스 제공업체뿐 아니라 가입 페이지가 있는 모든 사이트에 적용되지 않나요? 가입 페이지가 유사한 프라이버시 및 데이터 취약성의 잠재적 벡터가 될 수 있으므로 보호되어야 한다는 점은 동의합니다. 하지만 그것은 이 스레드에서 우리가 논의하고 있는 사용자 인증 플로우의 다른 부분입니다.
나는 둘 중 어느 것도 고립된 상태로 볼 수 없다고 생각합니다. Discourse의 가입 과정에는 "이미 사용 중인 이메일입니다"라는 메시지가 있으며, 이를 다르게 처리하는 방법을 이해하기 어렵습니다. 이 메시지가 존재하는 한, "계좌를 찾았습니다"라는 특정 메시지에 큰 문제가 무엇인지 이해하기 어렵습니다.
포럼이 외부 인증만 허용하는 경우라면 상황이 달라질 수 있을 것입니다.
당신의 말투 때문에 단순히 반박하고 싶은 충동을 누른 후, 실질적인 내용에서 당신의 입장이 기본값은 더 안전한 옵션이어야 하며, 적어도 외부 인증이 사용될 때 그러하다는 점에서 당신이 옳다고 생각합니다. 여전히 더 안전한 옵션이 **아무** 곳에도 적합하지 않다는 데에는 동의하지 않습니다(제 포럼은 Discourse의 기본 가입 과정을 사용하므로 비밀번호 재설정 옵션을 변경할 계획이 없습니다).
그리고 참고로, 당신이 컨텍스트에서 추측하도록 남겨둔 XVideos와 Xnxx(하지만 X는 제외)가 포르노 사이트라는 사실에 웃었습니다. 그런데 아마존은 "전자상거래 사이트"라고 설명하는 데에는 공을 들였습니다.
---
### Author:  [@dobon](https://meta.discourse.org/u/dobon)
#### Post date: [8월 4, 2023, 7:55오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/17 "2023-08-04T07:55:02Z")
Amazon.com과 AWS를 구별하기 위함이었습니다. 그리고 질문하신 내용에 대해 말씀드리자면: AWS는 사용자 열거(user enumeration)를 허용하지 않습니다. 🙂
사용자 인증 플로우의 모든 단계와 이들이 어떻게 상호작용하는지를 고려해야 한다는 점에 동의합니다. 이는 매우 중요하며, 가장 흔한 보안 취약점의 원인 중 하나입니다. 언급하신 가입 페이지의 유사한 이메일 열거 버그가 적절히 완화되지 않았다면, 이 주제의 결론과 관계없이 반드시 패치되어야 합니다. 이는 `hide_email_address_taken` 구현의 버그가 될 것입니다. 다만 해당 잠재적 버그/누락에 대한 논의는 다른 주제에서(아마도 **bug** 태그와 함께) 이루어지는 것이 적절할 것입니다.
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [8월 4, 2023, 8:14오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/18 "2023-08-04T08:14:31Z")
> [@Jonathan5](#):
>
> Discourse의 가입 과정에서 "이메일이 이미 사용 중입니다"라는 메시지가 표시되며, 이를 다르게 처리하는 방법을 찾기 어렵습니다.
참고로, `hide email address taken`(이메일 중복 감추기) 옵션이 활성화되어 있으면 가입 시에도 해당 메시지가 표시되지 않습니다(기존 이메일을 입력할 때 초대 메시지도 함께 변경됩니다). 👍
기본 설정을 단순히 변경하는 것의 가능한 복잡성 중 하나는, 여기에 ‘비밀번호 재설정 시 전체 이메일 주소 요구’ 기능이 내장되어 있어 상황을 더 복잡하게 만들 수 있다는 점입니다(다만, 완전한 장애 요인은 아닐 가능성이 높습니다).
---
### Author:  [@Jonathan5](https://meta.discourse.org/u/Jonathan5)
#### Post date: [8월 4, 2023, 8:49오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/19 "2023-08-04T08:49:03Z")
감사합니다. 그러면 설정을 변경할 것 같습니다. 이 주제에서 무언가가 잘못된 인상을 심어준 것 같습니다.
> [@JammyDodger](#):
>
> 내장된 ‘비밀번호 재설정을 위해 전체 이메일 주소 요구’
이 기능은 무슨 뜻인가요? 사용자명만으로는 비밀번호 재설정을 할 수 없다는 뜻인가요?
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [8월 4, 2023, 9:04오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/20 "2023-08-04T09:04:06Z")
> [@Jonathan5](#):
>
> 이건 무슨 뜻인가요? 사용자명만으로는 비밀번호 재설정을 받을 수 없다는 뜻인가요?
맞습니다. 👍 `hide email address taken` 기능이 활성화되어 있으면 비밀번호 재설정을 위해 계정 이메일 주소를 직접 입력해야 하며, 사용자명만으로는 사용할 수 없습니다.
---
### Author:  [@dobon](https://meta.discourse.org/u/dobon)
#### Post date: [8월 4, 2023, 9:52오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/21 "2023-08-04T09:52:21Z")
`hide_email_address_taken` SiteSetting을 `prevent_password_recovery_by_username`으로 이름을 변경하고, 비준수하는 동작을 모든 사용자를 위해 앱에서 리팩토링해 제거하는 것을 제안합니다. 이렇게 하면 모든 설치 환경에서 비밀번호 재설정 기능이 변경 없이 유지되는 동시에 이메일 열거 취약점도 해결할 수 있습니다. 저는 숙련된 RoR + JavaScript 개발자로서 이 풀 리퀘스트를 구현하는 데 기꺼이 참여할 준비가 되어 있습니다. 코드베이스를 빠르게 살펴본 결과, 이 PR이 매우 방대하지는 않을 것으로 보입니다.
만약 이 '기능’을 리팩토링하여 완전히 제거하는 것이 실제로 불가능하다면, 여전히 이 두 가지 관련 개념을 별도의 SiteSetting 항목으로 분리하는 것이 합리적이라고 생각합니다.
---
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [12월 19, 2024, 11:19오전 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/22 "2024-12-19T11:19:05Z")
> [@회원가입 시 기본값으로 "이미 사용 중인 이메일" 숨기기](https://meta.discourse.org/t/hiding-e-mail-taken-on-sign-up-by-default/342599/1):
>
> Background Under the current default settings, when signing up for an account with an e-mail that has already been registered, the sign-up form will inform of that: We are changing the default setting to not give away this information. Instead, the sign-up form will look like this, regardless of whether the e-mail is already registered or not: This also affects password resets in similar ways. With the setting di…