HMAC Generator

A plain hash takes one input, so anyone can compute it. That catches accidental corruption and nothing else — someone who alters the message can recompute the digest to match. An HMAC mixes a secret key into the same hash function, so only a holder of the key can produce or check the value, which is why it counts as authentication rather than a checksum. The construction also closes a weakness in the obvious approach of sticking a key on the front of a message: SHA-256 and SHA-1 are open to length extension there, and their HMAC forms are not.

Usually the message, not the maths. Production code must hash the exact raw request bytes before JSON parsing or middleware changes them — reordered keys, one space or CRLF becoming LF produces a different digest. A browser textarea cannot preserve every raw byte or CRLF sequence, so compare here only when the provider's fixture is defined as UTF-8 text. Also check whether the scheme prepends a timestamp or canonicalises the method, path and headers, whether the key is raw bytes rather than displayed hex, and whether the expected digest is hex, Base64 or Base64URL.

Not in the way the bare hashes are. MD5 and SHA-1 are unfit for certificates and signatures because collisions can be manufactured to order, and the HMAC construction does not lean on collision resistance in the same way, so neither has fallen in practice — the six-digit codes from an authenticator app are HMAC-SHA1. That is a reason not to panic about an integration you have inherited, rather than a reason to pick either for something new. For anything new, HMAC-SHA256 is the default: supported everywhere and no harder to implement.

There is nowhere for it to go: the computation happens in the tab as you type, with no upload step and no request leaving the page. That covers the tool, but not everything else in the path. A production secret you have pasted has been through your clipboard, which other applications can read and which may sync between your devices, and it can linger in browser form history depending on your settings. The safer habit is to reproduce the problem with a throwaway key and a sample message, and leave the live secret where it already lives.

The usual guidance is at least the length of the hash output — 32 random bytes for SHA-256, 64 for SHA-512. Going past the hash's block size buys nothing, because the construction hashes an over-long key down first. What matters far more is that the key is random rather than chosen. A memorable phrase used as a signing secret can be guessed offline at speed: an attacker holding one message and its digest tests candidates locally, without ever contacting you. Generate it from a cryptographic random source, and keep it out of the repository.

Whichever the other side expects; they carry the same bytes and neither is more secure. Hex is twice the length of the raw digest and completely unambiguous, which is why most signature headers use it. Base64 is about a third shorter and turns up where size matters or the surrounding format is already Base64. The trap is the variants: standard Base64 uses plus and slash and pads with equals signs, while the URL-safe form substitutes hyphen and underscore and often drops the padding, so a value can be the right digest and still fail a comparison.

No. It rests on a hash function, which is one-way by design, and the output is a fixed size no matter how large the input — a short line and a large file both reduce to 32 bytes under SHA-256, so most of the input is not in there to recover. Guessing is a different matter. Where the set of possible messages is small, someone holding the key can enumerate them and match digests; where the key is weak, someone holding a message and its digest can do the same to the key.

Ordinary comparison stops at the first differing byte, and how long that took leaks how many leading bytes were right. Someone who can submit guesses and measure the response can then recover a valid signature a byte at a time, turning a hopeless search into a short one. Use the constant-time comparison your language ships — compare_digest in Python, timingSafeEqual in Node, hash_equals in PHP — on the raw bytes or a consistent encoding, since those functions expect equal lengths. Eyeballing two strings while debugging is fine; it is the code running on every request that matters.