web-dev-qa-db-ja.com

PBKDF2でシークレットパスワードを変更するためのベストプラクティスは何ですか

私は秘密鍵(またはパスワード rfc8018 と呼ぶ)に関する推奨事項について読みました。そのうちの1つは、パスワードを時々変更することです。

知りたいのですが、このパスワードの変更にはいくつかのベストプラクティスがありますか?

私はこれを次の情報とともにRFCで見つけました 参照

パスワードを変更すると、関連するDPKを保護するキーが変更されます。したがって、パスワードが変更されるたびに、廃止パスワードによって保護されているDPKは、廃止パスワードに関連付けられているMKまたは派生したキー生成情報を使用して回復(復号化など)され、再保護(暗号化など)されます。 )新しいパスワードに関連付けられている適切なMKまたは派生したキー生成情報を使用する。

このテキストから、私は再び保護しなければならないことを理解しました。しかし、whenwhoによってこのプロセスを行う必要がありますか? 「再保護」はバッチプロセスですか?またはより良いオプションはありますか?

手短に言うと、ホイールを再発明せずにこのプロセスを実行する方法は?

パスワードへの参照の明確化

私は、Wordのパスワードが混乱を招くと思いますが、RFCが次のように参照しているため、Wordのパスワードを使用しました。

「公開鍵暗号の多くのアプリケーションでは、ユーザーのセキュリティは最終的に1つ以上の秘密のテキスト値またはパスワードに依存します。ただし、パスワードは従来の暗号システムの鍵として直接適用できないため、パスワードの何らかの処理が必要です。さらに、パスワードは比較的小さいスペースから選択されることが多いため、検索攻撃を防ぐためにその処理には特別な注意が必要です。」

テキストを読んで、私はこのパスワードはユーザーパスワードとは関係がないと思います(私は間違っている可能性があります)。私にとってこれは、テキスト全体を暗号化するために、アプリケーション全体で使用できる秘密です。

その点を明確にしていただければ幸いです、ありがとうございます。

1
KCOtzen

暗号化された情報にアクセスするためにパスワードを入力する必要がある状況では、PBKDF2を使用してデータを暗号化するキーを取得する必要はありません。

  • すべてのファイル(またはモノ)は、ランダムに生成された一意の「セッション」キーとソルト(256ビットの暗号化キーなど)で暗号化されます
  • ファイルごとの「セッションキー」は、マスターキー(およびソルト)で暗号化されます
  • マスターキーもランダムに生成された256ビットの暗号化キーです

次に、そのマスターキーがユーザーのパスワードから導出されたキーで暗号化されます。

enter image description here

基本的な目標は次のとおりです。

  • 各ファイルは暗号的に強力な256ビットキーで暗号化されます
  • すべてのセッションキーは、暗号学的に強力な256ビットキーで暗号化されます。
  • マスターキーはユーザーのパスワードで暗号化されています

これの利点は、データとセッションキーが優れた暗号化キーで保護されていることであり、弱点ではありません。

そして、ユーザーが自分のパスワードを変更したい場合:

  • すべてのデータを復号化して再暗号化する必要はありません
  • すべてのファイルごとのセッションキーを復号化および再暗号化する必要さえありません
  • あなたは彼らのマスターキーを解読して再暗号化する必要があるだけです
2
Ian Boyd

私は秘密鍵(またはrfc8018が呼び出すパスワード)に関する推奨事項について読みました。そのうちの1つは、パスワードを時々変更することです。

NIST文書のどこにもパスワードを変更することはありません。 RFC 8018は秘密鍵のパスワードを呼び出しません。

しかし、いつ、誰がこのプロセスを行わなければならないのでしょうか。

いつ? whenever a password is changedこれは、新しいパスワードから新しいキーを導出する場合です。

WHO?データを秘密にしたい人、ストレージメディアへの書き込みアクセス権があり、パスワード、マスターキー、または派生キーを知っている人。おそらく別の従業員。

手短に言うと、ホイールを再発明せずにこのプロセスを実行する方法は?

パスワードベースの暗号化をサポートする多くのアプリケーションがあります。たとえば、KeePass2とVeracrypt。もちろん、もっとたくさんあります。ほとんどすべてが非常に不完全です。私は、クローズドソース、コマーシャル、または小規模なユーザーベースのプロジェクトを引用することに抵抗があります。他の人々は、GPG(正しく使用するのは難しい)や7Zip(疑わしい)を含むかもしれません。

トピックが広すぎて、すべてのプログラムまたはその一部のメリットと欠陥を分析できません。それは私にとって多くの執筆であり、このサイトが意図するものではありません。


あなたがソフトウェア開発者として尋ねているなら...これから遠く離れてください。暗号化の正式なバックグラウンドを持つ他の誰かがその作業を行えるようにします。セキュリティに壊滅的な影響を与えることで事態を悪化させる微妙な方法は無数にあります。責任のあるプログラミングチームがこれらの方法のすべてを知ることは重要です。

(参考までに、そのNISTは、暗号化の分野で理解するためにリモートで難解な知識さえ必要としません。ほとんどのサブジェクトとドキュメントははるかに複雑です。その上、NISTドキュメントはかなり不完全であり、最新ではありません。したがって、このドキュメントから出発点として作業することは不十分です。

0
Future Security