WebアプリケーションにHTTP認証を実装することの欠点は何ですか？

Question

利用可能な認証メカニズムにはさまざまなタイプがあることを知っています。その1つがHTTP認証です。他の方法と比較して、この方法を使用する際の危険は何ですか？

Xander · Accepted Answer

基本認証にはいくつかの欠点があります。その1つは、ユーザー名とパスワードが要求ごとに平文で渡されることです。これは明らかにHTTPでは安全ではありませんが、HTTPSでは脆弱ではありません。ただし、資格情報はすべてのリクエストで送信されるため、この制限がない他のメソッド（ダイジェストを含む）よりもさらに劣ります。主な理由は、最初のログインリクエストだけでなく、すべてのリクエストがクリアテキスト認証情報の盗難の標的になる可能性があるためです。ほとんどのシステムでは、ログイン後、攻撃者が取得しようとする可能性が最も高いのはセッションまたは認証トークンです。基本認証では、すべての要求がユーザーのパスワードを盗む機会です。これは理想的ではありません。

ダイジェスト認証は、クリアテキスト資格情報ではなく、ユーザー名、パスワード、ナンス（値など）を含むいくつかのさまざまなビットのMD5ダイジェストを送信するという点でやや優れています...キャプチャされたダイジェストからパスワードを抽出できません。

（任意の形式の）HTTP認証では、クライアントに依存して認証のユーザーエクスペリエンスを提供しますが、これには独自の問題がある可能性があるため、アプリケーションを使用する予定のクライアントで十分にテストする必要があります。たとえば過去には、たとえば、特定のブラウザがパスワードに特定の特殊文字が含まれているために認証に失敗するのを見てきました。アプリケーションベースの認証UXでは、これを制御できます。 HTTP authの場合、これは行いません。

別の攻撃（およびその非常にマイナーな攻撃）は、ユーザーが生成した外部でホストされたコンテンツをサイトに表示すると、非常に微妙な401のフィッシング攻撃に遭遇することです。ユーザーはクライアントのchrome for HTTP認証に慣れているため、サイトでわずかに異なるドメインの認証プロンプトが表示されても、必ずしも気付かない場合があります。アプリケーションによっては、まったく有効な脅威ではありませんが、HTTP認証ルートをたどった場合は、確かに検討する必要があります。

nobody · Answer

上記の他のポイントに加えて、HTTP基本認証（たとえば、フォームベースのログイン）のもう1つの大きな欠点は、「ログアウト」の概念がないことです。ユーザーが資格情報を入力すると、ブラウザはそれらを内部に保存し、後続のすべてのリクエストで送信します。つまり、セッションを終了するためのタイムアウトまたは「ログアウト」ボタン/リンクを設定することはできません。ユーザーが他の誰かが自分のセッションを使用する可能性を回避したい場合（たとえば、共有コンピューターの場合）、ユーザーはブラウザーを終了することを忘れないでください。

詳細については https://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication

user10008 · Answer

HTTPS経由の基本アクセス認証には、HTTP経由のダイジェストアクセス認証よりも明らかに有利な点があります。

ダイジェストアクセス認証を使用しても、パスワードを一意のソルト（レルム+ユーザー名）でハッシュして保存できますが、最初にこのソルトは推測可能であり（これにより、単一のユーザーや小さなグループに対する攻撃が容易になります）、次に使用できませんbcrypt、scryptまたはPBKDF2ハッシュ計算を困難にします。また、ハッシュを回復不可能な形式で保存することを選択した場合（これを行う必要があります！）、明確なユーザーパスワードを要求せずにレルムを変更することはできません。

SASL では、IETFによってダイジェストアクセス認証も履歴としてマークされていますです。 SASLの場合、代わりに使用することを推奨できる代替案（ [〜＃〜] scram [〜＃〜] 、たとえば、文字の正規化のためにSASLPrepを明確に要求する）がありました。 HTTPのSCRAMには残念ながらドラフトステータスに合格していません（SCRAMではユーザーのソルトも秘密ではないことに注意してください。攻撃者はログインメカニズムを悪用して、必要なすべてのユーザーのソルトを取得できます）。

ダイジェストアクセス認証は、誤った安心感を与える可能性があります。攻撃者が成功したログインをキャプチャできれば、パスワードに対してブルートフォース攻撃を仕掛けることができます。 username、realmおよびnonceはすべて、攻撃者にとって既知の値です。

暗号化されていないHTTPの使用は、ダイジェストアクセス認証の有無にかかわらず、MITMの影響を受けません。攻撃者はパスワードを取得できない可能性がありますが、セッションCookieを取得し、コンテンツを変更したり、ユーザーになりすますことができます。

ダイジェストアクセス認証では、ログインにのみ指定され、アカウントのセットアップには指定されません。「通常の方法」でアカウント設定を行う必要があります。コードがスマートで、内部ハッシュのみを送信してパスワードがクリアテキストで転送されないようにする場合でも、攻撃者がパスワードを変更して、パスワードを中継することができます。ただし、この重大な問題は登録時に1回だけ存在します。ユーザーが少数のマシンからのみログインすると想定すると、HTTPSに [〜＃〜] tack [〜＃〜] を使用して同様のセキュリティを実現できます。これにより、ユーザーのブラウザーは、サイトへの最初の接続で取得した証明書のみを承認できます。したがって、ダイジェストアクセス認証と同様に、可能なMITMに公開されたままの最初の接続のみが残ります。