tcp - TCP クライアント サーバー アーキテクチャでの単純なパスワード認証

Question

おはようございます。安全なパスワード認証を行う方法（n回ハッシュする、saltを使用するなど）について読んでいますが（ほとんどはスタックオーバーフローにあります）、実際にTCPクライアントにどのように実装するかは疑問です-サーバー アーキテクチャ。

私はすでに必要なメソッドを実装してテストしました (jasypt digester を使用) が、どこでハッシュとその検証を行うべきか疑問です。

私が読んだことに関しては、パスワードを送信しないことをお勧めします。この場合、サーバーはハッシュ化されたパスワードを送信し、クライアントはユーザーが入力したパスワードでそれをテストします。その後、認証が成功したかどうかをサーバーに伝える必要があります。サーバーが読み取っているソケットに接続して「認証OK」を送信した人は誰でもログオンするため、これは機能しません。

もう 1 つのオプションは、パスワードのハッシュをサーバーに送信することです。この場合、「攻撃者」は認証のために同じハッシュを送信する必要があるため、ハッシュによる実際の利点は見られません。

おそらく詳細がわからないので、誰か教えてもらえますか？

Answer 1

あなたの質問に対する簡単な答えは、間違いなくパスワードのハッシュを永続的に保存する側にあります。

長い答え: パスワードのハッシュは、パスワード ストレージ (データベースなど) への読み取り専用アクセス権を持つ攻撃者がより高いレベルにエスカレートするのを防ぎ、実際の秘密のパスワードを知ることを防ぐことしかできません。サービス (こことここで適切な説明)。そのため、ストレージ側で検証を行う必要があります（そうしないと、前述のように、攻撃者は「検証OK」メッセージを送信するだけなので、それだけです）。

ただし、本当に安全な接続を実装したい場合は、単純なパスワードのハッシュでは不十分です (前述のように、攻撃者は TCP トラフィックを盗聴してハッシュを明らかにする可能性があります)。この目的のためには、安全な接続を確立する必要がありますが、これは単にパスワードをハッシュするよりもはるかに困難です (Web の世界では、パスを入力するページは常に HTTPS 経由で提供される必要があります)。これには SSL/TLS を使用する必要がありますが、これらのプロトコルは TCP の上にあるため、別のソリューションが必要になる場合があります (一般に、信頼できる証明書ソースが必要であり、サーバー証明書を検証する必要があり、共通の証明書を生成する必要があります)。対称暗号化キーを使用してから、送信するすべてのデータを暗号化します)。安全な暗号化された接続を確立した後は、暗号化されたデータを傍受しても意味がなく、攻撃者はパスワードのハッシュを知ることはありません。