SQLデータベースのパスワード暗号化の意見が必要です
データベースのパスワード暗号化構造が適切であるか、あまり使用されていないかを理解しようとしています。
だから私が登録すると、phpは50文字のランダムキーを生成し、そのキーはユーザーIDに対してタグ付けされたハッシュと呼ばれるdbテーブルに入れられ、そのハッシュはパスワードをAES暗号化するために使用され、パスワードが保存されます別のテーブルで。
ユーザーがログインすると、ハッシュが取り出され、復号化に使用されます。そして、ログインが成功した場合、ハッシュキーは次の使用などのために新しく生成されたものに置き換えられます。
これが良いアイデアかどうかはわかりませんが、フィードバックはありがたいです！
いいえ、これは良い考えではありません！ Lukas がコメントで指摘したように、あなたは パスワードをハッシュ化したい なので、決して暗号化しないでください！スキーマを使用すると、手間をかけずにデータベースダンプからプレーンテキストのパスワードを取得できます。それを起こさないでください！
いいえ、これはまったく良くありません。
まず、用語について大きな混乱があります。
ハッシュ関数は、任意の入力を固定セットにマッピングします。ここでの利点は、これらが1つの方法であるため、実際のパスワードを保存せずに、認証のためにパスワードを保存でき、実際のパスワードを回復する可能性がないことです。
一方、Encryptionは双方向です。キーがあれば、復号化は簡単です。
あなたが「ハッシュ」と呼んでいるものは、ハッシュではないようです。暗号化と復号化に使用される対称keyのようです。
スキーム全体では、パスワードをプレーンテキストで保存することにメリットはありません。攻撃者がデータベースへの読み取りアクセス権を持ち、暗号化されたパスワードを読み取ることができる場合、攻撃者はキーを読み取ることもできるため、暗号化は役に立たなくなります。
一般に、データベースに保存されているものを暗号化する場合、暗号化キーを同じデータベースに保存することは望ましくありません。しかし、この場合は パスワードはハッシュされ、暗号化されない であるため、重要ではありません。
ハッシュ全体の暗号化の問題に加えて、これが安全ではないもう1つの理由は、パスワードの生成方法です。 「キー」または「ハッシュ」と呼ぶのは、基本的には次のとおりです。自動生成されたパスワード。
今、上記のパスワードを生成するアルゴリズムがこれを予測可能な方法で実行し、攻撃者がこれにアクセスできる場合。攻撃者は、適切にハッシュされていても、すべてのユーザーのパスワードを予測することが可能になります。
タイミング攻撃についてもう少し読んで、これらの種類のパスワード/キー生成に適切なランダムソースを使用することを確認することをお勧めします。
暗号化には「復号化」と呼ばれるものがありますが、「ハッシュ解除」などはありません。したがって、パスワードをソルトしたり、組み込みのpassword_hash 関数。