HTTPS を使用している場合でも、クライアント側でハッシュ (パスワード + ソルト) メソッドを使用してパスワードをハッシュする必要がありますか? または、組み込み関数を使用して SQL SERVER 2008 R2 に到着したときにハッシュする必要がありますか? ありがとうございました。
4 に答える
なぜクライアント側でハッシュするのですか? これは Javascript で書かれたシングル ページ アプリですか? それでも、データベースに接続するサーバー側の言語が必要です (ASP.NET? PHP?)。サーバー側でソルティングとハッシュを行います。クライアント側は私には悪臭がします...何らかの理由で、クライアント側でロジックとランダム生成が発生している場合、ソルティング/ハッシュ手順は攻撃を受けやすいようです。特定の攻撃を指摘することはできませんが、クライアントにプッシュするのは不必要なことのように思えます (おそらく SSL を取得できない場合を除きます)。
サーバー側の言語で行うか、データベースで直接行うかは特に重要ではありません。私は、コードで計算を行い、最終的なハッシュを SQL に送信することを好みます。組み込みの SQL Server 関数を使用するのは煩わしく、バージョン間で問題が発生します。コードは Microsoft の世界に永遠に閉じ込められてしまいます。
TL;DRクライアントではなく、データベースで直接ではなく、サーバー側で行います。送信前にプレーンテキストのパスワードを回線上で暗号化する場合は、HTTPS が必要です (間違いなく必要です)。
私の知る限り、パスワードのソルトは、誰かがセキュリティ違反を発見し、データベースからパスワードのリストを盗んだ場合に (また) 役立ちます。ソルトされている場合、レインボー テーブルなどの方法でクリアなパスワードを見つけることはほとんど不可能です。そうしないと、ひび割れする可能性があります。
HTTPS が壊れていると仮定すると、多くのセキュリティ上の結果が生じます。基本的にすべてが崩壊します。
これをしないでください。時間の無駄です。ユーザーが気にする機能を開発するなど、より良い方法で使用してください。
サーバーで標準のハッシュとソルトを行うだけで、新しいセキュリティスキームを発明しないようにしてください.
SSL を使用している場合、クライアントとサーバー間の通信は暗号化されます。
質問の後半は少しトリッキーです。SQL Server には暗号化が組み込まれていますが、データベースにアクセスできる人なら誰でも使用できるという問題があります。
コードを暗号化し、暗号化されたバージョンをデータベースに送信すると、データベースが侵害された場合に保護されます。データベースに侵入した可能性がありますが、データを復号化することはできません.
したがって、私の答えは...クライアント側でもデータベースでもありません-2つの間のコードで暗号化とソルトを行います!