個々のファイルにパスワード保護を実装するにはどうすればよいですか?

Question

私は、データ ファイルを暗号化し、パスワードで保護できる小さなデスクトップ アプリを作成しています (つまり、復号するには正しいパスワードを入力する必要があります)。暗号化されたデータ ファイルを自己完結型で移植できるようにしたいので、認証をファイルに埋め込む必要があります (おそらくそうだと思います)。

私の知識に基づいて実行可能で論理的であると思われる戦略がありますが (おそらく危険であるだけで十分です)、それが実際に良い設計であるかどうかはわかりません。それで教えてください：これはおかしいですか？それを行うためのより良い/最善の方法はありますか?

• ステップ1：ユーザーはプレーンテキストのパスワードを入力します。「私の難しいパスワード」
• ステップ2：アプリはユーザー パスワードをハッシュし、その値を対称キーとして使用してデータ ファイルを暗号化/復号化します。例えば「MyDifficultPassword」 --> 「HashedUserPwdAndKey」。
• ステップ 3:アプリはステップ 2 のハッシュ値をハッシュし、新しい値をデータ ファイル ヘッダーに保存します (つまり、データ ファイルの暗号化されていない部分)、その値を使用してユーザーのパスワードを検証します。例えば「HashedUserPwdAndKey」 --> 「HashedValueForAuthentication」

基本的に、私は Web サイトのパスワードを実装する一般的な方法 (つまり、OpenID を使用していない場合) から推定しています。これは、ユーザーのパスワードの (ソルト化された) ハッシュを DB に保存し、実際のパスワードを決して保存しないことです。 。ただし、対称暗号化キーにハッシュされたユーザー パスワードを使用しているため、認証に同じ値を使用することはできません。そこで、基本的に別のパスワードと同様にそれを再度ハッシュし、二重ハッシュされた値をデータ ファイルに保存します。そうすれば、ファイルを別の PC に持ち込んで、パスワードを入力するだけで復号化できます。

では、この設計はかなり安全なのでしょうか、それとも絶望的に単純なのでしょうか、それともその中間なのでしょうか?ありがとう！

編集：以下に関する説明とフォローアップの質問:塩。
ソルトが役立つためには秘密にしておく必要があると思いましたが、あなたの回答とリンクは、これが事実ではないことを示唆しています。例えば、 この仕様 エリクソンのリンク (下記) は次のように述べています。

したがって、ここで定義されているパスワードベースのキー導出は、パスワード、ソルト、および反復回数の関数であり、後者の 2 つの量を秘密にしておく必要はありません。

これは、ハッシュ化されたキーと同じ場所/ファイルにソルト値を保存でき、ハッシュ化時にソルトをまったく使用しない場合よりも安全であることを意味しますか?それはどのように機能するのでしょうか?

もう少し背景を説明します。暗号化されたファイルは、他のユーザーと共有したり復号したりすることを目的としたものではなく、実際には単一ユーザーのデータです。しかし、完全に制御していないコンピューター上の共有環境にそれを展開したいと考えています (例:職場では)、ファイルをコピーするだけでデータを移行/移動できます (そのため、自宅や別のワークステーションなどで使用できます)。

Answer 1

鍵の生成

で定義されている PBKDF2 などの認知されたアルゴリズムを使用することをお勧めします。 PKCS #5 バージョン 2.0 パスワードからキーを生成します。これは、概要を説明したアルゴリズムに似ていますが、AES で使用するためのより長い対称キーを生成できます。さまざまなアルゴリズムの PBE キー ジェネレーターを実装するオープンソース ライブラリを見つけることができるはずです。

ファイル形式

の使用も検討してください。 暗号化メッセージの構文 ファイルの形式として。これにはある程度の検討が必要ですが、やはり使用できる既存のライブラリがあり、S/MIME 対応メール クライアントなどの他のソフトウェアとよりスムーズに相互運用できる可能性が広がります。

パスワードの検証

パスワードのハッシュを保存したい場合、PBKDF2 を使用してキーを生成する場合、標準のパスワード ハッシュ アルゴリズム (ビッグ ソルト、1,000 回のハッシュ) を使用して、さまざまな値を取得できます。

あるいは、コンテンツの MAC を計算することもできます。パスワードのハッシュ衝突は、攻撃者にとって有益である可能性が高くなります。コンテンツ上のハッシュ衝突はおそらく無価値です。しかし、これは、復号化に間違ったパスワードが使用されたことを正当な受信者に知らせるのに役立ちます。

暗号ソルト

塩 事前に計算された辞書攻撃を阻止するのに役立ちます。

攻撃者が、可能性のあるパスワードのリストを持っているとします。彼はそれぞれをハッシュし、被害者のパスワードのハッシュと比較し、一致するかどうかを確認できます。リストが大きい場合、これには長い時間がかかる可能性があります。彼は次のターゲットにそれほど多くの時間を費やしたくないので、ハッシュが対応する入力を指す「辞書」に結果を記録します。パスワードのリストが非常に長い場合、彼は次のようなテクニックを使用できます。 レインボーテーブル スペースを節約するために。

しかし、彼の次のターゲットがパスワードにソルトをかけたとします。 たとえ攻撃者がソルトが何であるかを知っていたとしても、事前に計算されたテーブルは無価値です- ソルトは、各パスワードから得られるハッシュを変更します。彼はリスト内のすべてのパスワードを再ハッシュし、ターゲットのソルトを入力に付加する必要があります。異なるソルトごとに異なる辞書が必要となり、十分な数のソルトが使用されると、攻撃者にはそれらすべてのソルトの辞書を保存する余地がなくなります。時間を節約するためにスペースを取引するという選択肢はもはやありません。攻撃者は、攻撃したいターゲットごとに、リスト内の各パスワードをハッシュすることにフォールバックする必要があります。

したがって、塩を秘密にしておく必要はありません。攻撃者がその特定のソルトに対応する事前に計算された辞書を持たないようにするだけで十分です。

Answer 2

Niyaz 氏が述べたように、次のような強力なアルゴリズムの高品質な実装を使用する場合、このアプローチは合理的であるように思えます。 SHA-265 そして AES ハッシュ化と暗号化用。さらに、 塩 すべてのパスワード ハッシュの辞書を作成する可能性を減らすため。

もちろん読書も ブルース・シュナイアーさんの 応用暗号化 も決して間違ってはいません。

Answer 3

強力なハッシュ アルゴリズム (SHA-2) と強力な暗号化アルゴリズム (AES) を使用している場合は、このアプローチで問題なく動作します。

Answer 4

パスワードで保護されたファイルをサポートする圧縮ライブラリを使用してみてはいかがでしょうか?以前、XML コンテンツを含むパスワードで保護された zip ファイルを使用したことがあります:}

Answer 5

ハッシュ化されたパスワードをファイルに保存する必要は本当にありますか。パスワード (またはハッシュされたパスワード) にソルトを加えて使用し、それを使用してファイルを暗号化することはできませんか。復号化するときは、パスワード + ソルトを使用してファイルを復号化してください。ユーザーが間違ったパスワードを入力した場合、復号化されたファイルは正しくありません。

私が考える唯一の欠点は、ユーザーが誤って間違ったパスワードを入力し、復号化が遅い場合、再試行するまで待たなければならないことです。そしてもちろん、パスワードを忘れた場合、ファイルを復号化する方法はありません。