マルチレベル認証の利点は何ですか？
マルチレベル認証とは、ユーザーが自分のアカウントにログインするために、プライマリユーザー名とパスワードのキーペアを利用することを指します。次に、トランザクションの承認など、その他のアクションを実行するには、セカンダリパスワードまたはパスフレーズを入力して、自分自身を再認証する必要があります。
では、マルチレベル認証の利点は何ですか？私の頭に浮かぶ唯一の利点は、ユーザーが誤って自分のアカウントを開いたままにしたり、誰かがメインのユーザー名とパスワードを知っている場合、何もできないということです。
しかし、フィッシング、キーロギング、およびブラウザ内攻撃についてはどうでしょうか。マルチレベル認証はこれらのタイプの攻撃に対してまったくセキュリティを提供しないと言ってもいいでしょうか？どうもありがとうございました ：）
すべての認証が同じデバイス（デスクトップクライアント）にパスワードを入力することで行われる場合、はい、キーストロークロガーは引き続き問題になります。認証システムを分離すると、多要素認証へのオプションも開くことに注意してください。現在ではない場合でも、将来的には、トークンや個別のキーパッドなどを使用できるため、簡単な操作を制限できます。高い特権アクセスを取得するキーロガーの機能。
中間の男-中間の男が両方の認証レベルで中間にいる場合、はい、それは問題です。しかし、ほとんどの場合、両方が同じ道をたどったことに驚いたでしょう。だから、あなたがウェブブラウジングについて話しているなら、おそらく。しかし、それがホストへのアクセスである場合は、ネットワーク上の何かへのアクセスです。2つのパスについて話している可能性があり、中間の人は両方へのアクセスが必要です。
ソーシャルエンジニアリング（フィッシングを含む）-通常、マルチレベル認証には複数回のトレーニングが含まれます。管理者アカウントと通常の従業員アカウントの場合、従業員は通常、セキュリティの重要性について長い退屈なトレーニングセッションを受講しますが、効果的である場合とそうでない場合があります。非常に多くの場合、リスクの高いアカウントを持つ管理者は、よりポイントの高い2回目のトレーニングを受け、さらに「これを大規模で不注意な方法で混乱させると、解雇される」という流れに沿ってトレーニングを受けます。パスワードを与えたり分離したりすることにより、多くの場合、管理上、これを実施するのが簡単になります。
その他の利点：
個別のセキュリティプロセス-2つのレベルのパスワードを使用すると、高レベルのパスワードストアがプライバシーに向かう傾向がある一方で、低レベルのパスワードストアを可用性の面で妥協させるオプションがあります。例えば：
低レベルでは、フェデレーションサービス、リモートアクセス、企業以外のデバイスをサポートするサービスなどを提供できます。高レベルのストアでは、建物への物理的なアクセス、すべてのデバイスで利用できない暗号化機能、およびより高度なパスワード品質が必要になる場合があります。
個別のストレージ-ライブおよびバックアップとロギングの両方。ハイエンドシステムでは、暗号化されたテープバックアップ、一定期間安全に保管された監査ログが必要になる場合があります。インフラストラクチャを完全に分離できると、非常に役立ちます。ハイエンドのストレージは高価なので、保管する量を減らすことは大きなメリットです。
アクセス監視-アクセス試行のライブ監視-インフラストラクチャのはるか前にあるシステムは、DDOSになるまでそれについてあまり気にしないほど多くのブルートフォース試行を1日に呼び出す可能性があります。インフラストラクチャの奥深くにネストされたシステムは、侵入検知がフラグを立てるたびに深刻な問題になる可能性があります。アクセス監視は、スタッフの配置が異なり、監視が異なり、対応が異なる場合があります。
私はおそらくさらにいくつかを夢見ることができます。しかし、BIGの勝利として思いつくのは、単一のユーザーとエンドマシンだけでなく、システム全体に焦点を当てている大規模な組織の視点からです。 、そしてリスク対コストのトレードの必要性。
攻撃者が他の種類のパスワードで保護された認証と同様に、パスワードを取得できた場合、これはあなたを保護しません。
それはニースの追加のチェックを追加しません、私は購入のようなものがなされるとき、私はこれらの種類のチェックが好きです。 PSN（PlayStation Network）には、これを他の人がストアから購入したり、他のアカウントを変更したりできないようにするオプションがあります。これはオプションですが、セキュリティを確保するための良い方法です。
重要な操作を承認するために追加のパスワードが必要になることは、通常のユーザー名とパスワードの資格情報に追加するのに最適です。あなたの恐れに基づいてリスクを分解しましょう。
- フィッシング-追加のパスワードは、メインのパスワードに沿ってフィッシングされない場合にのみ有効性を維持します。悲しいことに、1つのフィッシングページに30の運用コードすべてを挿入するユーザーは前代未聞ではありません。
- KeyloggingおよびMan in the Middle-アプリケーションが単一の追加パスワードを必要とする場合、攻撃者がそれを取得すると、アカウントが危険にさらされます。それ以外の場合、複数のパスワードがある場合、攻撃者は本当に効果的にするために十分な数のパスワードを取得する必要があります。
single追加のパスワードは、セキュリティを大幅に改善するものではありませんが、それでも歓迎すべき機能です。認証セキュリティ全体を高めるには、2番目の要素（トークンなど）がより優れたオプションです。トークンを追加できない場合は、multiple追加のパスワードが次善の策です。
まだ言及されていないので、これを追加します。
特別なアクションを実行するために再認証を要求する（典型的な例は、自分のパスワードの変更です） CSRF攻撃 から保護できます。
あなたが ここに私たちのチャットルーム でチャットしていて、私が次のような画像を投稿したとします。
<img src="http://example.com/change_password?new_password=1234" />
ブラウザはそのURLにアクセスし、セッションキーを含め、ブラウザが保持するCookieを上流に渡します。単純なGETリクエストがすべての場合example.com現在ログインしているユーザーのパスワードを変更する必要がある場合、パスワードは知らないうちに変更されます。チャットで壊れた画像が表示されるだけです。
次のような再認証を追加します。
http://example.com/change_password?current_password=abcd&new_password=1234
現在のパスワードを知らないとURLを生成できなくなります。
より高いセキュリティアクションでユーザー名とパスワードが異なり、アクションがまれである場合、使用される頻度が減るため、セカンダリクレデンシャルを攻撃する表面積が大幅に減少します。たとえば、メインログイン用にフィッシングサイトを設定する方がはるかに簡単ですが、安全なアクティビティのためにセカンダリログインに到達するまで、フィッシングサイトに確実に保持することははるかに複雑です。
まだ可能であることに注意してください、しかしそれは技術的なバーをかなり上げます。また、信頼できないシステムで安全なパスワードを使用しないようにするオプションもユーザーに提供します。たとえば、GMailにアクセスするために公共システムでGoogleアカウントにログインしたいとします。 Googleウォレットにセカンダリパスワードを設定して、GMailにアクセスしているマシンが危険にさらされた場合、攻撃者が私の財務情報ではなく自分の電子メールのみを入手できるといいのですが。