web-dev-qa-db-ja.com

PBKDF2:ハッシュからソルトを知ることができますか?

一部のKDFはbcrypt(モジュラー暗号形式)などのソルトを出力にバンドルしていることを理解しています。

PKCS5_PBKDF2_HMAC(具体的には、 OpenSSL実装 を1回の繰り返しで見て)、saltは知っている/攻撃可能ですか?

ユーザーパスワードをソルトとして使用して、一部のデータに対してPBKDF2-HMACの単一の反復を実行するKDF実装を見つめています。

塩が発見されるリスクがありますか/これはPBKDF2の適切な使用ですか?

(ハッシュされるデータ自体は同じKDFからの出力ですが、適切な反復回数が使用されます。)


 //ハッシュ1はネットワーク経由で送信されず、対称暗号化に使用されます
 hash_1 = pbkdf2(salt = username、data = password、iterations = 5000)
 
 //ハッシュ2が認証用のパスワードとしてネットワーク経由で送信されます
 //ソルトは脆弱ですか?
 hash_2 = pbkdf2(salt = password、data = hash_1、iterations = 1)
3
az_

編集:

私の最初の直感的な応答はパスワードをソルトバリューとして使用しないでください。そして、それはまだ私が立っているところのほとんどです。

しかしながら;あなたの投稿をもう少し注意深く読んでください。pbkdf2アルゴリズムの結果にソルトは保存されません。

しかしながら;ソルトの目的は、ハッシュする前に入力データにエントロピー(ランダム性)を追加することです

塩は実際には「秘密」であることを意図していません。

私が目にする最初の明白な問題は、pbkdf2への最初の呼び出しでソルト値としてユーザー名を使用することです。それは完全に予測可能です。ユーザー名とパスワードのハッシュと共に保存されているランダムに生成されたソルト値を使用しないのはなぜですか? (パスワード自体はどこにも保存しないでください)。

とにかく、ソルトは、KDFによって格納または送信されないものであると言っても安全です。これは、ソルトが一方向の数学的に不可逆な出力値を生成するために使用される入力だからです。ソルト自体は出力に存在しません。

しかし、どちらも十分にランダムではないため(重複から十分に安全であるため)、ユーザー名とパスワードはどちらも「塩」の値としてはあまり適していません。特にパスワードは、多数のアカウントのセットで重複する可能性が非常に高くなります。多くの人が同じパスワードを使用することになります。

ただし、ランダムに生成された saltをハッシュする前に同一のパスワードに追加すると、結果のハッシュは完全に異なります。

一方、複数のアカウントまたは複数のデータストリームで同一の(予測可能!)ソルト値を持つことは、ある程度の予測可能性をもたらし、潜在的に悪用の扉を開くため、悪いニュースです。

編集#2:

ハッシュとソルト...この件に関して追加の疑問とコメントがあるように見えるので、肝心なことは、暗号ハッシュアルゴリズムは決定論的であるということです(暗号ハッシュアルゴリズムへの同じ入力は常に同じです出力)。

これが真実でない場合、これらのアルゴリズムは役に立ちません。

セキュリティの観点からの問題は、入力データ(通常はパスワード)を「ソルト」しない場合、保存または送信するハッシュは、元のデータよりも一意ではないということです。

したがって、1つのハッシュ(辞書攻撃またはRainbowテーブル)をクラックすると、一致するすべてのハッシュがクラックされたことになります。これがまさに、数年前に600万のアカウントが侵害された(主要なビジネスソーシャルメディアサイトを名前で識別できるか)ことにつながったものです。

"ソルト"は、エントロピー(ランダム)のグリーンスクリーン時代にさかのぼる、かわいらしい頭字語でした。 「ハッシュ」の「塩漬け」(ハッシュブラウンポテトやコンビーフハッシュなどに塩をかける)について考えるのはかわいいです。

「塩」の目的は、入力(パスワード)をランダム化することです。ソルトがランダムに生成される場合、すべてのパスワードに対して完全に一意になります。それをパスワードに追加すると、数千人のユーザー全員が同じパスワードを選択したとしても、突然すべてのパスワードが一意になります。

ソルト値自体は一般に秘密であることを意味しません。多くの場合、ハッシュ値と一緒に(またはハッシュ値に追加して)保存され、元のデータシークレット自体(パスワード)は保存されません。

したがって、ユーザーがシークレットを提供すると、ハッシュが最初に作成されたときと同じ方法でソルトが提供された文字列に追加され、ハッシュアルゴリズムにフィードされます。結果が保存されたハッシュと一致する場合、ユーザーが正しいパスワードを提供したことがわかります。 。

ユーザー名がグローバルに一意ではないことについて@Flecheが言っていることは真実であり、パスワードはグローバルに言うまでもなく、小さなドメインではそれほど一意ではありません。

このようにユーザー名とパスワードの両方をソルトとして使用すると、 might で、予期しない攻撃に遭遇する可能性があります。ユーザー名はドメイン内で一意であっても、予測可能であり、 universally 一意ではありません。ただし、塩の値は通常、とにかく秘密ではありません。だからあなたはかもしれません安全であるかもしれません。しかし、それは少し大ざっぱな感じです。

4
Craig

入力データから導出される「塩」は、まったく塩ではありません。つまり、これはnsaltedハッシュ関数であり、パスワードと反復回数のみを取得して、結果のハッシュを計算します。反復回数が一定の場合、同じパスワードは常に同じハッシュを生成します。

ソルトの要点は、それが追加入力であるということです。一般的な考えに反して、それは決して秘密ではありませんが、十分にランダムである必要があります。

4
Fleche