データベース内または外部からのハッシュ？
私は「株式分析システム」のアーキテクチャーを進化させています。 SQLServerをデータベースとして使用しますが、.NETルートを使用せず、組み込みの「メンバーシップ」機能を使用しません。ユーザー、user_credentials、ロール、および権限テーブルを設計しました。 'credentials'テーブルには、ID、ユーザーのフルネーム、電子メール、ログインID、ソルト、ハッシュされたパスワードが格納されます。
質問は
a）「credentials」テーブルに値を挿入するストアドプロシージャは、データベースの機能-hashbytes/sha2_512を使用してハッシュを実行できますか？その場合、プレーンテキストのパスワードをストアドプロシージャにパラメーターとして渡す必要があります。ストアドプロシージャは、プロファイラーまたはトレースを介してDBAが確認できます。
b）webサーバー上のアプリケーション（node.jsなど）は、saltとハッシュを作成し、ハッシュのみをストアドプロシージャに送信して、プレーンテキストのパスワードをデータベースから完全に見えなくする必要がありますか？ただし、管理者がパスワードを確認することを決定した場合、パスワードは引き続きWebサーバーで表示できます。
私はウェブ/アプリサーバーを軽量に保ち、データベース側でほとんどすべての作業を行いたいと思っています。そして、option-aのように見えます。同時に、bcryptやscryptなどの高度なアルゴリズムはデータベース内から利用できない場合があり、私の一部はoption-bを使用することをお勧めします。また、多少メモリを集中的に使用するハッシュ処理を行うのは、データベースの仕事ではない可能性があります。ベストプラクティスとして、option-bの使用が推奨されると思います。
私は故意にOpenID/OAuth 2.0ルートを使用していません。SQLServerで多くの作業が既に行われているため、現時点ではMySQL、PostgreSQL、またはNoSQLデータベースの使用を検討していません。
あなたの考え、アドバイス、提案、およびポインタは大歓迎です。
アプリケーション側でのハッシュには1つの大きな利点があります。パスワード/資格情報は暗号化されていない方法でネットワーク経由で送信されないことが保証されているため、ネットワークトラフィックを分析しても簡単に見つけることができません。
もちろん、今日、SQLサーバーへのネットワーク接続は通常SSL/TLSを使用しますが、DB側でハッシュを実装する場合、使用するアルゴリズムは潜在的な違反ポイントだけではなく、セキュリティもSSL/TLSに依存します安全を維持します（もちろん、これらのプロトコルをアクティブにするのを忘れることはありません）。
ただし、十分なアクセス権を持つ悪意のある管理者は、入力されたパスワードをログに記録する「プロキシ」によってシステムのコンポーネントを常に交換する可能性があり、Webサーバー上のアプリケーションやDBのストアドプロシージャとこれに一般的な違いはありません。これはあなたが技術的な解決策によってあなたが防ぐことができる何でもありません、あなたはこれがそれらの人々の労働契約に特定の条項を持っているのを防ぎます。ただし、異なるWeb管理者とデータベース管理者がいる場合は、アプリケーション側で暗号化を維持することにより、パスワードをログに記録する可能性のある人々のグループが少なくなる可能性があります。
ハッシュ機能をデータベース側に配置することの唯一の真の利点は、異なるWebアプリ間または異なるバージョンのWebアプリ間でこの機能を再利用できることです。
実際にボトルネックに気付く前に、パフォーマンスについてあまり心配する必要はありません。通常、認証はこのようなシステムで発生するアクティビティのごく一部にすぎないため、暗号化のパフォーマンスが無視できると期待することは不合理ではありません。