私は安全なログインモジュールを構築しており、ハッシュなどの前にパスワードをソルトすることに関するこれらすべてのガイドを読んでいます。
そこで、代わりにハッシュの一部をデータベースに保存するだけでどうなるかを考え始めました。PHP で SHA-256 でハッシュすると 64 文字の文字列が得られます。これらのうち 50 文字をデータベースに保存し、ログイン時に同じ 50 文字の比較を行うとどうなるでしょうか。
ブルートフォースは、いくつかの余分な誤検知を与えます。それでも、彼らは非常に多くのパスワードを試す必要があり、実際のパスワードは明らかに解読できません。
私のアイデアに何か欠けているのでしょうか、それとも実際にうまくいくのでしょうか?
/アンドレアス
名前に値するハッシュは元に戻せません。SHA-256 ハッシュの出力から 14 文字を捨てると、SHA-228 になります。これはおそらくあなたが考えていたものではありません。十分な大きさのソルト (64 ビット以上) を使用し、それが適切にランダムである場合、十分に安全であり、50 文字よりも 64 文字を格納する方が安全です。
すべてのパスワードは、ハッシュとソルトの両方にアクセスできる「デハッシュ可能」であると感じました。
ハッシュを元に戻すことはできません。それがまさにハッシュの目的であり性質です。
攻撃とは、他の情報漏えいによるハッシュを知り、入力変数の可能性のあるすべての値のハッシュを計算することで問題を総当たり攻撃することです。ヒットした場合、推測した値がハッシュを作成するために最初に使用されたものでした。
ソルトは、一度にすべてを事前に計算するのではなく、すべてのパスワードに対して個別に実行する必要があるため、この攻撃を遅くしますが、最新のハードウェアはハッシュを非常に高速に計算できるため、これにはかつての抑止力がありません.
保存するハッシュ データの量を減らすことで、ブルート フォース推測が正しい可能性を確実に減らすことができます。パスワードは一致します。しかし、それの必要な欠点は、認証のためのそのハッシュの使用が大幅に弱められ、256 のランダムな推測ごとに 1 が入ることができることです.
保存されたハッシュを一意に推測しにくくすることの利点は、メインの認証インターフェイスを偶然の影響を受けやすくすることのコストに正比例します。オフラインで推測可能なハッシュのケースは、推測可能な認証インターフェイスのような絶え間ない脅威ではなく、データベース侵害が発生した場合にのみ発生するため、通常はあまり気にしません。
あなたの例では、200 ビットのハッシュ (50 の 16 進数) は、すべての一般的なパスワード文字列に対して一意の値を与える可能性が高いため、実際の利点はほとんどありません。
最終的に、漏洩したデータベースに対するオフライン推測を防止するという問題は解決できませんが、現時点で最善のアプローチは、攻撃者と実際の認証サーバーの両方に対してハッシュ計算を遅くすることです. 一般的な実装については、bcrypt と PBKDF2 を参照してください。それでも、データ侵害を発見した後、ユーザーにパスワードの変更を求める時間を与えるのに十分な時間、大量推測オフライン攻撃を遅くすることしかできません.