私はJavaEEアプリケーションを作成しています。これにより、新しいユーザーは自分で登録してからインターネット経由でログインできます。クレデンシャルとデータベースを保存しています。
さて、それを行うにはいくつかの方法があります、例えば：
いくつかの記事を読んで、Secure Remote Password Protocol（SRP）が進むべき道のようです。
しかし、他のいくつかの記事を読むと、これはTLS / SSL自体など、一部の低レベルのレイヤーでのみ使用されているようです。
それでも、アプリケーションレベルでSecure RemotePasswordProtocolを使用することをお勧めします。
これは正しいです？または、これがアプリケーションレベルで必要とされない理由はいくつかありますか？
考慮すべきトレードオフがいくつかあります。まず、クライアントがサーバーの SSL 証明書を適切に検証している場合に限り、SSL リンクを介して生のパスワードを送信することは十分に安全です。ただし、適切な SSL 証明書の検証が実行されたとしても、未加工のパスワードをサーバーに送信することは完全に理想的ではありません。サーバーがハッキングされると、ユーザーのパスワードが公開される可能性があります。パスワードは他の場所で頻繁に再利用されるため、この種の公開は深刻な影響を与える可能性があります。
SRP の利点は、これらの問題の両方を回避できることです。ユーザーのパスワードがマシンの外に出ることはなく、適切な SSL 証明書の検証は必要ありません。SRP の相互認証プロパティにより、SSL 証明書は冗長になります。実際、一部のアプリケーションはこれを利用して、適切な SSL 証明書管理に伴う頭痛の種を完全に回避しています。サーバー上で匿名の自己署名証明書をデータ暗号化の目的でのみ使用し、認証はアプリケーションレベルの SRP に任せます。
具体的には、あなたの質問に対して、低レベルとアプリケーションレベルの使用に対する SRP の適用可能性は、実際にはアプリケーションに依存すると思います。それは両方の分野でうまく機能しますが、実際に最もよく使用される場所は、作業している特定の設計上の制約のセットに帰着します。
SRP は無料であるため、TLS/SSL 経由で SRP を使用する必要があります。
ユーザーがネットワーク経由で SRP パスワード検証ツールを登録またはリセットする場合は、接続を暗号化する必要があります。検証者は、オフラインのブルート フォース攻撃を受けないように秘密にしておく必要があるためです。TLS/SSL/HTTPS はこれに最適です。それらは十分に確立されており、すべてのデータを暗号化し、ブラウザがなりすましサーバーと通信しないようにするサーバー証明書の保護を提供します.
SRP は、ユーザーが認証に使用するパスワードがネットワークを通過しないことを意味します。ユーザーが企業の Web プロキシ経由で会社が提供するコンピュータを使用している場合、HTTPS が復号化されて監視される可能性があります。Hearbleed バグは、適切に構成された HTTPS に問題がある可能性があることも示しています。ラップトップ メーカーは、Superfishで販売するラップトップの HTTPS を故意に侵害して、暗号化されたページに広告を挿入できるようにしました。フランス政府によって展開されたルート証明書が侵害されている可能性があります従業員を詮索する。完璧な暗号化設定を行ったとしても、アプリケーションが誤ってパスワードをログに漏らす可能性があります。一方、SRP はランダム化された入力を使用して 1 回限りのパスワード証明を行います。そのため、SRP はパスワードがクライアント マシンから出ないように保護します。これは、2 台のマシンの (漏洩する可能性のある) メモリにパスワードを入れるよりも本質的に安全です。
つまり、SRP と HTTPS/TLS/SSL の両方を使用する必要があります。