Developer tools · SHA hash calculator
Length Extension Attacks: Why SHA-256(secret + message) Is Not a MAC
· Why it matters
sha-256 cryptography security
Prepending a secret to a message and hashing it looks like authentication, but SHA-256's structure lets an attacker extend the message without knowing the secret. This post explains the attack and the fix.
The homemade request signature — hash(secret + body) and why it feels secure
A developer needs message authentication but lacks the HMAC knowledge, so they concatenate a secret with the message and hash the result. This approach looks secure at first: the output is a fixed-size fingerprint that should change if anyone modifies the message. However, SHA-256 has an architectural flaw called length extension that lets an attacker append data to the message and compute a valid digest without knowing the secret. The ToolAcre SHA hash calculator computes plain digests only, not keyed authentication, because this distinction matters for real security.
Prepending a secret before hashing is intuitively appealing because only the secret holder can recompute the hash. If the message changes, the hash changes too, so it looks like a proof of authenticity. An API might sign requests by concatenating a shared secret and the request body, then hashing the result and including that hash in the request. The server receives the body, recomputes the hash with its copy of the secret, and checks whether it matches. If an attacker changes the body, the hash will not match—or so developers think.
Merkle–Damgård leaks its state — the final digest is the internal state, so an attacker can keep hashing from where you stopped
SHA-256 belongs to a family called Merkle–Damgård hash functions. These functions process input in fixed-size blocks, chaining a compression function that takes the previous state and the current block and outputs a new state. The compression function is the only cryptographic primitive inside; the chaining strategy and padding scheme make the whole construction work. The final digest is simply the final state printed in hexadecimal. This is not incidental: the output is the internal state. Anyone who sees the digest has the exact state needed to continue hashing from that point.
To extend a message, an attacker starts with the observed digest of secret + original_message and treats it as the state variable for a new compression function call. They append the data they want to add, pad it correctly for the full new message length, and compute the digest. When the server validates this forged digest by prepending its own secret and hashing, the computation proceeds identically to the attacker's calculation after the initial secret was absorbed. The server computes the same digest, and the forged message is accepted without the attacker knowing the secret at all.
How the extension works — appending padding and extra data to forge a valid hash for a longer message
Different algorithms are affected differently by length extension. SHA-1 is vulnerable: an attacker can observe a SHA-1 digest and extend the message. SHA-256 is vulnerable in exactly the same way. SHA-512 is also vulnerable to extension attacks. SHA-384 resists length extension because it is constructed as SHA-512 truncated to 384 bits. The compression function output is longer than the published digest, so the attacker does not have enough information to continue hashing. The sponge construction used in SHA-3 also resists because it does not leak the internal state.
Understanding which algorithms are vulnerable requires knowing something about the compression function size versus the published digest size. SHA-256 publishes 256 bits and the compression function state is also 256 bits, so the digest is the entire state. An attacker has everything needed to continue. SHA-384 publishes 384 bits, but the underlying compression function state is 512 bits because SHA-384 is built on top of SHA-512. The digest only reveals 384 of those 512 bits, leaving 128 bits unknown to an attacker. This is an intentional design property of SHA-384 that provides this resistance.
The supported SHA-1, SHA-256 and SHA-512 constructions expose full state; SHA-384 truncation changes the extension boundary
The fix for authenticating messages with a shared secret is HMAC, the keyed-hash message authentication code. HMAC does not prepend the secret and hash; instead, it applies the secret in two nested hash operations using specific padding schemes called the inner and outer pads. The construction is HMAC(secret, message) = SHA256(secret_XOR_outer_pad, SHA256(secret_XOR_inner_pad, message)). This nested approach closes the length extension gap because even if an attacker has the digest of the inner hash, they cannot continue hashing without the secret.
The reason to keep digest and HMAC operations separate is to avoid the common mistake of treating the two interchangeably. A developer who learns about hashing through a tool that does both might forget which one they are using when they write code. Keeping digest computation separate makes the choice explicit and reinforces the learning that authentication needs HMAC or signatures. The ToolAcre SHA hash calculator labels plain digests clearly, and documentation explains that HMAC is a different operation entirely.
HMAC as the fix — the nested construction that closes the gap and why it is the standard answer
A conceptual example of length extension works on the familiar test vector abc. Computing SHA-256 on the ASCII text abc produces the digest ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. Suppose this digest is the result of secret + abc hashed with a 5-byte secret, giving a total of 8 bytes of input. SHA-256 processes input in 64-byte blocks, so the first and only block was padded with the message length and other padding bytes. An attacker sees the digest and wants to forge a message starting with abc followed by extra data.
They cannot directly append to abc because they do not know the exact padding that was added inside the hash. However, they can compute what the full padded message must have been: abc plus the required padding for an 8-byte input to a 64-byte block. They then append their extra data, compute the padding for the new total length, and hash the combination by treating the observed digest as the starting state. The result is a valid SHA-256 digest that the server will accept because it prepends the secret and computes the same hash.
Worked example — a conceptual walk-through of extending a signed message, without a live target
To prevent this attack in a real system, the developer should not try to build authentication from a plain hash. HMAC is the standard answer, and the ToolAcre SHA hash calculator is a tool for computing plain digests for integrity checks, content hashing and similar non-authenticating purposes. Examples of safe uses of plain SHA-256 digests include file checksums, where an attacker cannot control both the file and the digest; content-addressable storage, where the hash is the lookup key; and digital signatures combined with signatures, where the signature provides authentication.
The full scope of this issue includes the other algorithms that the browser provides. SHA-1 is vulnerable to length extension and was already cryptographically broken before that became relevant. The ToolAcre calculator labels SHA-1 as legacy-only and explains the collision attacks that have made it unsuitable for new applications. For new applications, SHA-256 is the sensible choice for plain digests, and if authentication is needed, HMAC with SHA-256 is the answer. SHA-384 and SHA-512 are both vulnerable, but SHA-384 is protected by truncation.
What this does not cover — the ToolAcre calculator computes plain digests, not HMAC; the post explains why that distinction matters
When building the mental model of hash functions, the Merkle–Damgård construction and length extension become the key concepts. A hash function must handle arbitrary input lengths and produce fixed output. The way it does this is by chaining a compression function block by block, and the way the final state is converted to output matters tremendously. If the final state is output entirely, then that output contains all the information needed to continue hashing. If the final state is truncated, part is hidden.
For a developer reading about length extension attacks for the first time, the question is how to know whether it affects their use case. If the input to the hash is a public constant and the hash is used as a lookup key or a fingerprint, length extension is irrelevant. If the hash is used to authenticate a message when both parties share a secret, length extension is a critical vulnerability, and HMAC is the fix. The ToolAcre SHA hash calculator displays digests and byte counts, making it clear that these are computational outputs, not authentication mechanisms.
Takeaway: use a MAC for authentication — the ToolAcre SHA hash calculator is for integrity digests; authentication needs HMAC or a signature
Applying this to production systems, the principle is straightforward: never use a bare hash for authentication when a secret is involved. HMAC is the standard construction that closes the length extension attack vector entirely. SHA-256 and SHA-384 are both secure for their intended purposes when used correctly. Understanding the three key points—that Merkle–Damgård reveals its state in the digest, that SHA-384 truncates to hide part of the state, and that HMAC uses a nested construction to prevent extension—gives a developer the tools to make the right choice.
The ToolAcre SHA hash calculator embodies this teaching: it provides plain digests for learning and for legitimate non-authenticating uses, it labels SHA-1 as legacy, and it does not implement HMAC because that operation belongs in a different context. When developers reach for a plain hash calculator to authenticate a request, the tool's positioning and documentation guide them toward HMAC and signatures as the proper tools. The ToolAcre toolkit focuses on what the browser's Web Crypto provides directly and explains the boundaries where each primitive is appropriate.