重要ではないWebサイトのパスワードに自家製のハッシュを使用する
最初に：私はこれまで自家製のハッシュ機能を使用しませんし、使用するつもりもありません。なぜそうすべきでないのかを知っており、それが愚かであることを知るのに十分なトピックを読んでいます。
私はこの問題の専門家ではなく、自分で作ったアルゴリズムの脆弱性を見つけて悪用する可能性があり、それらの結論を使用して、より堅牢な標準暗号化よりも簡単に保存されたハッシュパスワードを解読できることを理解しています。
私が頭を包むことができないのは次のとおりです。Aを入れた関数を想定すると、常にBが出力されます。Bは常に同じです。それが最善ではないことは承知していますが、それを現状のまま比較のための「適切な」アルゴリズムとしてください。
ハッカーがデータベースを持っている場合、そのことを行い、データベースから大量のパスワードを復元することができました。ボットが実行されている場合、またはハッシュ化されたパスワードをダウンロード/一般的なハッキング/購入する場合、ハッカーは標準的なトリックを繰り返して元に戻すことができます。
ハッカーのターゲットにならず、独自の「追加ソース」を実装しないほど重要でない会社を所有している場合1、トリックを使用するすべての「ドライブバイ」バリアントは機能しなくなり、したがってより安全になります。
そこにありますか/私のロジックの欠陥は何ですか？それらを長くすると、これは価値のないアプローチになります。初めからやりなさい。しかし、もしあなたがあなたが決して二度とないことを知っているならどうでしょう。
1例えば文字列を部分AとBに分割し、BABを連結します。
あなたのロジックの最初の欠陥は、あなたが説明する特性、すなわちという正しいパスワードハッシュアルゴリズムがないことです。 "Aを入れた関数を仮定すると、常にBを出力します。同じ。」。代わりに、適切なハッシュにはランダムなソルトが含まれるため、同じパスワード（A）は異なるハッシュ（B）になります。実際にランダムでもある十分に長いソルトを使用すると、マッピングのデータベースを作成するのに時間がかかりすぎ、大きすぎるため、攻撃者がマッピングのデータベースを作成することは事実上不可能です。過去に一部の実装が単にMD5またはSHA1でパスワードをハッシュしたとしても、過去にも間違っていたことに注意してください。すでに古くからの POSIX crypt関数 にはソルトの使用が必要でした。
ロジックの2番目の欠点は、シークレットアルゴリズムが実際よりも秘密であると考えることです。ハッカーが行う必要があるのは、サイトを危険にさらして、弱くハッシュされたパスワードだけでなく、同じサイトにある可能性が高いシークレットパスワードハッシュを実行するコードの一部を盗むことだけです。次に、独自の脆弱なアルゴリズムを使用して、データベース内のパスワードを総当たりすることができます。したがって、本質的には、弱いアルゴリズムと覆い隠しを組み合わせるという考えは、覆い隠し部分が実際には機能しないため、単に弱くなります。
サイトが重要ではないと思われる場合でも、そのような妥協はありそうにないことに注意してください。攻撃者は、重要なものを盗むためにサイトを危険にさらすだけでなく、信頼できるホストをさらなる攻撃の開始点として使用します。また、重要性の低いサイトは安全性が低いことが多いため、これらのセキュリティ侵害は比較的容易です。ハッシュ化されたパスワードとハッシュアルゴリズムへのアクセスは意図しないものですが、おそらく歓迎すべき副作用です。
これはmightは、攻撃者がアルゴリズムの動作方法を知らないという想定の下で意味をなします。残念ながら、これは現実的な想定ではありません。
時々、攻撃者は内部関係者です（実際、内部関係者はすべての違反の約25％を担当しています）。インサイダーが誤ってプライベートデータを公開することもあります（すべての違反の約25％も責任があります）。場合によっては、外部の攻撃者がデータベースだけでなくコードベースにもアクセスできます。
上記のすべてのケースで、マジックソースは完全に役に立ちません。ソルトによって保護された強力なハッシュ関数は、総当たり攻撃に対して非常に耐性があります。さらに、コードベースに直接保存されていないコショウを追加した場合も同様です。便利なことに、このようなツールもサポートされており、最近は使いやすいです。独自のマジックソースを書くよりもはるかに簡単です。
結果として、あなた自身の魔法のソースを書く正当な理由は本当にありません。
ハッシュ関数は元に戻せません。唯一の「トリック」は、攻撃者がブルートフォースを実行したり、すべてのA-> B結果（Bでソート）のテーブルルックアップを作成したりすることです。
塩の使用は副次的な問題です。ソルトは、入力Aに連結される単なる追加情報です。ハッシュアルゴリズムは同じままです。
同じサイズ以上の別のハッシュ関数を連続して追加した場合、個々のアルゴリズムの潜在的な数学的欠陥に対してより安全になります。基本的に、同じハッシュアルゴリズムをX回実行すると、ブルートフォーシングがX回長くかかるため、より安全です。複数のアルゴリズムを使用すると、ブルートフォース以外のショートカットを使用できる可能性が低くなります。
独自のハッシュ関数は、プロのハッシュ関数と同じベンチマークを満たす必要があります。つまり、値の統計的分布が均一になります。関数を実行して、値または値の範囲が他よりも多く出力されないことを確認できるはずです。どんな値の巨人も、より単純な数学関数によって予測不可能でなければなりません。
あなたの自作の関数の例が何かわからないので、これについてはまだコメントできません。
彼らがデータベースをハッキングしてパスワードハッシュを盗むことができた場合、ソースコードにアクセスして、あなたがどのように魔法を実行したかを理解できる可能性が高くなります。あいまいさによってセキュリティに依存するべきではありません。
彼らがあなたのトリックを知っていて、それをクラッキングする試みをしようとしていると想像してください。私たちが持っている関数よりもGPU並列化から保護されるパスワードハッシュ関数を作成できた大きなチャンス。ベストプラクティスを使用してください。そして、クールなのは、ほとんどのプログラミング言語がこれらの最高の機能を備えており、最近使用できることです。自分の暗号をロールバックしないでください。