HTTPS Webサイトにパスワードの暗号化は必要ですか？
サーバーに送信する前にパスワードをAES暗号化するように要求されたので、私は少し混乱しています。 Webサイト全体がHTTPSを介してサーバーと通信し、安全なCookieを使用します。
AFAIK、HTTPSはSSL 128ビット暗号化（256ビットである可能性がありますが、不明です）を使用し、これはトランスポート層で発生します。クライアントが危険にさらされない限り、プレゼンテーション層またはアプリケーション層での攻撃は不可能だと思います。したがって、SSLが暗号化されると、情報は安全にサーバーに到達すると思います。
それでも、サーバーに送信する前に、クライアント側でパスワードなどの貴重な情報を暗号化する必要がありますか？
HTTPS経由で送信する前にパスワードを暗号化しても、セキュリティは強化されません。
考慮してください：パスワードは送信者によってどのように暗号化され、受信者によってどのように復号化されますか？
対称アルゴリズムを使用する場合、どのようにしてキーをネゴシエートしましたか？キーがクライアントに組み込まれている場合、クライアントをリバースエンジニアリングする人は誰でもそのキーにアクセスできます。
非対称（つまり、公開鍵）アルゴリズムを使用する場合、鍵を暗号化するか、対称アルゴリズムの鍵をネゴシエートする... SSL/TLSが行うのと同じことを行っているだけです。
サーバーとクライアントの両方が使用できる最長のキーを使用して、TLSの利用可能な最高バージョンを使用するだけです。
完全を期すために：HTTPSはSSL/TLSを使用します。もともとは「HTTP over SSL」を意味していました。現在、SSLは脆弱であることが判明しているため、その後続のTLSを使用する必要があります。
サーバーで、（パスワード+ソルト値）のハッシュを作成します。 Stack Overflowの フォームベースのWebサイト認証の明確なガイド には、安全なWebベースの認証を行う方法に関する多くの情報があります。
一般化されたFredericsは少し答えますが、ソリューションが資格情報データフローでエンドツーエンドのHTTPSを使用しない場合、クライアントでパスワードの暗号化が必要になる可能性があります。
エンドツーエンドのHTTPSを使用しないいくつかの理由は次のとおりです。
- HTTPSは、ロードバランサーやリバースプロキシなどの一部のエッジサーバーで終端され、エッジサーバーと最終的な送信先サーバーの間のプレーンHTTPが使用されます（フレデリックの状況はこの別の例です）。
- 要求は、負荷平準化のためのメッセージキューなど、フローのある時点で静止しています。
この場合、説明したようにメッセージレベルの暗号化を使用することは理にかなっています。
パスワードのエンドツーエンドの暗号化の概念を販売したクライアントからのそのような要求を見てきました。
セットアップは次のとおりです。パスワードやその他の資格情報を検証する専用サーバーがあり、それ以外は何もありません。アプリケーションをホストするサーバーは、その専用サーバーに認証を委任し、暗号化された資格情報を渡します。
HTTPS暗号化はアプリケーションサーバーで停止しますが、暗号化された資格情報は、認証サーバーに到達するまで保護されます。
今はそれがまったく意味をなすかどうかはわかりませんが、前述したように、そのようなことを要求するクライアントに会いました。
通常、ソフトウェアアーキテクチャは、フロントエンド、ミドルウェア（ビジネスロジック用）、およびバックエンド（データベースなど）で構成され、これらすべてのコンポーネントがパスワードを処理します。これらのコンポーネントのいずれかを侵害した攻撃者は、パスワードを傍受することができます。
緩和策の1つは、パスワードを暗号化することです。公開鍵暗号化を使用すると、次のシナリオが可能になります。
- バックエンドは公開鍵と秘密鍵を作成します
- 公開鍵は、ユーザーがパスワードを入力するフォームに含まれます
- ユーザーがフォームを送信すると、JavaScriptコードは公開鍵を使用してパスワードを暗号化します
- フロントエンドは暗号化されたパスワードを受け取り、それをバックエンドに送信するミドルウェアに送信します
- バックエンドだけがそれを復号化できます
したがって、フロントエンドまたはミドルウェアを侵害した攻撃者は、平文のパスワードを見ることができません。