2段階のログインフォームで、最初に尋ねられるのがログイン名であり、パスワードではないのはなぜですか？
インターネットにはいくつかのログインフォーム（Googleなど）があり、最初にログイン名を入力し、それが送信されると、パスワードを入力できるようになります。
これの利点の1つは、サーバーが知っている画像のみを取得してユーザーに表示し、単純なフィッシングスキームを阻止できることです。
私の質問は、なぜ逆にそれをしないのかということです-最初にパスワードを要求し、次にログイン名を要求します。
私は明白な答えを見ることができます（パスワードが一意ではない可能性があり、そのためサーバーは誰のフィッシング詐欺画像を表示するのかを知りません）が、それは私を納得させません。パスワードを共有するアカウントをすぐに無効にするか、少なくとも次回ログイン時にユーザーにパスワードを一意の文字列に変更するように強制することは、その回避策であり、それ以外に、「123456」パスワード現象を解決します。
私が見ることができるもう1つの問題は、ユーザーがパスワードを正しく入力し、間違った画像が表示されることに気づいたフィッシングのシナリオで、彼はすでにパスワードを与えられており、フィッシャーが行うべきことは誰がこれを特定することだけであるということです。パスワードが属しています。
私が知りたいのは、ログインしてからパスワードを入力するシーケンスのほとんどが慣習またはユーザーインターフェイスの考慮事項によるものか、最初にパスワードを要求するシーケンスを逆にすることで他のセキュリティ問題があるかどうかです（前述の2つに加えて） ）。
単独のパスワードは、それ自体で検証できるとは限りません。特に、サーバーが適切に処理を行う場合、サーバーはパスワード自体を保存するのではなく、パスワードに対して計算された パスワードハッシュ関数 の出力を保存します。 （単なるハッシュ関数ではなく）パスワードハッシュ関数には、salt（非常に優れたセキュリティ関連の理由から）を含むいくつかの追加機能が含まれています。パスワードを確認するには、対応するソルトの知識が必要です。ソルトはインスタンス固有であるため（ソルトのポイントは、異なるユーザーが独自のソルトを持っていることです）、ユーザーIDが必要です（ユーザーIDはソルトのインデックスキーとして使用されます）。
1つには、サーバーはパスワードだけがアカウントと一致したかどうかを認識しません。
安全なシステムでは、パスワードはソルト処理されてからハッシュ化されます。
単純なデモで、3人のユーザーがいるとします。
Username Password
bob foobar
alice foobar
maggie foobar
これらのパスワードが設定されると、ソルトが追加され、ハッシュが生成されます。
Username Salt Value to hash Hash result
bob ABCDEF ABCDEFfoobar 778f9aab91717e420e447d7e4cdd84f1
alice 123456 123456foobar 17e9191daecc5b8be26779209769b275
maggie ZXCVBN ZXCVBNfoobar 527cb07b112559cf9c1aff19d28074fa
ご覧のとおり、saltの目的は、パスワードが一致しても、2つのパスワードが同じように格納されないようにすることです。これは、抽出されたパスワードリストでRainbowテーブルが使用されないようにするための重要なセキュリティ手順です。
このため、使用するソルトが不明なため、パスワードのみに基づいてログインしているアカウントを特定できません。これは、ユーザー名が検索のキーとして使用され、サーバーに提供されない場合、ステップ1で入力されたパスワードは、一致が見つかるまでユーザーテーブルの各ハッシュを試さないと一致しません。適切に構成されたシステムでは、遅いアルゴリズムを使用しているため、これは遅すぎます（脚注を参照）。
また、システムがあなたのパスワードが別の人によって使用されているとシステムに通知した場合、それは大規模なセキュリティ情報漏えいになるでしょう。
上記の例は、説明のみを目的としており、MD5を使用しています。 MD5を使用してパスワードをハッシュしないでください。bcrypt、scrypt、またはpbkdf2を使用してください。
基本的に「パブリックパスワードとプライベートユーザー名がない理由はありますか？」
どちらも単なるテキスト文字列です。一意のパスワードを適用するというあなたの考えは、実際にはユーザー名は一意であると言っているだけです。テキストボックスに適用するラベルは重要ではありません。非公開の文字列をパスワードと呼び、一意の文字列をユーザー名またはユーザーIDと呼びます理由一意です。
セキュリティの観点から、ログイン/パスワードの通常の順序で確認する：bothを一意にする必要がある場合、チェックされたすべてのパスワードがすべてのユーザーに対してチェックされるため、データベースに攻撃を仕掛けます。データベース内パスワードを一意にする必要があるため。したがって、どちらも一意には機能しません。どのアカウントがアクセスされているかわからないため、どちらも一意ではありません。つまり、一意の文字列は1つだけになります。単一の一意のテキスト文字列を作成する場合、それをデータのパブリックピースにして、最初にそれを確認することもできます（このデータをログイン/ ID /ユーザー名と呼びます）。
アナロジーを想像してみましょう...
私は、城の谷にある特定の城にメッセージを届けるために王から送られたメッセンジャーです。私は行きたい城がどのようなものか知っており、警備員にその城に入れられるようにパスフレーズを与えられました。
これを行う方法には2つのオプションがあります。
ご想像のとおり、これを行うための従来の方法は、私が送られた城に乗って、パスフレーズを許可するように伝えます。これは、まず私の公開情報（城、私の個人情報（パスフレーズ）でログインします。
しかし、これを行うには逆の方法があります。私はホーンを手に入れ、パスフレーズを渓谷全体に叫び、一般の人に聞くことができます。私が訪問するつもりの城は私のパスフレーズを聞いたので（他のすべての城や潜在的に悪意のある谷の住民と一緒に）、私が訪問している城は私に期待することを知っているはずです。
それから私は正しい城に馬に乗って進み、開いた跳ね橋を横切ります。しかし、彼らは誰もがこの開いた跳ね橋を通り抜けることを許しました！私の個人情報が世界中に共有されたので、誰でも城間を行き来し、門を開けて城に入ることができます。
私がこれを自分でホーンに叫ぶためにここにいない場合、渓谷の住民は自分のホーンで丘の頂上に立って、跳ね橋が開く音が聞こえるまで、渓谷の向こうで意味不明なことを叫ぶことができます。彼らがパスフレーズを正確に推測したことを知っているので、彼らは彼らが開いているものを見つけるまで、単に城の間を走らなければなりません。
最初のオプションは、通常の方法です。その規則を変更する理由はありません。別の方法も可能ですが、個人情報を最初に共有することで、公開情報で認証する前に一度に全員のパスワードを推測するのが非常に簡単になります。アカウント名。この谷には何千もの城やウェブサイトのアカウントがあるため、誰かが簡単なパスワードを推測する可能性が高く、数千の城またはパブリックアカウント名のいずれかと単純に一致させる方がはるかに簡単です。
Googleでは、セキュリティ上の理由から、最初に電子メールを入力するように求めていません。電子メール/ユーザー名を入力する必要があるため、SSO/SAMLの独自のランディングページが必要な仕事または教育のドメインにログインしている場合
最初にパスワードを要求する場合、ユーザー名を待つ間、「秘密」の値をある状態に維持する必要があります。 Webアプリでは、2番目のリクエストでユーザー名が入るので、新しいプロセスが値を読み取ることができるように、通常は何らかの方法でそのストレージを行う必要があります。これにより、時間とデータへのアクセス方法の両方に関して、パスワード文字列が公開される機会が増えます。
最初にユーザー名を要求することで、ソルトハッシュを使用する（または使用しない）パスワード検証は、すぐにパスワードを検証するために必要なすべてのものにアクセスでき、システムはパスワード自体を最小限の時間だけ使用できるようにするだけで済みます。一般的には、機密データを可能な限り短時間で使用できるようにすることが最善です。
そしてそれは慣習です。最初にパスワードを要求すると、ユーザー名を誤って別の場所のユーザー名フィールドに入力するようにユーザーをトレーニングすることになり、おそらくログを通じて開示されることになります。
しないでください。 :)
追加する; 識別vs認証/検証のメカニズムは、アプリケーションの開発時に決定されます。 Identification is 1：many、verification/authentication is 1：1
1:1 - match against one pre-selected result set;
1:many - match against all results in the DB
Gmailのようなユーザー名は一意です。これはすべてのアプリケーションに必須ではありませんが、識別アルゴリズムとは対照的に、検証アルゴリズムの方が確実に楽になります。
ポピュラーなユーザー名とGmailのパスワード認証を検討してください。
ユーザー名を入力してください。
gmailは、他のすべての一意のユーザー名と一致する一意のユーザー名を照合します。はい、一致しました。パスワードを入力してください。一致なし、アクセスなし。
パスワードを入力する。
gmailは、1つのユーザー名と、任意の形式で保存された1つのパスワードを照合します。一致しません。認証に失敗しました。はい、一致しました。メールにアクセスしてください。
かなり簡単な私見。
反対に、識別（1：many）、gmailのマッチングプロセスは次のようになります。
パスワードを入力する; そして@SilverlightFoxが明確に示しているように、多くのアカウントは同じパスワードを持つことができます。
matching algorithm matches password to ALL usernames registered in gmail database.あまりにも控えめな結果セットでは、10個のユーザー名を使用できます。
- ユーザーネームを入力してください;
ユーザー名が一意であるか同じであるかは、認証プロセスが実行される時間moreと一致する数が決定されます。一致するものが2つ以上ある場合は、3ステップのログイン認証を実装する必要があります。
2段階認証により、開発者とアルゴリズムの作業が楽になります。
グーグルおよびほとんどの分割認証設定の場合、システムは基本的にユーザーIDを使用して関連するリスクを識別し、ユーザーに対して実行する必要のある適切なログインプロセスを決定します。
これらの状況のほとんどの場合、人が入力したユーザーIDは、考慮される1つの入力にすぎません。それに加えて、他の多くの情報（アクセス元のIPアドレス、ユーザーが使用しているデバイス-ユーザーIDとともに生成されて渡されたデバイス署名がある）がリスク判定エンジン（ほとんどの銀行）に渡されますただし、常に使用されるとは限りません）。これにより、推奨されるログインプロセスが提供される場合があります。そのシステムに加えて、ユーザーに関連付けられたログインポリシーをチェックします（つまり、多要素が有効になっているかどうかなど）。最終的な決定に基づいて、ほとんどの場合、単純なパスワード画面が表示されるだけですが、場合によっては、複数の認証プロセス（電話ベースのOTPなど）に進むように求められることがあります。