bcrypt(SHA-256) Hash

Technical details, regex signatures, and cracking commands for the bcrypt(SHA-256) algorithm.

Regex Identification Signature:
^\$bcrypt-sha256\$(2[axy]|2)\,[0-9]+\$[a-z0-9\/.]{22}\$[a-z0-9\/.]{31}$
Not supported natively by Hashcat
Not supported natively by John the Ripper
← Back to Hash Identifier

What is bcrypt(SHA-256)?

The hybrid cryptographic hash format **bcrypt(SHA-256)** combines the adaptive key derivation function *bcrypt* with the cryptographic hash function *SHA-256*, though its design is fundamentally flawed due to the misuse of SHA-256 as a post-processing step rather than a core component. Originally conceived as a defense against brute-force attacks, bcrypt was introduced in 1999 by Niels Provos and Solar Designer to mitigate the computational efficiency of password storage by introducing a computationally expensive hashing process with a variable cost factor (the *work factor*, *N*), exponential backoff, and a fixed-length salt. However, the "bcrypt(SHA-256)" variant—often misrepresented as a true hybrid—actually applies SHA-256 *after* bcrypt’s core hashing loop, effectively reducing it to a post-hash transformation rather than a true composition. This format is primarily deployed in legacy systems or misconfigured implementations where developers mistakenly assume SHA-256 enhances security, though its security guarantees rely solely on bcrypt’s original design, with SHA-256 serving only as a redundant (and unnecessary) digest function. The primary use-case remains password storage, but its hybrid mislabeling obscures its true vulnerability profile.

The "bcrypt(SHA-256)" format is vulnerable to cracking due to several architectural flaws rooted in its misuse of SHA-256 and bcrypt’s inherent limitations. First, the post-SHA-256 transformation introduces no meaningful security benefit, as SHA-256’s collision resistance is irrelevant when the primary security relies on bcrypt’s work factor—making the hybrid effectively equivalent to plain bcrypt in practice. Second, the absence of a cryptographically secure salt derivation (if not properly implemented) exposes stored passwords to rainbow table attacks, though bcrypt’s built-in salt mitigates this risk if used correctly. More critically, bcrypt’s fixed output length (60-byte hashes) and reliance on a single cost parameter (*N*) make it susceptible to GPU/ASIC optimizations, as adversaries can parallelize brute-force attacks across thousands of cores. Additionally, the exponential backoff in *N* (which scales poorly) and the lack of adaptive resistance to quantum computing render it obsolete for modern threat models, particularly when paired with an unnecessary SHA-256 layer that does not address these weaknesses. Finally, the format’s ambiguity in documentation fosters implementation errors, such as insufficiently large salts or incorrect parameter handling, further weakening its defenses.

Identifying bcrypt(SHA-256) 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 bcrypt(SHA-256), security researchers analyze the hash against a strict regular expression (regex) signature (shown above) to find structural matches.

How to Crack bcrypt(SHA-256)

If you need to recover the plaintext password for a bcrypt(SHA-256) 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.