hide email address taken という管理設定があり、その画面の動作を変更できます。
デフォルトにするのはどうでしょうか？
「いいね！」 9
RGJ
2023 年 8 月 1 日午前 7:52
3
管理者権限を有効にする - 設定 - ログイン - メールアドレスが使用されていることを隠す
メールアドレスが使用されていることを隠す
サインアップ中またはパスワードを忘れた場合のフロー中に、指定されたメールアドレスを持つアカウントが存在することをユーザーに通知しないでください。「パスワードを忘れた場合」のリクエストには、完全なメールアドレスが必要です。
関連項目 Different password reset for wrong username/email (2014
編集 @JammyDodger は 40 秒速かった
「いいね！」 7
調べてみたところ、この問題は以前にも何度か発生しているようです。ログイン試行時のレート制限も重要な点の1つだと思います。
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.
「いいね！」 3
dobon
2023 年 8 月 1 日午前 8:11
5
お二人ともありがとうございます。meta.discourse.orgでこのバグに自然に遭遇し、その設定については知りませんでしたが、修正はすでにコード化されており、パッチは非常に簡単であることがわかってよかったです。OWASPのベストプラクティスを満たすために、その設定は常に有効にする必要があります。管理者がこれを無効にしたいと思う理由はありません。そうすることは、業界のベストプラクティス基準に明確に違反する、完全に不要なセキュリティおよびプライバシーの脆弱性を表しているからです。もし私が理解できないレガシーインストール用にこのオプションを保持する理由がある場合は、現在の構成が業界標準のベストプラクティスに違反していることを示す警告を追加し、代わりに準拠した構成を推奨する必要があります。
「いいね！」 2
dobon
2023 年 8 月 1 日午前 8:28
8
このスレッドにリンクしてくれてありがとう。@awesomerobot は彼らの意見を持つ権利があるが、彼らは業界標準のベストプラクティスを公然と無視し、よく知られており、頻繁に報告され、明示的にコード化されたバグを「バグではない」と主張している。私は、公表されている業界標準のベストプラクティスと比較して、彼らの意見をあまり説得力があるとは思わない。
少なくともデフォルト値はより安全な設定を反映すべきであり、このオプションを無効にすることがフォーラムに意図的で不必要なセキュリティとプライバシーの脆弱性を構成することを、初心者の管理者に伝えるための何らかの兆候があるべきだ。OWASPのエントリへのリンクなど。
このオプションが無効であることが望ましい可能性のあるシナリオを誰か教えてくれないか？私は本当にこれがなぜ論争の的となる問題なのか理解できず、この設定で実装されているオプトインセキュリティモデルを不要にするユースケースを見逃しているのかどうかを知りたい。そのようなシナリオが提案できないのであれば、この設定は常に有効にされるべきであり、したがって設定であるべきではない。
「いいね！」 1
現状ではすべて期待どおりに機能しているため、これを真に Bug
会話を続けるために、こちらを UX
「いいね！」 11
単純に…人々はアカウントを作成したメールアドレスを覚えるのが苦手で、トラブルシューティングのために管理者に連絡してきます。
これは「enforce second factor（二要素認証を強制する）」や「min password length（パスワード最小長）」に似ています。二要素認証は常に要求することが一般的な推奨事項だと思いますし、パスワード最小長の推奨値は、現在一般ユーザーのデフォルトよりも高くなっているようです…しかし、セキュリティの推奨事項と平均的なコンピューター スキルとの間にはギャップがあります。
デフォルトを変更することに強く反対しているわけではありませんが、それらがユーザビリティに影響を与える可能性があることに注意する価値はあります。
「いいね！」 10
Ed_S
2023 年 8 月 3 日午後 12:42
11
これは、ほとんどの他のサイトと同様に、Discourse のデフォルトがベストプラクティスに従うべきだと私には思えます。
インスタンスで適切な設定が行われているようです。
x@example.com
「いいね！」 3
sam
2023 年 8 月 4 日午前 12:59
12
このフィードバックは気に入っていますが、もう少しデータで裏付けられて いるとさらに良いと思います。
以下のサイトは何をしていますか？
Facebook
Twitter
Amazon
Reddit
Yahoo
「いいね！」 3
dobon
2023 年 8 月 4 日午前 4:27
13
このバグに関する皆様の貴重なご意見や視点に感謝いたします。私にとって、これは非常に単純明快で、全く複雑なものではありません。Discourseに存在する、管理者や私のようなセキュリティ専門家によって繰り返し指摘されてきた、よく知られたバグがあり、それはセキュリティ上の脆弱性ではなく、機能として扱われています。NIST: CWE-200: 機密情報が権限のないアクタに公開される 。
フォーラム管理者が、自分がサインアップに使用したメールアドレスについてユーザーから問い合わせが殺到するという仮説的な状況を引用して、業界標準のベストプラクティスに違反するこの安全でないデフォルト設定を正当化することは、意味がありません。なぜなら、「パスワードを忘れた場合」のページを使用すれば、この設定がどのように構成されていても、管理者の介入を必要としないからです。より安全で標準に準拠した設定が有効になっている場合、ユーザーは「メールアドレスを忘れた場合」のダイアログで自分のメールアドレスを確認するだけで、そのアドレスにパスワードリセットメールが届いたかどうかを確認できます。これは、ダイアログで説明されている通りであり、プライバシーを尊重し、標準に準拠した最新のWebアプリケーションで一般的に見られる動作です。さらに、「他のサイトもベストプラクティスに違反している可能性がある」という前提に基づいてこの違反を正当化することは、セキュリティとデータ保護の観点からは論理的または説得力のある議論ではありません。なぜ、明確なメリットもなく、管理者にDiscourseのインストールをわずかに安全で標準に準拠しなくする「機能」を提供しているのか、理解に苦しみます。
それにもかかわらず、@samさんが指示された作業を行いました 。
Google : ユーザー列挙を許可していません。YouTube : ユーザー列挙を許可していません（Googleログインを使用しており、Googleはユーザー列挙を許可していないため）。Facebook : ユーザーが意図的にメールアドレス/電話番号を公開に設定している場合にのみ、その「アカウントを検索」/「パスワードを忘れた場合」のページを通じてユーザー列挙を公式に許可していますが、この種の脆弱性により5億人のユーザーデータが漏洩したことで有名 であり、レート制限と「明示的に公開されている場合のみ」というルールが内部で遵守されていなかったことを発見したセキュリティ監査人に多額の支払いを行っています 。Instagram : ユーザー列挙を許可しており、そのために苦労しました 。これはFacebookで言及したハックとは異なります。X (このフォーラムでは、故人を尊重して敬意を払ってください) : パスワードを忘れた場合のページを通じてユーザー列挙を許可していますが、レート制限やその他の簡単に回避できる障害 を実装しています。しかし、レート制限とデータプライバシー保護の実装におけるバグにより、ユーザーの電話番号が漏洩するという重大な事態が発生しました 。Baidu : メールアドレスを忘れた場合のページでユーザー列挙を許可しており、キャプチャ（およびレート制限もあるかもしれません？中国語は苦手です）を実装しています。興味深いことに、復旧プロセスでは、簡単な復旧メールではなく、管理チームへの異議申し立てが必要です。これはCCPの中央統制に非常に典型的です。Wikipedia : ユーザー列挙を許可していません。Yahoo : パスワードを忘れた場合のページを通じてユーザー列挙を許可していますが、レート制限とキャプチャを実装しています。Yahooがこのバグを悪用した論争に巻き込まれたり、ハッカーに支払いをしたりした例は見つかりませんでしたが、明白な理由からYahooを検索エンジンで検索するのは非常に困難です。Yandex : ログインページでユーザー列挙を許可しており、メールアドレスを忘れた場合のページでキャプチャとチャレンジ質問を実装しています。Whatsapp : ユーザー列挙を許可していません。PCログインはモバイル認証情報で行われます。モバイル認証情報は電話番号に紐付けられています。ログアウトボタンやログインページ/メールアドレスを忘れた場合のページはありません。XVideos : ユーザー列挙を許可していません。PornHub : ユーザー列挙を許可していません。Amazon (eコマースサイト) : パスワードを忘れた場合のページを通じてユーザー列挙を許可しており 、これはAmazon Web ServicesのCognitoユーザープール製品のベストプラクティス推奨事項に直接違反しています 。Amazonがこのバグを悪用した論争に巻き込まれたり、ハッカーに支払いをしたりした例は見つかりませんでしたが、明白な理由からAmazonを検索エンジンで検索するのは非常に困難です。Xnxx : ユーザー列挙を許可していません。メインサイトにはログインページがなく、「ゴールド」サイトはユーザー列挙を許可していません。通常のサイトのモバイル版で無効なログインページを見つけましたが、「メールアドレスを忘れた場合」の機能は全くありません（また、明らかに無効であり、「ゴールド」ウェブサイトに置き換えられています）。Tik Tok : ユーザー列挙を許可していません。パスワードを忘れた場合のページでMFAを強制します。Reddit : ユーザー列挙を許可していません。業界標準のベストプラクティスに準拠しています。)
リストの上位15サイトのうち、8/15（Redditを含めると9/16、Facebookはユーザーが意図的に公開を承認した情報のみ列挙を許可しているため0.5を追加すると仮定すると）はユーザー列挙を許可していません。また、ユーザー列挙を許可しているサイトのうち、少なくとも3/7は、その決定の結果として重大なセキュリティインシデントに直面しています。
「いいね！」 2
dobon:
Google : ユーザー列挙を許可していません。YouTube : ユーザー列挙を許可していません（Googleログインを使用しており、Googleはユーザー列挙を許可していないため）。
これは、おそらく主要なGoogle製品（Gmail）が列挙を許可しているため、やや不誠実です。
メールID プロバイダー のアカウントの存在をテストすることは、それ以外では些細なことなので、リストに含める意味はあまりありません。
リストにある他のプラットフォームは、（潜在的に）セルフホスト型ソフトウェアではありません。
中央Discourseプラットフォームはありません - サイト管理者は 自分で選択する自由があります 。
とはいえ、サイト管理者がデフォルトで良い設定を選択するように促すことには同意します。
管理者が簡単にこのような設定を締めくくることができるノブ（ウィザードに追加することを提案するのはためらわれます）があるかもしれません。
「いいね！」 4
dobon
2023 年 8 月 4 日午前 7:21
15
それは、サインアップページがあるあらゆるサイトに当てはまるのであって、電子メールサービスプロバイダーだけに限ったことではないのでしょうか？サインアップページが同様のプライバシーおよびデータ脆弱性の潜在的なベクトルであり、したがって保護されなければならないというあなたの見解は理解できますが、それはこのトピックで議論しているユーザー認証フローとは別の部分です。このトピックでは、「パスワードを忘れました」ダイアログからの漏洩に specifically に焦点を当てています。誤解しないでください。どちらも絶対に重要であり、注意深い配慮が必要で、プライバシーおよびデータ脆弱性を防ぐために緩和策が必要です。通常、サインアップフォームにはキャプチャが必要であり、「パスワードを忘れました」エンドポイントでは、電子メールが有効か無効かに関わらず、同じ応答を返したいと考えます。多くのサイトでは、「パスワードを忘れました」エンドポイントをキャプチャで保護しています。どちらのエンドポイントもレート制限されるべきです。
私は決して不誠実なことを言おうとしたわけではありません。「他のサイトもコンプライアンス違反だから、コンプライアンス違反でも構わない」という考えが論理的に健全な結論だとは思いませんが、私は単にサムのリクエストに応え、彼が提供したリンクを使用して求めていた「証拠」を提供することで、彼の懸念を和らげようとしていただけです。
MediaWiki ソフトウェアは、何万ものウェブサイト および 数千の企業や組織 によって使用されています。Wikipedia を動かしており、非常にセルフホスト型のソフトウェアです。
私は管理者の自由を確かに奨励しますし、管理者やユーザーの生活を困難にすることは好きではありませんが、この設定の「長所」がどのようなシナリオにおいても「短所」を上回るとは思いませんし、管理者が実際にこの「機能」を望むようなケースはありません。管理者が最大 必要がある のであれば、デフォルトではより安全な位置に設定し、初心者の管理者がなぜ推奨されないのかを理解できるように、安全でない位置は明確に区別されるべきです。しかし、この設定を存在しないものとしてリファクタリングするのが最善の選択肢だと思います。それについては PR を喜んで提出します。
「いいね！」 1
どちらも真空状態で見ることはできないと思います。Discourseのサインアッププロセスには「Email has already been taken」というメッセージが表示されますが、それを別の方法で表示するのは難しいです。そのメッセージが存在する限り、「We found an account that matches」というメッセージが特に問題であるとは考えにくいです。
外部認証のみを許可するフォーラムでは違いがあるかもしれません。
あなたのスタイルに異議を唱えたいという衝動を乗り越えた上で、実質的な点については、あなたの立場が、少なくとも外部認証が使用されている場合には、デフォルトはより安全なオプションであるべきだという範囲で正しいと思います。私はまだ、より安全でないオプションの余地がない とは同意しません（私のフォーラムはDiscourseのデフォルトのサインアッププロセスを使用しているため、パスワードリセットオプションを変更するつもりはありません）。
ちなみに、XVideosとXnxx（Xを除く）がポルノサイトであることを読者に文脈から推測させる一方で、Amazonが「eコマースサイト」であることを説明するのに手間をかけたという事実に笑ってしまいました。
「いいね！」 1
dobon
2023 年 8 月 4 日午前 7:55
17
Amazon.comとAWSを区別するためです。そして、お尋ねの件ですが、AWSではユーザー列挙は許可されていません。
ユーザー認証フローのすべてのステップとそれらがどのように連携するかを考慮する必要があることに同意します。それは非常に重要であり、セキュリティ脆弱性の最も一般的な原因の1つです。あなたが言及したサインアップページでの同様のメール列挙バグが適切に緩和されていない場合、このトピックの結果に関係なく、それは絶対に修正されるべきです。それはhide_email_address_takenの実装におけるバグになるでしょう。ただし、その潜在的なバグ/見落としについての議論は、おそらく別のトピック（そしておそらくバグ タグ付き）で行われるべきです。
「いいね！」 1
ちなみに、「メールアドレスが使用済みであることを非表示にする」が有効になっている場合、サインアップ時にもそのメッセージは表示されません（既存のメールアドレスがそこに入力された場合、招待メッセージも変更されます）。
デフォルトを単純に切り替えることの潜在的な複雑さの 1 つは、「パスワードリセットには完全なメールアドレスが必要」という機能も組み込まれていることです。これは物事を複雑にしすぎる可能性があります（ただし、完全なブロックではない可能性が高い）と考えています。
「いいね！」 2
わかりました。その設定を変更する可能性が高いです。このトピックの何かで、誤解を招いたのだと思います。
これはどういう意味ですか？ユーザー名のみではパスワードリセットができないということでしょうか？
「いいね！」 1
その通りです。 hide email address taken が有効になっている場合、パスワードのリセットにはアカウントのメールアドレス自体を入力する必要があり、ユーザー名だけではできません。
「いいね！」 1
dobon
2023 年 8 月 4 日午前 9:52
21
hide_email_address_taken SiteSetting を prevent_password_recovery_by_username にリネームし、非準拠の動作をすべてのユーザーに対してアプリからリファクタリングすることを提案します。これにより、すべてのインストールのパスワードリセット機能は変更なく維持され、メール列挙の脆弱性にも対処できます。私は熟練した RoR + Javascript 開発者であり、このプルリクエストを喜んで実装します。コードベースをざっと見ましたが、それほど広範囲にわたる PR にはならないでしょう。
この「機能」をリファクタリングして廃止することが本当に不可能なのであれば、それでもこれらの 2 つの関連概念を個別の SiteSetting エントリに分離することは理にかなっていると思います。
「いいね！」 1
)
