sha384(sha384_raw($pass)) Hash

Technical details, regex signatures, and cracking commands for the sha384(sha384_raw($pass)) algorithm.

Regex Identification Signature:
^[a-f0-9]{96}$
Not supported natively by Hashcat
John the Ripper Command:
← Back to Hash Identifier

What is sha384(sha384_raw($pass))?

SHA-384 is a member of the SHA-2 family of cryptographic hash functions, standardized as part of FIPS 180-4 by the U.S. National Institute of Standards and Technology (NIST) in 2015. It extends the bit-length of its predecessor, SHA-256, to 384 bits by doubling the internal state size (from 512 to 1024 bits) and increasing the number of compression rounds (from 64 to 80). The algorithm follows a Merkle-Damgård construction, processing input data in fixed-size blocks via a series of bitwise operations (Ch, Maj, Σ₁/Σ₀, and ROTR), with a final padding step to ensure uniform output length. Its primary use-case lies in generating fixed-length digests for integrity verification, digital signatures (e.g., via ECDSA with SHA-384), and as a building block in key derivation functions (KDFs) like HKDF or PBKDF2, where its increased collision resistance mitigates certain security trade-offs compared to shorter hashes. The notation `sha384(sha384_raw($pass))` represents a nested hashing scheme: the raw password is first hashed via SHA-384, and the resulting 384-bit output is then hashed again, effectively doubling the computational effort and reducing the effective output entropy to 384 bits (though the second hash’s input is deterministic).

The vulnerability of this format stems from several architectural and implementation flaws. Firstly, the absence of a cryptographic salt exposes the hash to rainbow table attacks, as identical passwords produce identical outputs. Secondly, SHA-384’s design, while resistant to classical collision attacks (owing to its 384-bit output), is susceptible to **preimage attacks** when nested—each SHA-384 iteration halves the effective security margin (from ~192-bit to ~192-bit total, despite 384-bit outputs), making brute-force recovery feasible with optimized hardware. Modern GPUs and FPGA-based cryptanalytic platforms (e.g., Hashcat’s SHA-384 kernels) exploit parallelizable compression rounds, achieving terahashes-per-second (TH/s) rates, which render nested SHA-384 impractical for password storage. Additionally, the lack of adaptive resistance to side-channel attacks (e.g., timing or power analysis) further compromises real-world security, as attackers can exploit implementation quirks to infer intermediate states. Finally, the format’s reliance on raw password input without key stretching (e.g., Argon2 or PBKDF2) renders it vulnerable to GPU-accelerated cracking even when nested, as the computational overhead is linear rather than exponential.

Identifying sha384(sha384_raw($pass)) Hashes

Identifying a hash blindly is often difficult because multiple algorithms can output strings of the exact same length. For example, a standard 32-character hexadecimal string could be MD5, NTLM, MD4, or LM. To definitively identify sha384(sha384_raw($pass)), security researchers analyze the hash against a strict regular expression (regex) signature (shown above) to find structural matches.

How to Crack sha384(sha384_raw($pass))

If you need to recover the plaintext password for a sha384(sha384_raw($pass)) hash during a penetration test or forensics investigation, you must supply the correct module ID to your cracking software. Use the exact commands provided at the top of this page to target the hash successfully.