web-dev-qa-db-ja.com

これは自己ロールハッシュ/難読化方法ですか?パターンを認識できますか?

組織に導入しているシステムは、私が見つけることができる従来のハッシュ関数を使用していません。私はブラックボックステストによって「承認」するよう割り当てられています。

結果の長さはパスワードの長さによって変わるため、パスワードは単純に難読化または暗号化されている(ハッシュされていない)と思います(いくつかの最小値がありますが、おそらく埋め込みですか?)。

ここにいくつかのデータがあります:

 password:結果
 1:TG3432WB7VU = 
 11:r8ahLkJGWbY = 
 111:E7fXdNqEWAA = 
 11111111: FIcx3a00R4eGhFyHjD56qw == 
 1111111111: FIcx3a00R4evxqEuQkZZtg ==
 2111111111:GPwnH80qEACvxqEuQkZZtg ==

結果は明らかにbase64ですが、読み取り可能なものにデコードされません。結果の長さが変わることを知る前に、デコードされたバイトを取得してMD5およびその他のハッシュ関数として処理しようとしましたが、明らかにうまくいきませんでした。結果の長さの変化がわかったので、他のより悪い代替案を検討しています。上記の2つの太字部分が注目に値します。これらは2つの異なるパスワードで同一です。したがって、各8バイトが個別に処理されている(理由)か、いくつかのポリアルファベット置換が行われている(?)のいずれかです。

更新:

Unicode文字を含むすべての文字が、システムでパスワードとして受け入れられます。 3バイト文字を8回繰り返すと、24バイト長の「ハッシュ」になります。

46
coldfused

私はこれが自転する方法であるか、少なくとも非常に古い方法であると強く疑っています。それは現代の基準では非常に弱く、重要なものを保護するために使用すべきではありません。

短いパスワードは2 ^ 64回のブルートフォース攻撃でクラックされる可能性があり、これは通常のコンピューターでも可能です。かなり長いパスワードを使用しても、結果の半分が独立している場合は、2 * 2 ^ 64のブルートフォース攻撃でクラックされる可能性があります(2 ^ 65回の試行)。アルゴリズムには、ここで説明するよりもさらに弱くする弱点がある可能性があります。

テストするもう1つの興味深いポイントは2111111111で、結果の2番目の部分が同じままかどうかを確認します。 2番目の部分が変わらない場合、これは明らかに弱いアルゴリズムです。

編集:

2111111111テストの結果が後半でも同じであることを見ると、これは明らかに弱いアルゴリズムであり、機密事項の保護には使用しないでください。以下に関連する比較を含めました:

  • 1111111111 : FIcx3a00R4evxqEuQkZZtg==
  • 2111111111 : GPwnH80qEACvxqEuQkZZtg==

編集:

別の興味深いテストは、Ricky Demerが以下で提案するものです。

次に確認することは、8バイトのブロックを同様に処理することです。 aaaaaaaabbbbbbbbcとbbbbbbbbaaaaaaaacの「ハッシュ」とは何ですか? – Ricky Demer 2月25日6:44

8バイトのブロックを同じように処理した場合、長さがどのようなものであっても、長いパスワードを使用した場合はさらに悪くなります。コメントでニールによって指摘されたように、それはたった2 ^ 64のブルートフォースの試みを必要とするでしょう。誰かが各可能性を計算するための表を作成すると、このアルゴリズムは実質的に役に立たなくなります。このアルゴリズムには、まだ発見されていない弱点があります。

最終行:

最後のテストの結果に関係なく、このアルゴリズムを使用することはお勧めしません。私たちはすでにそれが弱いことを知るのに十分を見てきました。より高いビット暗号化/ハッシュスキーム、ソルト、長い計算時間などを備えたものがはるかに優れています。既存の徹底的にテストされた方法のいずれかを使用することをお勧めします。自己ロール暗号化/ハッシュには、主なストリーム方式のほとんどが持っているような広範なテストの利点がありませんでした。

58
Jonathan

エンコードされた文字列の長さがそれぞれのパスワードの長さに依存するという事実は、はるかに悪い弱点を示唆しています:パスワードはハッシュされるのではなく難読化されているように見えます

これは、システムの内部を知っている誰もが即座にパスワードを解読できる可能性があることを意味します!その影響は数多くあります。システムに取り組んだことのある開発者を信頼する必要があります。ソースコードは永久に秘密にしておく必要があります(そのため、ブラックボックスを確認しています)。

難読化アルゴリズムがどれほど優れているかは重要ではありません(そして264 正確には恒星ではありません)。仕様により壊れています。

10

Kerckhoffs's_principle が適用されることは明らかです。キーを除くシステムに関するすべての情報が公開知識であっても、暗号システムは安全である必要があります。

これだけで、「情報がなければこのシステムを承認することはできません」と言うのに十分です。

あなたの例から、入力は8文字/バイトのブロックに分割され、各ブロックが個別にハッシュされ、出力がまとめられ、結果全体がbase64エンコードされているようです。

これは良くない。 8文字を超えるほとんどのパスワードは、数文字長くなります。これは、攻撃者が2番目のブロックを非常に簡単にクラックできることを意味します。そして、2番目のブロックを知っていると、最初のブロックに何を含めることができるかについての強いヒントがあります。

暗号化コミュニティはこの数十年前に発見し、ブロックを個別にハッシュしなくなりました。つまり、これらのプログラマーは暗号に関して最新ではありません[〜#〜] [〜#〜]

唯一の朗報は、パスワードを1文字変更すると、出力ブロック全体が変更されることです。これはおそらく、パスワードを難読化するだけでなく、実際にパスワードをハッシュ化していることを意味します。それでも、上記の弱点があるため、世界最高のハッシュ関数はアルゴリズムを保存できません。

5
Stig Hemmer

単純なブロック暗号のようで、間違いなく使用したくないものです。パスワードをハッシュする代わりに、単にbase64などでエンコード/難読化する場合と比較してください。これはあなたがしたいことではありません。誰かが単純な暗号解読を適用したとしても、彼らはbase64に使用されている十分な文字だけであることを簡単に見つけることができます。