パスワード認証を含む2要素認証と2段階認証の違いを意識する

こんな話です。

想定する認証

この投稿内では以下のようなものを想定しながら話を進めます。

2段階認証

パスワード認証の後、異なる認証を行う。

参考:Google
Google 2 段階認証プロセス

• 2段階目の認証方式 : 2要素認証に揃えてOTPアプリやYubiKeyなどのセキュリティキーあたりを使う
• 認証時には、メアドなどのユーザー識別子とパスワードを入力させた後、パスワード認証に成功したら設定済みの2段階目の認証を要求

ここではパスワード認証を含むフローを想定しているので識別子とパスワードの入力を一緒にしてますが別でもいいです。

2要素認証

ここではパスワード認証 + 所持/生体認証に相当するあたりを組み合わせる設計を想定する。

参考:AWS

AWS での多要素認証 (MFA) の使用 - AWS Identity and Access Management

• 2要素目の認証方式 : OTPアプリやYubiKeyなどのセキュリティキーあたりを使う
• 認証時には、メアドなどのユーザー識別子とパスワードを入力させた後に2要素目として設定済みの認証を要求し、それぞれの値を検証する

実装難易度/UX

2段階認証

• 既存ロジックの後に2段階目の認証ロジックをいれる。ある意味疎結合。
• エラーハンドリングもそのまま返して良い

2要素認証

• パスワード認証のパラメータを保持しつつ、2要素目の認証方法の検証と同時に行う必要がある
• エラーハンドリングもある程度曖昧にする必要があるため、C向けサービスでは特に離脱が増える可能性がある

考察

ここからはいくつかの視点から考察していきます。

対リストスクリーニング

有効なメアドリストがあるとして、認証機能にてサービスに登録済みかどうかを調べようとする試行を想定。

• 2段階/2要素認証が任意の場合 : 2段階/2要素目の認証を要求した時点で登録済みかどうかはわかる
• 2段階認証必須の場合 : 正しいパスワードを知らないと登録済みかどうかはわからない
• 2要素認証必須の場合 : 正しいパスワードを知らなくても2要素目の認証が求められるため、セキュリティキーなどを使う場合は登録済みであることがわかりそう。

2要素認証の場合、これだけを見ると未登録のユーザーの場合も2要素目の認証を要求するような対策が必要そうですね。

有効なパスワードを入れた際の挙動

アクセス元を散らしたりしながらカウンタにかからない程度に調整された、リスト攻撃やブルートフォースアタック、リバースブルートフォースアタックなどで正しいパスワードが入力された場合を想定。

• 2段階認証必須の場合 : 2段階認証の要求により、パスワードが正しいことはわかる
• 2要素認証必須の場合 : 全てのユーザーに2要素目の認証が要求されるため、パスワードが正しいことはわからない。

まとめ

• ユーザーが登録されているかどうかの精査については、2要素の方がわかりやすくなる可能性がある
• 2段階認証では1つめの認証方式の応答でパスワードの有効性がわかるのでユーザー数が多いサービスであればリスト精査に使われることがあるかもしれない
• 2要素認証ではそれがないぶん、ユーザーもどこがダメなのかわかりにくい可能性がありそう

追記

このリアクション良かった。

引用RTもしましたが、要素と段階は本来別軸でしょう。

• 今回の2要素認証 : 1段階2要素
  • UserVerification有りのセキュリティキーなども1段階2要素かも
• 今回の2段階認証 : 2段階2要素
• パスワード + 秘密の質問とか : 2段階1要素。秘密の質問3つあるのとか見たことあるけどあれは...

が、世の中混乱してるので細けぇ話をしてもピンとこなそうというところで、パスワード+αに絞って一般的な呼ばれかたに近い形で比較しました。