RFC 7616（HTTP Digest Auth）の採用がない理由
RFC 2617の後継により、MD5ではなくSHA-256のサポートが追加され、qopフィールドが必須になり、認証全体がより安全になります。
ただし、主要なブラウザー/クライアント（Edge、FF、Chrome、Opera、curl）ではサポートされていません。
それは私にとって少し奇妙なことです。というのは、通常、より良いセキュリティ標準に関しては、ブラウザーベンダーは非常に積極的だからです。
どうしてこれなの？ここで何か不足していますか？
ほとんどのサイトでは、基本認証やMD5ベースのダイジェスト認証などのHTTP認証メカニズムを使用していません。これらのメカニズムは、提供する機能が非常に制限されているためです。これらの認証メカニズムを使用してログアウトすることもできません。
ただし、HTTP認証を使用するいくつかのサイトでも、通常、ダイジェスト認証ではなくHTTPSよりも基本認証を優先します。最後のサイトでは、パスワードをプレーンテキストまたは同等のものとしてサーバーに保存する必要があるため、もちろんセキュリティの観点からは好ましくありません。
したがって、ダイジェスト認証が他の認証フォームに対して持つ唯一の利点は、暗号化されていない接続で使用される場合です。他のすべての場合では、他の確立された認証方法よりも劣ります。しかし、安全でない接続を介したあらゆる種類のログインは、とにかく今日では悪いと考えられています。したがって、基本的な問題、つまり必要なプレーンテキスト（または同等のプレーンテキスト）のパスワードの保存に対処することなく、すでに悪い認証メカニズムを少し改善する必要はありません。
それとは別に、衝突攻撃やプリイメージ攻撃に対する悪い耐性などのMD5の弱点は、ダイジェスト認証での使用には実際には影響しません。つまり、適切なランダムサーバー定義ノンスと一緒に使用する場合、このユースケースには依然として適しています。
それは素晴らしい発見です、私はSHAハッシュを使用したHTTPダイジェストを認識していませんでした
HTTPダイジェストは、次の理由で優れています。
- セットアップは簡単です[ 1 ]
- ハッシュ方式は公式に文書化されています
- ユーザーのパスワードを保存する必要はなく、 'H（A1）' []を保存するだけです。
- したがって、それを台無しにすることはできません
HTTPS +基本認証はそれほど優れていません：
- 適切な設定は難しく、費用がかかります[ 2 ]
- sSLプロバイダーに頼らざるを得ない初心者の参入障壁
- 一元化され、不正なCAによる検出不能なスヌーピングを可能にする
- 誤った安心感を与える
- 資格情報を安全に保存する方法に関する一般的なガイダンスはありません
SSL証明書の発行が一元化されているため、潜在的な理由は、Webの制御を統合したいということです。
最高のセキュリティが必要な場合は、HTTPSとHTTPダイジェストを同時に使用してください。また、ベンダーに最新のRFCを実装することを推奨します。