Apacheを使用すると、基本アクセス認証を使用してユーザーに名前/パスワードの入力を求め、何らかの方法でそれらの資格情報を使用してそのユーザーにアクセスを許可するページを設定するのは非常に簡単です。
クライアントとサーバー間の接続が安全であると仮定すると、これは安全ですか?
Apacheを使用すると、基本アクセス認証を使用してユーザーに名前/パスワードの入力を求め、何らかの方法でそれらの資格情報を使用してそのユーザーにアクセスを許可するページを設定するのは非常に簡単です。
クライアントとサーバー間の接続が安全であると仮定すると、これは安全ですか?
基本認証に関する懸念は、クレデンシャルがクリアテキストとして送信され、パケットスニッフィングに対して脆弱であるということです。その接続がTLS / SSLを使用して保護されている場合、暗号化を使用する他の方法と同じくらい安全です。
これは古いスレッドであり、私は最高の投票/選択された答えが正しいとは思わない。
@Nateowamiが指摘しているように、セキュリティスタック交換スレッドは基本認証に関する多くの問題の概要を示しています。
もう1つ指摘したいのは、パスワードの検証を正しく行っている場合、基本認証によってサーバーがサービス拒否に対してより脆弱になるということです。なんで?昔は、パスワードの検証にはソルトハッシュで十分であると考えられていました。 もはやそうではありません。今日では、データベースが公開された場合に(これは非常に頻繁に発生します)、ブルートフォースパスワードを防ぐために低速の機能が必要であると言われています。基本認証を使用している場合は、すべてのAPI呼び出しでこれらの低速な計算をサーバーに強制することになり、サーバーに大きな負担がかかります。この古い認証メカニズムを使用するだけで、DoSに対する脆弱性が高まります。
より一般的には、パスワードはセッションよりも価値があります。ユーザーパスワードが侵害されると、パスワードの再利用によってユーザーがアクセスする他のシステムが乗っ取られる可能性は言うまでもなく、ユーザーのアカウントが無期限に乗っ取られる可能性があります。一方、ユーザーセッションは時間制限があり、単一のシステムに限定されます。したがって、多層防御の問題として、パスワードなどの価値の高いデータは、必要がない限り繰り返し使用しないでください。基本認証は時代遅れのテクノロジーであり、非推奨にする必要があります。
ほとんどのサイトが基本認証よりもOAuthを好む理由は、基本認証ではユーザーがサードパーティのアプリにパスワードを入力する必要があるためです。このサードパーティアプリは、パスワードをクリアテキストで保存する必要があります。アクセスを取り消す唯一の方法は、ユーザーがパスワードを変更することです。ただし、これにより、すべてのサードパーティアプリへのアクセスが取り消されます。したがって、ここで問題が何であるかを確認できます。
一方、OAuthにはWebフレームが必要です。ユーザーは、この特定のサイト自体のログインページでログイン情報を入力します。次に、サイトは、アプリが将来自分自身を認証するために使用できるアクセストークンを生成します。長所:
スニッフィング可能な環境でのhttpを介した基本認証は、パスワードを簡単に元に戻して再利用できるため、認証なしのようなものです。sslを介したクレジットカードの安全性が「少し」高いという上記の卑劣なコメントに応えて、問題は、基本認証が同じチャネルで何度も使用されることです。パスワードを一度侵害すると、単一のデータ属性だけでなく、そのチャネルを介したすべてのトランザクションのセキュリティが侵害されます。
同じクレジットカード番号をWebセッションで何度も渡すことがわかっている場合は、SSLに依存するだけでなく、クレジットカード番号が使用される可能性があるため、他の制御方法を考え出すことをお勧めします。それは頻繁に危険にさらされるでしょう...最終的には。
でパスワードを生成する場合は、にhtpasswd切り替えることを検討してhtdigestください。
ダイジェスト認証は、暗号化されていない接続でも安全であり、セットアップも同様に簡単です。確かに、SSLを使用する場合は基本認証で問題ありませんが、ダイジェスト認証を同じように簡単に使用できるのに、なぜチャンスを利用するのでしょうか。
名前自体が示すように、「基本認証」は単なる基本的なセキュリティメカニズムです。心配のないセキュリティを提供するためにそれに依存しないでください。
その上にSSLを使用すると、少し安全になりますが、より優れたメカニズムがあります。