web-dev-qa-db-ja.com

ラウンド長が不明なため、ハッシュを解読できませんか？

だから私は婚約していて、いくつかのハッシュをつかみましたが、それらをクラックすることは役に立ちませんでした。ハッシュタイプ（PBKDF2-HMAC-SHA256）は知っていると思いますが、どのラウンドサイズを使用したかはわかりません。これは私にこれをクラックすることを不可能にしない、または私が何かを見逃しているのではないかと私に考えさせました。なぜなら、平文のパスワードとソルト（明らかに非常に不自然なシナリオ）を知っていたとしても、使用するものが見つかるまですべてのラウンドサイズを試す必要があるからです。

この考え方は正しいですか、それとも何か不足していますか？

編集：これは振り返る重要な情報であり、ラウンドが欠落していることについての混乱をお詫び申し上げます。アプリケーションは、JSONオブジェクトの2つの異なる部分でハッシュを返します。 {...、 "パスワード"： "（Base64encoded（27文字））"、 "PasswordSalt"： "（Base64encoded（24文字））" 、...}。これが、ハッシュにラウンド識別子が含まれていない理由です。

したがって、PBKDF2-HMAC-SHA256は、アプリケーションの別の部分にパスワードを保存する方法に由来し、OSINTを通じてそれを見つけることができました。パスワードの長さを見て、Python passlibで遊んでいるようですコミュニティが言ったように、100,000ラウンドは前代未聞ではなく、悲しいことに、彼らはデフォルトの29,000を使用していません。

編集編集：既知のパスワードをハッシュに対して1〜100,000回実行しただけで、ヒットしませんでした。 Sha1であるという私の直感は間違っていたようです。同じアプローチでSHA-256を試します。

編集編集：まあ私の希望はすぐに枯渇しています。私はSHA_1、256、512をすべて1から100,000ラウンドまで試しましたが、どれも私のハッシュに一致しません。ハッシュの長さと値は説明と完全に一致しているように見えますが、実験は異なることが判明しているようです。

これは実際にはプログラミングフォーラムではないことはわかっていますが、完全を期すために、生成されたすべてのハッシュに対してハッシュをチェックするために使用していたコードを示します。

import concurrent.futures
global quit
from passlib.hash import pbkdf2_sha512
quit = False

def hasher(round, quit):
    if(not quit):
        hash = pbkdf2_sha512.using(salt=(passlib.utils.binary.ab64_decode('xpN14Zl95QQNOKffgsERSw==')), rounds=round).hash('Password').split('$')[-1]
    if(hash[0:5] == '278Vu'):
        print(round) #found it
        quit = True
    if(round % 5000 == 0):
        print(round) #status update


exec = concurrent.futures.ThreadPoolExecutor(max_workers=4)
print("Execing")
for i in range(1,100001):
    exec.submit(hasher,i, quit)

EDIT EDIT EDIT：ハッシュ識別子ツールがここにあるようです https://github.com/psypanda/hashID はそれらをPeoplesoftパスワードとしてラベル付けしています。アプリケーションがどこでもpeoplesoftを使用していないように見えるため、これが誤検知であるかどうかはわかりません。また、Peoplesoftのハッシュは塩漬けされておらず、私の塩分が返されたようです。この件に関する投稿が1つあります https://hashcat.net/forum/thread-6639.html ですが、あいまいです。これに関して何か助けはありますか？

hashpassword-crackinghashcat
1
staticFlow

これは通常、ひび割れに対する穏やかな一時的な障壁にすぎません。

ラウンド数を取り去ることは、あいまいさの薄い層になります。そのようなハッシュが作業を行うことができる唯一の方法は、ソフトウェアにラウンド数を決定するハードコーディングされた方法またはアルゴリズム的な方法がある場合です。そのため、そのソフトウェアを単純にリバースエンジニアリングして、ラウンド数を検出できます。

それもかなり珍しいでしょう。丸めを使用するほとんどのハッシュ形式には、ハッシュ自体の一部として丸めの数が含まれます（この例では、「 （hashcatの例」のハッシュのリスト から取得した） "1000"）：

sha256:1000:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

つまり、最も簡単な回避策は、多くのラウンド数を持つハッシュのバージョンを単に生成することです。

sha256:1:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:2:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:3:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:4:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:5:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

...そして、それらすべてをクラッキングソフトウェアにすべてフィードします。 （このハッシュ形式のラウンド数は可変になるように設計されているため、クラッキングソフトウェアはこれをうまく処理できます。）

とはいえ、通常、ラウンド数には実際的な上限があります。それを超えると、インタラクティブユーザーがパスワードの確認を待つのに耐えるのに時間がかかりすぎます。 100,000ラウンドはかなり珍しい しかし不可能ではない 。しかし、これがカスタムのカスタムアプリケーションである場合、異常に多いラウンド数が許容される可能性があります。したがって、特注のアプリケーションの場合、ラウンド数を「非表示」にしようとすると、攻撃者にとって少し難しくなる可能性があります。また、PBKDF2はかなり遅いハッシュであるため、防御側がかなりの数のラウンドを選んだと仮定すると、このアプローチは実際に事態を難しくする可能性があります。

したがって、一般的なワードリストと攻撃を使用して、1から50,000までのラウンドに対する攻撃が1日か2日で結果をもたらさなかった場合...私はそれが異なるハッシュタイプである可能性があると考え始める傾向があります-そしておそらく、ハッシュを生成/検証するソフトウェア/ファームウェアを取得し、それをリバースエンジニアリングすることも試みます。実際、クラッキングジョブが完了するのを待っていたのはなぜかと思います。 :)

1
Royce Williams