ソルトが長すぎると、保存されているパスワードハッシュのセキュリティが低下しますか？
統計的に7〜8文字のパスワードがあるとします。 200文字の長さのソルトを追加することは、同様のハッシュ関数入力のため、5文字のソルトよりも安全ではありませんか？
私は疑問に思っていました：誰かがソルトをブルートフォースでソルトを推測しようとした場合、たとえばパスワード「123456」、またはシステム、またはハッカー自身のアカウントからの既知のパスワードで見つけることができる別の人気のあるパスワードはどうでしょうか？
MikeとGumboがコメントで述べたように、saltは不正なパスワードを保護するためのものではありません。これは、攻撃者がデータベース全体を一度に破壊しないようにするためのものです。ソルトの長さは、保存されているパスワードの解読を困難にすることを意図したものではありません。これは、ソルトがインターネット上の他のソルトと比べてかなり一意であることを保証するためのものであり、（正しく実行している場合）2人のユーザーが同じソルトを持つことはありません。
20人のユーザーがパスワードとして「神」を持っているとします。以下のシナリオを検討してください。
パスワードは無塩です
攻撃者は事前に計算されたテーブルを使用して、1人のユーザーのパスワードをveryの短い順序で解読できます。その上で、20の最初の1つを取得すると、ハッシュが同一になるため、残りの19も取得します。パスワードはソルト処理されます。使用されるソルトはかなり短いです。すべてのユーザーに同じソルトが使用されます。
攻撃者は少し探す必要があるかもしれませんが、あなたの構成のために特別に作られた事前計算されたテーブルに遭遇する可能性があります。その後、シナリオ1を参照してください。パスワードはソルト処理されます。使用されるソルトはかなり強力です。すべてのユーザーに同じソルトが使用されます。
確率は、攻撃者がインターネット上でシステムの事前に計算されたテーブルを見つけられないことです。彼は自分で作る必要があります。これには少し時間がかかります。ただし、それが完了すると、再びシナリオ1に戻ります。- パスワードはソルト処理されます。使用されるソルトはかなり強力です。各ユーザーには固有のソルトがあります。
これはあなたがすべきことです。攻撃者がシステムの事前計算済みテーブルを見つけられないだけでなく、攻撃者が自分でテーブルを作成する価値はありません。彼が行う可能性のある前処理は、oneユーザーに対してのみ機能します。前述の20人のユーザーのいずれかをヒットしても、ハッシュはすべて異なるため、他の19人はわかりません。したがって、各パスワードは個別に攻撃する必要があります。また、本来のように強力で低速なハッシュアルゴリズムを使用している場合は、しばらく時間がかかります。おそらく、弱いパスワードは最終的にはまだ危険にさらされています。攻撃者がそれらすべてを通過するのにかなり長い時間がかかるだけであり、同じパスワードを持っているからといって、ユーザーのチャンクが一度に侵害されることはありません。
したがって、長いソルトを使用し、ユーザーごとに固有のものにします。ただし、パスワードに「神」を使用している場合でも、個々のユーザーを助けるためにこれを当てにしないでください。
塩が長すぎると、セキュリティが低下しません。ソルトが短すぎると、セキュリティが低下します。
塩が長くなると、セキュリティが向上します。ある時点で境界を越え、塩の長さが増えると収益が減少し始めます。そして、最終的には、別の境界を越えることになります。ソルトが長くても、セキュリティはまったく追加されません。
ただし、より長いソルトには大きなコストがかからないため、2番目の境界に到達するまで長さを増やすのをやめる理由はほとんどありません。ソルトの長さをそれより長くしても、唯一の欠点は、保管と処理時間の点でわずかな追加コストです。
悲しいことに、塩分は2つのしきい値の低い方の長さで生成されることがよくあります。
では、2つのしきい値とは何でしょうか。
下限しきい値は、ユーザーの数とソルトの目的によって決まります。これは、ユーザーが選択したすべてのパスワードで異なります。控えめに見積もっても、世界中のユーザー数は10 ^ 10未満であり、各ユーザーのパスワードは10 ^ 2システム未満であり、存続期間中にこのパスワードを10 ^ 3回未満変更します。つまり、パスワードは合計で10 ^ 15未満になります。これを考えると、ソルトの50ビットのエントロピーは2つのソルトが繰り返されることはないことを保証するのに十分であると誤って結論するかもしれませんが、誕生日のパラドックスのためにその数を2倍にする必要があります。
したがって、ソルトが100ビットより長くなると、追加されたセキュリティの観点から収益が減少し始めています。 100ビットのしきい値には、多くの推測が含まれていました。次のしきい値では、推測がはるかに少なくなります。ソルトで100ビットを超えるエントロピーを使用しても、セキュリティは向上しますが、それほどではありません。
しかし、ソルトが根底にあるハッシュ関数の出力より長くなると、それを長くすることによるセキュリティの追加はありません。しきい値はハッシュ関数によって異なりますが、一般的なハッシュの場合、これらの範囲は128〜512ビットです。
通常、ソルトは1文字あたり6ビットのエントロピーで生成されるため、512ビットのエントロピーに到達するには86文字のソルトが必要です。
セキュリティの観点から重要なソルトの唯一の特性は、それがglobally uniqueであることです。長さは、塩の一意性に影響を与える可能性がありますが、他の観点からは無関係です。それが何かにプラスまたはマイナスの影響を与えると仮定することは、提供するつもりでなかった機能を実行するようにソルトに要求することです。
だから、塩は一意性を合理的に保証するのに十分な長さでなければなりません、そしてそれがすべてです。あなたの塩が優れた独自性を持っていると仮定すると、もはや安全性にプラスまたはマイナスの影響を与えることはありませんが、最も確実に保管スペースを浪費します。
他の人はソルトとパスワードの適切な使用についてコメントしましたが、質問にそれらが機能する方法のやや不正確な直感を示唆しているように見えるので、ハッシュ関数にWordを追加すると便利かもしれません。
設計上、優れた暗号化ハッシュ関数では、ハッシュされた値自体に基づいて入力がどの程度類似しているかを推測できません。それ以外の場合は、この距離を徐々に短くすることで反転させることができ、純粋な総当たりの推測よりもはるかにコストがかかりません。したがって、hash（salt1 +“ 12345”）は、hash（salt1 +“ 67890”）またはhash（“ 12345”）に、hash（salt2 +“ 67890”）よりも似ているべきではありません。
ソルトの要点は、2つのアカウントが偶然同じパスワードを使用している場合でも、入力（およびハッシュ）が同一でないことを確認しますが、類似性は問題。
ソルトの長さは、収益の減少の法則に従います。
塩が長くなることによってless安全になることは決してありません。
しかし、意味のある取得は停止しますmore比較的迅速に保護されます。
ソルトを「クラック」することは決してありません。クラックしているのは、ソルトが付加されているハッシュされたパスワードです。ソルトは、レインボーテーブルの脅威に対処するだけです-ハッシュの事前計算されたテーブルを見つける機能により、ブルートフォースの面倒なプロセスをスキップできます。
この目的のために必要なのは、十分な長さの塩だけであり、そのようなすべての可能な塩のための包括的なレインボーテーブルをまだ誰も作成していません。そして、レインボーテーブルを作成するコストと、ソルトの最大長を増やすと計算する必要があるソルトの数の指数関数的増加のため、これはそれほど難しい要件ではありません。ソルトの数文字だけがすでにあなたのフォーマットのソルトについて包括的なレインボーテーブルを誰も計算していないことを確実にする可能性が高いです。
ランダムな値をどこからでも選択するには、たとえば16進数の16桁以上のソルトは、ランダムに選択する方法に悪用可能な欠陥がないことを前提として、非常に優れています。
これを超えると、セキュリティの向上はますます無視できなくなります。