機密データとハッシュパスワードの保存を分離するにはどうすればよいですか？
シナリオ：認証システム（クラシック）を備えたWebアプリケーションがあります。アプリケーションは基本的に、機密データを保持するDB（MongoDB）へのインターフェースです。保存したパスワードを適切にハッシュ化します。
ハッシュにより、攻撃者がすでにDBへのアクセス権を取得しているときにパスワードを知ることができないと想定します。
質問1：すべてのデータを1つのDBに保存するときにパスワードをハッシュするポイントはありますか？
質問2：機密データと資格情報を分離する正しい方法は何ですか？別のデータベース？ Mongoの組み込み認証システムをユーザー認証に使用しているのではないでしょうか？
について質問1：
一般的には、そうです。潜在的な将来の攻撃の詳細を知らないので、あなたの仕事は、脆弱性の実際の悪用を可能な限り困難にすることです。
ご存知のように、情報セキュリティの使命は3つの値を提供することです：confidentiality、integrity、およびavailability。ハッカーがDBの完全なコピーを取得したと仮定しましょう（confidentialityに影響します）。ユーザーとしてログインできるため、integrity（ユーザーのデータを変更し、ユーザーに代わってアクションを実行することにより）を引き継ぐことができ、availability（アクセスを回復するために使用できるメールを変更するなど。
質問2に切り替える前。私の知る限り、MongoDBにはコレクションレベルのアクセス制御もあるため、攻撃の伝播を制限するのに役立ちます。また、DB内の機密エントリを暗号化して、不正な読み取り専用アクセスがそれほど重要にならないようにすることもできます。
質問2について：リスク分析から導き出される多くの要因に基づいてセキュリティの決定を行う必要があるため、正しい方法はありません。ユーザーの資格情報を別のDBに保存したり、別の認証サーバーを作成したり、サードパーティの認証サービス（OAuth）を使用したりできます。
ここでの主な目標は、これらのセキュリティ制御の実装、サポートのコストと、データ侵害の場合に発生する可能性のある損失とのバランスを保つことです。私の直感は、それを単純に保ち、基本的なセキュリティの推奨事項（パスワードハッシュやMongoDBアクセス制御ツールを使用したアクセスの分離など）をシステムの他のセキュリティ制御（厳密なユーザー入力検証など）と組み合わせて、たとえば、 OWASP ASVSチェックリスト 。
質問1：パスワードのハッシュのポイントは、攻撃者がDBのコピーを取得した場合、資格情報を簡単に解読して、ユーザーになりすますことを防ぐべきではないということです。
多くのユーザーがパスワードを再利用したり、非常に微妙な方法でパスワードを変更したりすることを考慮すると、mayは、インフラストラクチャの他のコンポーネントへの侵害の拡散を遅らせるのにも役立ちます。
また、ハッシュを使用すると、DBへの完全なアクセス権を持つ可能性のある従業員は、ハッシュのコピーを取得した場合でも、情報を使用して他のユーザーにアプリを偽装させることができないため、内部関係者/不忠実な従業員のリスクを回避できます。
質問2：これは完全に別の質問です。より具体的またはあいまいな答えを出すには、個別に質問して詳細を提供する必要がある場合があります