プレーンテキストのパスワードをSQL Serverデータベースに送信することはセキュリティ上のリスクですか？
プレーンテキストのパスワードを取得するストアドプロシージャを含むデータベースがあります。それらをハッシュし、DBに挿入します。
攻撃者がDB接続にアクセスできる場合、SQL Serverプロファイラを使用してDBへの呼び出しを傍受し、渡されたプレーンテキストのパスワードを確認することが可能です。 SSLがDBへのネットワークトラフィックを暗号化することを理解していますが、攻撃者がストアドプロシージャのパラメータを盗聴するのを防ぐことはできません。
これらのパスワードを暗号化せずに送信することでセキュリティ上のリスクはありますか？
SQL Server アプリケーションとデータベース間の接続を暗号化するオプションがあります 。信頼できない環境でSQLサーバーを運用する場合は、有効にすることをお勧めします。その場合、データベース管理者を信頼している限り、データベースに送信する前にパスワードをハッシュする必要はありません。
さらに、SQLサーバーのほとんどの展開では、DMZにアプリケーションサーバーがあり、SQLサーバーがLANにあります。つまり、信頼できる環境で動作します。非常に高いセキュリティ標準がない限り、暗号化を行わないことは、大きなセキュリティリスクにはなりません。
誰も信じない。安全な文字列を使用してプレーンテキストのパスワードを保持し、すぐにハッシュします。システムが安全であることを期待できる時代は終わりました。そうではない。決められた攻撃者がシステムにアクセスできるようになるまでの時間とお金の問題です。
トラフィックがSSL/TLSで暗号化されている場合でも、いくつかのシナリオが考えられ、それぞれがパスワードの漏洩につながります。たとえば、
- 政府はSSLトラフィックをキャプチャし、秘密鍵がそれを復号化することを「適切に要求」します。すべてプライベートネットワークですか？オフサイトレプリケーションが構成されていませんか？
- 組織は、中間者SSL復号化を実行するハードウェアをインストールして、ネットワークを通過するSSLトラフィックを盗聴します。突然、より多くの人々、ハードウェア、およびソフトウェアが関与します-あなたはそれらを信頼しますか？インストールされていないか、まだインストールされていない可能性がありますか？
- SSL秘密鍵を保持するサーバーがハッキングされ、鍵が漏洩します。個人的に。静かに。
- 不満を持った従業員は、秘密鍵をコピーして競合他社に販売することで報酬を得ます
はい、ここにはさまざまなリスクまたはリスクの増加があります。
何よりもまず、DBAが信頼できるかどうかにかかわらず、DBAは監査人（または規制調査官、または弁護士）に正直に、いいえ、ユーザーXを偽装することは不可能であることを伝えることができるはずです。ユーザーXのパスワードを確認したい場合でも、サーバーXの秘密キーとパケットスニファのコピーを使用した場合でも同様です。
次に、サーバーでパスワードをハッシュする場合は、次のことを行う必要があります。
- 正規の パスワードを安全にハッシュする方法は？ 答えは、Thomas Porninによるもので、「BCrypt、SCrypt、またはPBDF2を使用する」に要約されます。
- ピーク負荷で処理できる限り多くの反復を使用します。
- 出力長は、基本ハッシュプリミティブの出力長以下です。
- これはSQL Serverなので、私自身の 純粋なT-SQL PBKDF2実装 回答を参照してください。
- 実際の実装、特にoclHashcatのような攻撃実装に比べると、恐ろしく遅いことに注意してください。
- 現在の単一マシン、マルチGPUオフライン攻撃速度については、 oclHashcat を参照してください。これは、攻撃者、研究者、およびクラッキング競技の競技者が、フロントエンドの脆弱性からハッシュ化されたパスワードのコピーを取得した後、またはデータベースのバックアップが保存されたラップトップを使用するときに使用します（または、ここでお気に入りのシナリオを選択してください）。
- 上記に基づいて、アプリケーションが何であれ、同じ計算時間でSQL Serverデータベースよりもはるかに多くのBCrypt、SCrypt、またはPBKDF2を使用してパスワードをハッシュできることを理解してください。
- sQL Serverのパワーを追加するよりも、スケールアウトしてフロントエンドのパワーを追加する方が、ほとんど常に簡単で安価です。
さまざまなPBKDF2実装が my Githubリポジトリ にあることに注意してください。これには、Jitherの作業に基づいた C＃バリアント が含まれ、JitherはMIT =ライセンス。
したがって、それは環境の信頼価値に依存します。信頼度がまったくない場合は、暗号化が有効な場合があります。さらに、構成の分岐が少ないのは、おそらくSQL接続を必要とするホストのみに制限することですが、アクセスできるように開く理由はさまざまです。
[〜＃〜] tldr [〜＃〜]：DBへのネットワーク接続が安全であり、ソルトハッシュがテーブルに格納されている限り、プレーンテキストでストアドプロシージャを呼び出すパスワードで結構です。ストアドプロシージャ呼び出しのトレースを取得できる種類の不正アクセスからデータベースを保護するために、時間と労力を費やした方がいいと思います。
まず、問題のシナリオは、攻撃者がストアドプロシージャに渡されたパラメーター値（1つはプレーンテキストパスワード）を確認してプレーンテキストパスワードを回復し、そのパスワードを使用してアプリケーションのユーザーアカウントを侵害する可能性があることです。
それが正しい場合、私が見ている唯一の技術的な解決策は、ストアドプロシージャのスコープ内でPKスキームを実装することです。これにより、ストアドプロシージャの公開鍵、ストアドプロシージャに渡される暗号文、およびパラメータ値は、使用される前に、ストアドプロシージャ自体によって秘密鍵で復号化されます。 （または、TLS自体のように、他のストアドプロシージャを使用してDiffie-Hellman交換をネゴシエートし、セッションキーを使用することもできます）。これは非常に重いリフトになります。そして今、その秘密鍵を保護する必要があります。
しかし、あなたが本当に身を守ろうとしていることを考えてください。このシナリオでは、攻撃者はストアドプロシージャの呼び出しを読み取り、渡された値を取得できます。この特権を持つユーザーは、使用する秘密キーへの読み取りアクセス権、またはテーブルへの選択/挿入/更新アクセス権を持っていますか？その場合、ストアドプロシージャレベルでPKIを実装する労力を費やしても、その努力はすぐに打ち負かされます。
もちろん、特にソルトを使用してパスワードをハッシュし、そのハッシュ値をストアドプロシージャに渡すという考えに具体的に対応させてください。これを行うと、ハッシュされた値がパスワードになります。格納されたprocパラメーターを本当に読み取ることができる場合、攻撃者がしなければならないことは、システムを危険にさらすためにそれらを見るのとまったく同じようにそれらのパラメーターを繰り返すことです。彼は実際にハッシュを逆にして「プレーンな」パスワードが何であるかを知る必要はありません。ハッシュ値は平文パスワードです。したがって、このスキームは効果がありません。