2FAパスワードの前にコードを尋ねない理由
したがって、ログインページのほとんどのWebサイトでは、ユーザー名とパスワードを入力する必要があります。ユーザー名とパスワードを入力してフォームを送信するFacebook。他のウェブサイトは、それぞれ別々に尋ねます。ユーザー名を入力して送信し、次にパスワードを入力して送信するGoogleなど。
2番目のスキームが使用される場合-ユーザー名、次に送信など。なぜSMSコードを最初に使用しないのですか？
私の考えでは、これにより、ユーザーがパスワードを推測またはブルートフォースするのを防ぐことができます。これは、電子メールなどの他のサービスで一般的に使用され、次にSMS権限からアカウントのロックを解除するためにしばしば使用されます。
別の理由は、これがユーザーにログイン試行に関する情報を直接提供することです。
編集：facebookやgoogleと同様に、2FAは必須ではなくオプションであることに言及していないことに気付きました。
また、2FAプロセス自体に欠陥はないことを前提としています。ユーザーが無効な番号を設定することはできず、設定時に番号がチェックされます。番号が正しいことを確認するために必要なテストOTPを送信することにより、番号がチェックされます。
TL; DRセキュリティは困難であり、セキュリティプロトコルの動作にわずかな変更を加えるだけで、予期しない攻撃が発生する可能性があります。一見、パスワードの前に2FAを置くように見えるかもしれませんが、パスワードの保護に役立ちますが、実際にははるかに悪い攻撃が開かれます。みてみましょう！
私たちが解決しようとしている問題
あなたの質問によると、あなたが解決しようとしている問題はパスワードの総当たりです。これは、パスワードハッシュの盗難または漏えいしたデータベースハッシュに対してユーザーがパスワードを解読するため、少々厄介な問題です。レート制限のようなものがすでにこの問題を解決するのにかなり優れているため、ライブサーバーに対してブルートフォースを行いません。それでは、さまざまなタイプの2FAと、2FAがパスワードの前にある場合にどうなるかを見てみましょう。
コード生成アプリ
別名 時間ベースのワンタイムパスワードアルゴリズム（TOTP） 、たとえば、Google認証システム：
私は頭の中で、これを最初に置くと認証プロトコルが弱くなる理由を考えることができないことに同意します。
通知アプリ
一部の2FAは、Blizzard Authenticatorのように、コードの入力を要求するのではなく、電話で通知をポップアップするように設計されています。
これをパスワードの前に置くことを提案することは、サービス拒否攻撃につながるため、実際には危険です。攻撃者はユーザーのアカウントをハンマーし、ほぼ常に通知が携帯電話に届くようにします。自分の電話を使用する、および/または通知を停止する（およびアカウントを弱める）ために2FAを無効にするように強制する。
SMSコード
別名SMSで携帯電話にワンタイムパスワードを送信します。
これには通知アプリと同じ問題があり、明らかにサービス拒否攻撃につながりますが、一部の地域では電話キャリアが着信SMSに課金するため、攻撃者がユーザーに莫大な携帯電話料金を支払うよう強制できるため、状況はさらに悪化します。
概要
私が言及した3つのタイプの2FAアプリのうち、あなたの提案は1つには中立であり、他の2つには有害です。
また、2FAのステップを最初に配置すると、2FAを有効にしたユーザーと有効にしていないユーザーが攻撃者にアドバタイズされます。基本的に、簡単なターゲットは誰かを伝えます。
最後に、通知とSMSベースの2FAサーバーがもう1つの重要な目的：パスワードが解読されたときに通知するアラームです。予期しない2FA通知を受け取った場合は、変更するときですわたしのパスワード。
私はあなたが箱から出して考え、物事のあり方に挑戦しているのが好きです。セキュリティは難しいですが、これ以上質問することを躊躇しないでください。これは答えるのが楽しいものでした。
これは、間違いを犯したユーザーが絶対に来ないOTPを無期限に待たないようにするためです
ワンタイムパスワード（OTP）がパスワードの前に来た場合のワークフローを想像してください。次のようになります。
- ユーザーがユーザー名を入力します
システムがユーザー名を検索して携帯電話番号を見つける
a。ユーザー名が有効で電話番号が存在する場合、システムはOTPを送信します
b。どちらも存在しない場合、システムは何も送信しません
どちらの方法でも、「アカウントに関連付けられている携帯電話番号にワンタイムパスワードを送信しました。」と表示されます。
なぜ「どちらにしても」と尋ねるかもしれません。どちらの場合もメッセージが同じになるのはなぜですか？ OWASP authentication cheat sheet を参照してください：
アプリケーションは、ユーザーIDまたはパスワードが正しくないかどうかに関係なく、一般的なエラーメッセージで応答する必要があります。また、既存のアカウントのステータスを示すものでもありません。
正しい応答の例
-「ログインに失敗しました。ユーザーIDまたはパスワードが無効です」
誤った応答の例
「ユーザーfooのログイン：無効なパスワード」
「ログインに失敗しました、ユーザーIDが無効です」
「ログインできませんでした。アカウントが無効になっています」
一般的なメッセージの理由は、ハッカーがユーザーIDファーミングに使用できるシグナルを提供しないようにするためです。
それでは、ワークフローを続けましょう。
ユーザーが電話番号を持つ有効なユーザーIDを入力した場合、OTPを受け取り、それを入力できます。
ユーザーが有効なユーザーIDを入力しなかった場合、または電話番号が関連付けられていないユーザーIDを入力した場合、ユーザーは無期限に待機します。
これで問題がわかりました。ユーザーがミスをした場合、システムは彼女がミスをしたことを彼女に知らせることができず、彼女はOTPを無期限に待たなければならないでしょう。これは、フィードバックが即時に行われるパスワード認証とは異なります。
最初にパスワードをチェックすれば、この問題全体はなくなります。ユーザーが最初の要素で認証されると、ユーザーIDが有効であることはすでに確立されており、アカウントに電話番号を設定したことがないかどうかをユーザーに通知しても問題ありません。
他のユースケースも影響を受けます
これらの他の使用例も、UXが貧弱になるか、セキュリティ要件のために実装が厄介です。
- ユーザーには複数の電話があります。
- ユーザーは最近電話を切り替えました。
- ユーザーが自分のユーザーIDを覚えていない
- ユーザーはロックアウトされた状態です
- ユーザーのSMS受信トレイがいっぱいです
- 運送業者の制限、例えばSMS制限を超えているか、コレクション内の顧客
- 電話の紛失/盗難
これはスパムの理由によるものです
これにより、攻撃者はユーザー名（主に、これらは公開されているか、非常に簡単に推測できる）を反復できるため、Webサイトはlotの不要なテキストを送信します/みんなにメール。その場合、Webサイトは確かに「スパマー」としてブラックリストに登録されます。
そしてこれは安全ではありませんが、すべてのログインを数分間シャットダウンすることを除いて（コメントで述べたように1つのアカウントのみをスパム送信し続ける場合、すでに数分前に要求された場合、別のOTPの送信を拒否できますが、これは不可能ですウェブサイトごとに行われます）。
すべての人のパスワードも知っている必要があるため、パスワードを要求すると、最初にこの種の攻撃がブロックされます。