ダイジェスト認証よりも安全なHTTP基本認証パスワードの保存
すでにSSLを使用している場合は、データベースに保存するときにパスワードを使用してbcryptを実行できるため、基本認証が適しています。ダイジェスト認証ではmd5。ご存知のように、データベースの盗難の場合、md5はbcryptよりも速く「クラック」される可能性があります。
私の質問は、SSLが存在し、bcryptダイジェスト認証パスワードを使用できないという事実を考えると、なぜそれでも基本認証でそれを使用したいのですか？または、SSLがある場合は、以前のBasic Authです。
ところでこれはREST APIサーバー用です
あなたの仮定は正しいです。 HTTPSを適切に使用している限り、基本的な認証方法が適しています。 HTTPDのセキュリティモデルに縛られるのではなく、すべての暗号化ポリシーとアクセスポリシーをwebappに実装できます。
SSLを使用している場合、選択できるのは基本認証とダイジェスト認証だけではありません。 SSLがない場合は、基本認証よりもダイジェスト認証の方が適していますが、中間者攻撃に対しては少し脆弱です。ただし、基本認証よりも複雑になります。
ただし、いくつかの理由で基本的な認証は避けます。
- ログインするための見苦しいインターフェイス（保護されたページに初めてアクセスしたときのほとんど構成できないポップアップアラート）と、ページのどこかにあるオプションのログインフォーム。
- 不正なログイン試行では、401-許可されていないメッセージは、カスタマイズ可能な間違ったパスワード画面よりも悪いです。 CAPTCHAを追加したり、メールアドレスに基づいてユーザー名を思い出させたり、失われたパスワードをリセットしたり、新しいアカウントを作成したりするリンクが含まれている可能性があります。
- 通常、ブラウザを閉じずに基本認証ログインの ログアウト を行うことはできません。
このため、パスワードを保存するために強力なハッシュ（bcryptなど）を使用するという理由から、Cookieベースのセッション（SSL経由）を使用することをお勧めします。
ダイジェストプロトコルの仕様 の日付は1999年でした。これは、SSLがまだ一般的に使用するには高すぎるツールと見なされていた時期でした。 RFCは、この段落から始まります。これにより、コンテキストが提供されます。
「HTTP/1.0」には、基本アクセス認証スキームの仕様が含まれています。ユーザー名とパスワードはクリアテキストとしてネットワーク経由で渡されるため、このスキームはユーザー認証の安全な方法とは見なされません（SSL 5 などの外部の安全なシステムと組み合わせて使用する場合を除く）。
これは、ドキュメント全体でSSLへの唯一の参照です。これは物事を明確にします：Digestは、Basicが行うように、パスワードを平文で送信するという明白な問題に対処しようとするように設計されましたSSLで使用しない場合。ただし、攻撃者は前世紀から少し進歩したため、SSLを使用しないことが大きな問題であることはわかっています。攻撃者は受動的な盗聴に満足せず、実際に接続をハイジャックして man-in-the-ミドルアタック 。その場合、ダイジェストの量を節約することはできません。
DigestがBasicよりも優れている点の1つは、サーバーが悪意のある場合にサーバー自体にもパスワードを公開しないことです。つまり、攻撃者が制御する偽のサーバーと通信しているということです。ダイジェストはMitMから保護しないため、その状況ではすでに運命を破られていますが、locallyのみ運命づけられています：攻撃者はデータを確認し、リクエストしても、彼はあなたのパスワードを知らないので、後で一人で戻ってくることはできません。いくつかの点で、この利点は非常に小さくなります。
偽のサーバーでのダイジェストは攻撃者に未加工のパスワードを明かしませんが、それでも 辞書攻撃 を実行するのに十分であり、MD5ハッシュのカップルであるため非常に効率的です（何もない） bcryptとリモートで比較することもできます）。
固有のMitM攻撃は適切なデータ整合性チェックを要求するほど深刻であり、これはSSLを意味します（完全なサーバー証明書検証を使用してください！）。 MitMが打ち負かされている場合、then Basicに対するDigestの利点は、朝の太陽の露として蒸発します。
一方で、既に述べたように、ダイジェストを使用すると、サーバーはパスワード自体（暗号化されている可能性がありますが、リバーシブルな方法で）を保存する必要があり、であることを意味しますはダイジェスト認証の大きな欠点です。
すべての世界で最高のものを使用するには、 TLS with SRP を使用します。これは、パスワードベースのキックアスキー交換を使用したSSL/TLSです。ここで、
- サーバーはパスワードを保存する必要はなく、検証トークン（一種のハッシュ）のみを保存します。
- 証明書はまったくありません。
- 認証は相互に行われ、パスワードに対して相対的です。
- サーバー、クライアント、またはその両方になりすました攻撃者でさえ、オフライン辞書攻撃を実行するのに十分なデータを知ることができません。
唯一の「マイナー」な問題は、TLS + SRPが（まだ）広くサポートされていないことです。 GnuTLS でできます。今後とも一層のご支援を賜りますようお願い申し上げます。一方、SSL内で基本認証を使用し、サーバーの証明書を完全に検証することを忘れないでください。また、bcryptを使用して、サーバー側にパスワードハッシュを保存してください。
ダイジェスト認証用のパスワードの保存は、実際にはあなたが提案するよりも悪いです。攻撃者がパスワードハッシュを取得した場合、これを使用してダイジェスト認証を自分で実行できます。クラッキングは必要ありません。他の人が述べたように、SSLが普及する前に、ダイジェスト認証がその場所にありました。
SSL経由の基本認証は基本的に問題ありません。ただし、セッションベースのソリューションを検討することもできます。すべてのリクエストでパスワードを送信するのではなく、一度パスワードを送信してセッションをセットアップし、次に各リクエストでセッションIDを送信します。パスワードが最も秘密にされているものであることを考えると、これにより、送信されるパスワードの量が最小限に抑えられます。
別の投稿者はSRPについて言及しており、SRPにはさまざまなセキュリティ上の利点がありますが、広く実装されているわけではないため、ほとんどのWebアプリにとってスターターではありません。