パスワードハッシュの暗号化に不利な点はありますか？
データベース内のパスワードハッシュの暗号化は、ハッシュのみを保存するよりも安全ですか？
暗号化されたSHA-256の結果を、ハッシュではなくAESで直接保存するとします。これは、誰かがアルゴリズムの1つを壊す将来の状況からの良い保護ですか？
まず第一に、保存されたすべてのパスワードは、異なる擬似ランダムソルトでハッシュされるべきです。次に、SHA-256はパスワードの保存には適していません。代わりに、すでに述べたように、 キーストレッチ アルゴリズムを使用します。詳細は Crackstation にあります。
暗号化されたハッシュはキー付きハッシュとも呼ばれ、キーは「ペッパー」と呼ばれることもあります。個別の暗号化ステップは必要ありません。代わりに、秘密鍵はハッシュ関数への入力の一部です。これはcanによりセキュリティが多少向上します。攻撃者がパスワードハッシュのコピーを取得する方法は2つあります。 1つは、SQLインジェクションと同様に、ストレージメカニズムを危険にさらすことです。その場合、キー付きハッシュはプレーンキーのパスワードをハッシュから取得することを事実上不可能にする可能性があります。これは、キーをプログラムにコンパイルするか、そうでなければパスワードストレージメカニズムの外部に保持できるためです。もう1つの方法は、OS自体を危険にさらすことです。その場合、キーは危険にさらされ、パスワードを攻撃する試みの妨げにはなりません。
つまり、簡単な答えは「はい」ですが、最初に基礎となる作業を正しく行う必要があります。
最初にハッシュ（ BCrypt ）を意味し、次にハッシュを暗号化する場合、セキュリティを弱めることはできませんが、改善されませんセキュリティ。
暗号化は、定義により、可逆的なスキームです。この場合、復号化が必要なユースケースは実際にはないため、暗号化はジョブにとって不適切なツールです。
「シークレットキー」をパスワードハッシュと組み合わせて使用する場合は、代わりにHMACを使用する必要があります（一般に「ソルトアンドペッパーの使用」と呼ばれます）。 HMACとハッシュの詳細については、 Password Hashingにsalt + pepperを追加するか、塩で十分ですか？ を参照してください。これを実装する方法については、 bcryptにペッパーを正しく適用する方法を参照してください？ 。
Bob Brownは 彼の答え でほとんどの顕著な点をカバーしてきましたが、1つの重要な欠点があることを指摘したいと思います：複雑さ。アプリケーションの複雑さをある程度まで軽減します（キー管理とパスワードハッシュとソルトの保存について考える必要があるハッシュにペッパーを追加する場合）またはそれ以上（実装する場合） AESのようなより洗練されたもので、IVまたはNonces、そして場合によってはタグ/ MACだけでなく、出力、ソルト、およびキーの管理を格納する必要があります。
では、追加する価値は、複雑さの追加コストを正当化するのに十分ですか？あなたはあなたのアプリケーションのためにその質問に答えなければなりません。私はそれは一般的にはそうではないと言うでしょうが、確かにそれが存在するケースは確かにあります。
いずれにせよ、ボブが述べたように、強力な基盤から始めて、暗号化するかどうかに関係なく、Bcryptなどのより良いハッシュアルゴリズムに移行する必要があります。