Webサイトがパスワードハッシュに無塩MD5を使用しているかどうかを調べる
私はWebサイトをパスワードセキュリティに従って分析および評価するプロジェクトに取り組んでいます（パスワードの最小/最大長、アルファベットサイズなどの要素がスコアに計算されます）。
知っておくべき重要な要素は、サイトが無塩MD5ハッシュを使用してパスワードを保存するかどうかです。これを確認するために、1つのパスワードで登録してから衝突でログインすると、衝突が引き起こされる可能性があります。ただし、HTMLフォームを介して送信されるデータは通常ASCIIエンコードされているため、多くの既知のバイナリMD5衝突の1つを使用できません。
2つのASCIIエンコードされた印刷可能な文字列の間に既知のMD5衝突はありますか？
または代わりに：
衝突以外に、Webサイトがパスワードを無塩MD5として保存しているかどうかを確認する方法はありますか？
私の知る限りでは（ただし、最近の結果を見逃した可能性があります）、MD5で既知のASCII互換の衝突はありません。
その主な概念的な理由は、衝突の発見は、いくつかの小さなビットの違いを導入し、それらがアルゴリズムで大きく広がりすぎる前に、これらの違いを互いにキャンセルしようとすることによって機能することです。つまり、特定の入力メッセージmについて、m 'がm数ビット。 mとm 'のMD5の計算ですべての内部値を比較することにより、違いが伝播することがわかります。同じビットの2つの違いは、場合によっては確率1（同じビットを2回フリップすると同じ値に戻る）で相殺される可能性があり、低い確率で、つまりに対してのみ機能します一部の可能な内部値。これは、MD5の演算がXORだけではないためです。また、いくつかのビット単位の非線形関数と、の追加がたくさんあります。追加はキャリー伝播を意味します。 MD5暗号解読の多くは、キャリー伝播に対処することです。
したがって、MD5衝突攻撃は、主に差分パス、つまりmとm '。これは、アルゴリズム全体で満たされ、それ自体をキャンセルして衝突を発生させる無視できない確率を持っています。次に、幸運になるまで、そのソースの違いによって異なる多くのペア（m、m '）を試します。 メッセージ変更手法は、差分全体では機能しないが、ほとんど機能するメッセージのペアを微調整することで、チャンスを改善する方法です。そのような手法に関係なく、フルフィルメントの可能性が低すぎない差分パスを使用する必要があります。
キャリー伝播は良好な差動パスを設計する上での主な問題であるため、そのための便利なツールは、32ビットワードの上位ビットを変更することです。実際、32ビットワードuおよびvが最上位ビットのみ異なる場合、 u + vは、（u、v）のすべての値について、必ず0x80000000に等しくなります。そのビットには、キャリーはありません（キャリー、いずれの場合も、結果が32ビットに切り捨てられる32ビットの加算を使用しているため、Wordから「落ちます」。これは1ビットの入力差であり、1ビットの出力差を確率1で生成します。これは非常に便利なツールです。実際の攻撃を生み出すのに十分高い確率を持つほとんどの（？のすべての）既知の差動パスは、ある時点で、そのような上位ビットの1ビットの違いに依存していることがわかります。
ただし、入力ワードの上位ビットで遊ぶと、衝突ペアに少なくとも1バイトが存在するため、メッセージの1つに128〜255の範囲のバイト値が含まれます。つまり非ASCIIバイト。
私が上で説明したことの多くは漠然とした手を振ることに基づいていますが、それはアイデアの要点を示すはずです：MD5コリジョンを取得する「高速」の既知の方法は、メッセージのいくつかのビットで遊ぶことを意味し、そして今、 、これにはいくつかのバイトの上位ビットが含まれるため、衝突するメッセージの1つが非ASCIIになります。
衝突を見つける遅い方法は、衝突が見つかるまでランダムなメッセージを試すことですが、制約はありません-これらのメッセージは完全なASCIIになる可能性があります。 11文字のパスワードを大量に生成し、大文字と小文字、および数字を使用する場合、2つほどハッシュすると衝突が発生するはずです。64 それらの、すなわち、すべての可能な11文字のパスワードの約3分の1。残念ながら、264 努力は技術的に実現可能であり、それはまだ非常に高価であり、誰もそれを実行していません。まだ。少なくとも公に。
外部から、パスワードの保存方法を決定するためにできることはほとんどありません。せいぜい、パスワード検証が非常に高速である（サーバーが数ミリ秒以内に応答する）ように見える場合は、パスワードハッシュが十分に反復されていないことを証明できます（ただし、「pepper」を使用している場合を除きます）可能性があります同時に高速で安全です-用語については この答え を参照してください）。それ以外の場合、特定のハッシュ関数の使用を証明するには、衝突が必要です。これは、特定のパスワードが特定のユーザーに対して機能するかどうかにかかわらず、取得できるすべての情報だからです。
データベースの内容を見ることができる場合（およびパスワードをハッシュすることの要点は、まさにそれを実行できる攻撃者の考えに基づいています）、あなたは多くの追加情報を持っています：
- 同じパスワードを持つ2人のユーザーが同じハッシュ値を取得する場合、ソルトはありません（それは悪いことです）。
- 同じパスワードを持つ2人のユーザーが同じハッシュ値を取得しないが、同じユーザーが自分のパスワードを以前のパスワードに戻した場合、ハッシュも古い値に戻されるので、本物の塩;ユーザー名はソルト（の一部）として使用されます（それほどではありませんが、これも悪いことです）。
- 候補ハッシュ関数を直接試すことができます。
2つのASCIIエンコードされた印刷可能な文字列間に既知のMD5衝突はありますか？
番号。
ASCII準拠のMD5ハッシュ衝突入力はまだ見つかっていないと思います。しかし、小さな非ASCII入力が見つかりました： https://stackoverflow.com/questions/1999824/whats-the-shortest-pair-of-strings-that-causes-an-md5-collision 。
衝突以外に、Webサイトがパスワードを無塩MD5として保存しているかどうかを確認する方法はありますか？
簡単に;バックエンドデータベースにアクセスできる場合。彼らがテーブルにソルト列を格納していないか、パスワードレコードのいずれかが Vanilla MD5 Rainbow table -に一致する場合、パスワードごとに一意のソルトを使用していません。グローバルカスタムソルトを使用しているかどうか、またはそれらの一意のソルトが単一のタプル属性にマージされているかどうかを確認するには、さらに作業が必要になる場合があります。
暗号化ハッシュの略記としてMD5を使用していますか？
ほとんどの暗号化ハッシュは破られておらず、Webサイトが使用しているハッシュはフロントエンドからは明らかではないためです。