暗号化識別子

識別子が使用する署名パターン

長さに基づく判定（16進数でエンコードされたハッシュの場合）：

56文字のSHA-224や96文字のSHA-384など、他の長さの文字列はハッシュとして認識されません（56文字または96文字の16進文字列はBase64と判定されます）。

プレフィックスに基づく判定（認識されるのはbcryptのプレフィックスのみ）：

• $2a$ $2b$ $2y$ bcrypt

その他のcrypt形式のプレフィックス（$1$、$5$、$6$、$argon2i$、$argon2id$、$pbkdf2$）は認識されません。

エンコーディングに基づく判定：

• すべての文字が [A-Za-z0-9+/=] に含まれ、長さが4の倍数の場合：Base64の可能性が高い。
• . で区切られた3つのセグメントがあり、各セグメントが [A-Za-z0-9_-] で構成される場合：JWT。

PEMラッパー、OpenSSHの ssh-rsa/ssh-ed25519 ブロブ、- や _ を含むBase64url文字列は検出されません。

識別でわからないこと

• 100%確実な正確なアルゴリズム。 64文字の16進数文字列はSHA-256と判定されますが、SHA3-256やBLAKE2sの可能性もあります。これらは暗号文だけでは区別できません。NTLMハッシュ（これも32文字の16進数）はMD5と見た目が同じです。
• 鍵の強度。 bcryptハッシュはプレフィックスにコストファクターが示されますが（$2y$10$ = コスト10）、元となるパスワード自体の強度はわかりません。
• ソルトが付与されているかどうか。 最新のパスワードハッシュ（bcrypt、Argon2）は常にソルト付きですが、古い方式（生のMD5/SHA）は付いている場合とそうでない場合があります。
• 平文。 識別ではハッシュを逆算できません。解読は別のプロセスであり、自分が所有するデータに対してのみ合法です。

識別子が誤る場合

• 独自のプレフィックスが付いたトークン。 アプリが独自のプレフィックスでハッシュをラップしていることがあります。まずそのラッパーを取り除いてください。
• 二重エンコード。 バイナリハッシュを16進数化し、さらにBase64でラップしたものは誤って識別されます。一度デコードしてから再実行してみてください。
• 異常な長さ。 切り詰められたハッシュ（SHA-256の先頭16文字をIDとして使用したものなど）は、文字と長さのルールが重なるため「Base64」と表示されます。
• 枠付きやラップされた形式。 PEMブロック、OpenSSHキー、Djangoの pbkdf2_sha256$... は認識されません。ラッパーまたはプレフィックスを取り除いて再試行するか、専用のパーサーを使用してください。

ユースケース

• セキュリティ監査：暗号方式の移行前に、コードベース全体のハッシュ種別を洗い出す。
• CTFチャレンジ：未知のデータに対する素早い初回チェック。
• インシデント対応：漏洩した認証情報の形式を特定する。
• フレームワークのデバッグ：ライブラリがどのエンコーディングを生成するかを突き止める。

倫理に関する注意

ハッシュ形式を特定することは受動的な調査にすぎません。許可なく他人のハッシュを解読する行為は、ほとんどの法域でコンピュータの不正利用に関する法律に違反します。自分が所有する、または分析を許可されているハッシュのみを対象にしてください。