新しいGmailログインシステム-従来の知恵に反しますか？
新しいGmailログインでユーザー名の入力が求められ、次にそのようなユーザー名が存在するかどうかを確認してから、パスワードの入力を求めていることに気付きました。
これは、ユーザー名が存在するかどうかに関する情報を漏らさず、多くの可能なユーザー名を試行する攻撃のクラスを阻止するという、従来のセキュリティの知恵に反するものではありませんか？
私はGoogleが彼らのしていることを知っていると思いますが、これは彼らが従来脆弱性と考えられていたものから保護するための何らかの方法があることを意味しますか？
小規模なサイトの場合、ハッカーがユーザーリストを列挙できるようにしたくないのですが、Googleの場合、サイトは非常に大きいため、ほぼ全員が1つまたは複数のアカウントを持っていると想定できます。したがって、ユビキタスのしきい値を設定すると、リスクは最小限に抑えられます。
ほとんどのサイトでは、ユーザー名が存在するかどうかを開示しないことをお勧めしますが、リスクは新規ユーザーの登録プロセスと比較する必要があります。防止したいのは、自動化されたプロセスによるリストの列挙です。新しいユーザー登録プロセスには、スクリプトがユーザーの辞書をすぐに試すことができないように、何らかの形の遅延またはゲートを含める必要があります。これは、登録プロセスの失敗または失敗の結果を電子メールで送信することによって達成されることがよくあります。はい、まだ列挙できますが、遅延と追加のステップがあります。
考慮すべきもう1つのことは、パブリックサイトとプライベートサイトの違いです。 Googleはパブリックサービスであり、ユーザー名もパブリックです（アカウントから送信されるすべてのメールで公開されます）。一方、現在の従業員だけがアクセスできる内部企業サイトは非公開であり、列挙を防ぐためにより厳密な制御が必要です。
ジェフ・アトウッド、ディスコースへのログインを作成するとき、件名に これは言わなければなりませんでした ：
これは、ユーザーが「パスワードを忘れた」フォームに電子メールアドレスを入力したときに、その電子メールアドレスが登録されているかどうかをユーザーに明らかにすることが理にかなっているかどうかについての 談話での長い議論 のソースでした。多くのウェブサイトで、パスワードを忘れた場合のフォームにメールアドレスを入力した後に表示されるメッセージは次のとおりです。
アカウントが[email protected]と一致する場合は、すぐにパスワードをリセットする方法の手順が記載されたメールが届きます。
所与の電子メールアドレスがサイトに存在するかどうかを明らかにすることによるすべてのセキュリティへの影響に対するヘッジ である、そこにある恥ずかしがり屋に注意してください==パスワードを忘れた場合のフォームに入力するだけです。
私たちはDiscourseの安全なデフォルトを選択することについて真剣に真剣に取り組んでいるため、箱から出して悪用されたり、悪用されたり、スパマーでオーバーランしたりすることはありません。しかし、実際に「どのメールをここで再び使用したのか」を体験した後、自分自身で数十のDiscourseインスタンスのログイン状態を確認したところ、この特定のケースでは、ユーザーフレンドリーであることが安全であるよりもはるかに重要であることがわかりました。
Gmailの場合、@gmail.comアドレスにメールを送信するだけで、アカウントが存在するかどうかを確認できます。バウンスした場合、そのアカウントは存在しません。
これは、多くの電子メールプロバイダーに当てはまります。ここでは、ユーザー名は秘密とは見なされません。ユーザーがメールアドレス[email protected]を持っている場合、fooがexample.comにユーザー名[email protected]のアカウントを持っていることを誰もが知っています。
ただし、他のほとんどのシステムでは、ユーザー名を明らかにすることはプライバシーの侵害です。誰かが[email protected]にnostringsattacheddating.example.orgのアカウントを持っていることを発見でき、ボブの妻アリスがWebサイトでユーザー名[email protected]で登録してみて、ユーザー名がすでに使用されていることがわかる場合は、プライバシーの大規模な侵害。
メールアドレスはメールプロバイダーにルーツがあることに注意してください。 [email protected]が誰であるかについての参照ポイントがないため、example.comが[email protected]にアカウントを持っていることがわかっている場合、プライバシーは失われません。ユーザー名としてメールを使用する別のシステムについては同じことが当てはまりません。メール以外のウェブサイトのユーザー名が[email protected]のユーザーは、他のウェブサイトで登録されているものと同じ[email protected]になります。マロリーが持っているアカウントについて保護するプライバシーがあります。
また、ユーザー名を明らかにすることは、攻撃者にとって有用です。これは、ユーザー名列挙の脆弱性として知られています。 攻撃者が存在するユーザー名を知っている場合、パスワード推測攻撃を実行できます 。
攻撃者として、ログインページまたはパスワードを忘れた場合のページを使用して、リストを10000のターゲットから1000のターゲットに絞り込むことができれば、私はそうします。
また、攻撃者はフィッシングを介してシステムのユーザーを標的にすることができます。
ユーザー列挙が実行できないシステムを簡単に設計することができます。たとえば、サインアップと忘れたパスワードのプロセスはまったく同じです。
手順は次のとおりです。
- システムは、他の入力フィールドなしで、単一のページでユーザー名（電子メール）を要求します。
- フォームが送信されると、システムはユーザーにメールアカウントを確認するように求めます。
- アカウントが存在する場合、メールにはパスワードリセットリンクが含まれます。
- アカウントが存在しない場合、メールにはサインアップリンクが含まれます。
おまけとして、後日パスワードをリセットする必要がある場合に備えて、サインアップ時にメールアドレスを検証しました。入力ミスがあると、ユーザーはまったくサインアップできなくなります。これは、ユーザーが誤って別のメールアドレスに登録されたアカウントを使用していないためです。
パスワードとサインアップリンクの両方に暗号化された安全なランダムIDが含まれているため、電子メールを受信せずに追跡することはできません。ユーザー名が登録されているかどうかを確認できるのは、アカウントにアクセスできる人だけです（ボブはメールとラップトップのパスワードをアリスから秘密にしておく-アリスがこのプロセスを試したときに備えて、通知音をオフにするのが賢明です。同じ部屋にいる）。
関連トピックについては、他のいくつかの回答を参照してください。
すべてのアカウントが大規模な企業または政府のシステム上にあった「ビッグ・アイアン」の時代にルールが発展したと私は確信しています。システムがアカウント名を配布したため、アカウント名を探すためのサインアップページの使用は問題ではありませんでした。したがって、アカウント名のリストを維持することは、実行可能で便利でした。
自己登録サイトを扱っているので、アカウント名リストを秘密にしておくことは不可能です。さらに、最近では非常に多くの人々が自分のアカウント名をとにかく公開しています。このような状況では、パスワードの代わりに失敗したのが名前だったという事実を隠そうとしても意味がありません。
最初にユーザー名の入力を求め、次にパスワードの入力を求めることには、より重要な理由があります。これにより、Googleは passwordless authentication または他の実験的なログインメカニズムを使用しているアカウントに別のUIを提供できます。それ。
これは、パスワードが入力されるまでGoogleの2Factor認証UIが表示されないのと似ています。攻撃者は、最初の要素をクラックするまで、2番目の要素が関係していることさえ知りません。
ユーザー名の漏えいの比較的非リスクについて他の回答がここで言っていることと組み合わせると、これは実際にはセキュリティの改善のようです。
攻撃者はサインアップページからも確認できるため、どのユーザー名が存在するかを知ることは重要ではありません。 Googleでは、攻撃者がユーザー名リストを取得するためにブルートフォース攻撃などの攻撃を実行することを許可していません。
メールアドレスはユーザー名と同じではありません。ユーザー名はセミプライベート情報です（潜在的に）が、電子メールアドレスは公開され、公開されます。郵便、よく知られている場合はそのメールアドレスを考えてください。しかし、有効な受信者の現在のリストは、必ずしも公開するように設計されているわけではありませんが、オンラインで調べる方法もしばしばあります。グーグルのようなものの場合、彼らはグーグル+、ユーチューブ、グーグルグループなどを持っています。
telnetを使用 または 多くのWebサイトがそれを行う のように、電子メールサーバーにクエリを実行して、特定の電子メールアドレスが存在するかどうかを判断することも簡単です。他の方法で簡単にアクセスできる情報を保護することから得るものはほとんどありません。これが、一部のサイトがユーザー名の電子メールアドレスを分離する理由です。電子メールプロバイダーの場合、平均的なユーザーのログオン名と電子メールアドレスを変えることは実際には意味がありません（おそらく、セキュリティに執着のないユーザーがこの機能を望んでいるでしょう）。
2段階ログオンに切り替えると、ユーザーのパスワードが検索フィールドまたはユーザー名フィールドに入力される可能性が低くなります。これらのフィールドはログに記録されることが多く、ログは場所全体で相互に関連付けられ、セキュリティで保護される可能性は低くなります。したがって、ログがハッカーまたは国家によって攻撃された場合、攻撃者はユーザーのIPアドレスをユーザー名と関連付けて、「m7p @ 55w0rd !!!!」のような何かに気付く可能性があります。これは突き出て、そのパスワードを想定しています。
リスク管理の観点から、パスワードが漏洩するリスクは、ユーザー名を列挙するリスクよりもはるかに大きくなります。 Googleは、既知のユーザー名に関連するリスクに対処するために、より強力な不正防止および異常追跡機能を備えている可能性があります。
これを理解する良い方法は、 FAIRの紹介（pdf） のタイヤスイングの例だと思います。既知のユーザー名のリスク計算は、他の制御や要因の影響を受けます。あなたはブルートフォース攻撃を阻止し、多要素認証を要求しますか、他にどのようにしてこの情報を取得できますか？シナリオでは、制御できるリスク（すべてのログインの監視）と、制御が難しい古いフォームの何か（ユーザーが間違った領域にパスワードを入力した）の間で効果的にトレードオフしています。
私はすぐに外に出て、ユーザーのオープンリポジトリではないことを確認するために、いくつかのメカニズムを備えている可能性が高いと言います。
同様のシステムを 私たちの小さなサイト に実装し、redisを利用したソリューションを使用しました。
ユーザーには、ログインと登録のためのボタンが付いたシンプルなメール/パスが最初に表示されます。メールを入力して次に進むと、一致するかどうかがチェックされ、一致する場合は登録ボタンが削除されます。そうでない場合は、完全な登録フォームが表示されます。
特定のしきい値を超えた後、IPサブネットとブラックリストによる試行回数を追跡します。ブラックリストはサイトを使用する能力に影響を与えず、単にログイン/登録オプションの標準的な動作に戻ります。
はい、虐待を防ぐためのシステムが整っています。 Googleには広範な「異常検出」メカニズムがあり、アクティビティが疑わしい場合にエラーやキャプチャを提供します。最もよく知られている例は、Google検索とNoCaptcha ReCaptchaのブロックです。
あなたがそのアカウントが存在するかどうかを知ることを許可されたという事実は、誰もがあなたが実際に他の誰かのユーザー名を推測できるわけでも、推測できるわけでもありません。あなたがブロックされるまでの時間をお試しください。興味深いテストです。
ほとんど誰もがすでにこれをしています
新しいGmailログインでユーザー名の入力が求められ、次にそのようなユーザー名が存在するかどうかを確認してから、パスワードの入力を求めていることに気付きました。
Googleにはすでにこの機能があります。新しいGoogleアカウントにサインアップしようとすると、ユーザー名がすでに存在するかどうかを確認する必要があります。
これは、ユーザー名が存在するかどうかに関する情報を漏らさず、多くの可能なユーザー名を試行する攻撃のクラスを阻止するという従来のセキュリティの知恵に反するものではありませんか？
確認しなかった場合、どのように適切に認証しますか？同じユーザー名を持つ複数の人々は、ウェブサイトの整合性にとって悪いニュースです。もちろん、多くの場合、一意のメールアドレスを使用して、複数の人が同じ名前を持つことを許可できます。
前に言ったように、ほとんどすべての人がすでに何らかの方法でこれを行っています。ここで心配することは何もありません。 スローダウンユーザー名の大量列挙をしたい場合は、数回試行した後にキャプチャを含めるだけです。
キャプチャは大量メール送信のトリックを実際に防ぐことはできません
スパマーは頻繁に大量のスパムを電子メールアドレスに送信します。 Googleがメールを迷惑メールフォルダに移動する可能性がありますが、バウンスしないメールによる列挙を妨げるものではありません。
何千もの異なるIPアドレスを使用する大量メーラーを作成し、返送された電子メールを受信しないことで列挙しようとするのは簡単です。ランダムなゴミを送ることもできます。メールアドレスが存在するかどうかを確認することが目的である場合は、数日後にエラーメールを受信しないことで十分です。