BCryptを使用してクライアント/サーバー構成で機密データを送信する
TCPを使用してサーバー/クライアント構成で機密データ（パスワード）を送信する必要があるソフトウェアを開発しています。すべてのデータはAESを使用して暗号化されます（対称鍵は各交換に固有であり、PGP/RSAを使用して送信されます。この部分は安全です）。
セキュリティを強化するために、機密データを送信する前にハッシュ化してください。パスワードはsqlデータベースに保存されます。 SHA-256/512を使用すると不思議に機能しますが、データベースが盗まれた場合に備えて、堅牢なBCryptを使用したいと思います。ただし、BCryptは一致を検証するためにプレーンパスワードを必要とし、チェックはサーバー側で行われるため、プレーンテキストでパスワードを送信する必要があります（ただし、AES暗号化されます）。私はまた、sha-256/sha-512を使用して約1000回のパスワードのハッシュ反復を行うことを考えましたが、それが本当に最良のアイデアであるかどうかはわかりません。
完全に安全な送信とパスワードの完全に安全な保管を確実にする最良の方法は何でしょうか？
適切なトランスポートレベルのセキュリティ（つまり、TLS接続）がなければ、中間者攻撃からアプリケーションを保護することはできません。 bcryptなどを使用してパスワードを転送しても、状況は改善されません。暗号化と認証の両方を使用して、クライアントとサーバー間に安全な接続が必要です。
これができたら、安全な接続を介してパスワードを送信するのと同じように問題はありません。
もう1つの攻撃対象はデータベースの侵害です。この場合、適切な解決策は、プレーンテキストのパスワードではなく、暗号化されたパスワードをデータベースに保存することです。
1つの可能性は、クライアントとサーバーの両方でパスワードをハッシュすることです。
- クライアントはbcrypt（password）をサーバーに送信します。
- サーバーコンピュータはbcrypt（bcrypt（password））を実行し、データベースに対してパスワードをチェックします。
したがって、データベース内のパスワードは2回暗号化されます。このように、プレーンテキストのパスワードは傍受に対して安全であり、認証トークンはデータベースの侵害に対して安全です。
あなたはクライアントにソルトを送信してみて、それを使ってパスワードをBCryptすることができます。または、クライアントにパスワードをBCryptしてもらいます。
次に、サーバーはパスワードのBCryptを実行し、パスワードが一致することを確認します。
[〜＃〜]どうやら[〜＃〜]これはより安全です-それはそうではありませんが。防御している攻撃（通過する秘密のキャプチャ）が成功した場合、攻撃者はBCrypt（pwd）を所持することになります。これにより、攻撃者はアクセス権を取得し、正当なクライアントになりすますことができます。システムbcryptハッシュのみのパスワードの知識は必要なくなりました。 リプレイ攻撃にさらされます。
change saltを実行し、キャプチャの成功後にリプレイアタックを防ぐには、プレーンテキストのパスワードを保存する必要があります。
あなたができることは次のとおりです：-サーバーにソルトS1でbcryptされたパスワードを記憶し、各パスワードには独自のソルトがあります-S1とSXを含むチャレンジをクライアントに送信します（毎回ランダムに生成されます）。これには、ユーザーが既にサーバーに送信されている必要があります。未知のユーザーがソルトを受け取りますユーザー名でシークレットをハッシュすることによって作成された。 -クライアントは平文のパスワードを持ち、Bcrypt（SX、Bcrypt（S1、password））を送信します
- bcrypt（S1、password）を持っているため、パスワードを明かすことができない
- ワイヤーはBcrypt（SX、hash）を認識しているため、ハッシュを明らかにすることができません
- 各段階でCPUハードbcryptを取得します。