Ever wonder why some old Windows passwords crack in seconds while others take forever? A lot of it comes down to how the password was hashed in the first place. And if you've spent any time around password recovery or legacy systems, you've probably run into the LM hash Practical, not theoretical..
Here's a question that sounds simple but trips people up: how many bytes is the output of an LM hash? Turns out the answer isn't just "16" — though that's where most people stop. The short version is that a raw LM hash produces 16 bytes, but the story around that number is messier than it looks.
Not the most exciting part, but easily the most useful.
What Is an LM Hash
An LM hash — that's short for LAN Manager hash — is a password hashing scheme Microsoft baked into early Windows systems. We're talking Windows 95, NT, 2000, and even later versions that kept it around for backwards compatibility. It's old. Like, genuinely ancient in tech years.
The way it works is ugly by modern standards. Your password gets converted to uppercase, truncated or padded to 14 characters, split into two 7-character chunks, and each chunk gets run through DES encryption using a fixed key. Each half spits out an 8-byte result Simple, but easy to overlook..
Quick note before moving on.
So when someone asks how many bytes is the output of an LM hash, the direct answer is 16 bytes total. This leads to eight from the first half, eight from the second. That's the raw binary output sitting in the SAM file or showing up in your hash dump.
Why It's Two Pieces
Look, the split isn't random. That's also why an LM hash is so weak: you can crack each 7-character half independently. So they chopped the password in half to fit the math. The designers back in the day were working with DES, which operates on 56-bit keys — basically 7 characters worth. The 16-byte output is really two separate 8-byte problems wearing a trench coat.
Where the 16 Bytes Live
In practice, you'll rarely see those 16 bytes as raw binary. Tools like Cain, Hashcat, or John the Ripper usually show LM hashes as a 32-character hexadecimal string. But the actual output of an LM hash is 16 bytes. Every byte is two hex chars, so 16 bytes becomes 32 characters. Day to day, not 32. The hex is just a representation Worth knowing..
Why People Care About LM Hash Size
Why does this matter? Because most people skip the difference between bytes and hex and then misconfigure their tools, misread their dumps, or write broken parsers That's the part that actually makes a difference..
If you're doing password auditing on a legacy network, knowing the LM hash is exactly 16 bytes tells you what to expect in the binary blob. If your extractor gives you 32 bytes, you've probably got something else mixed in — maybe the NT hash alongside it, or padding Simple, but easy to overlook..
And here's the thing — LM hashes were disabled by default from Windows Vista onward, but they still show up in enterprise environments with old policies, cached creds, or weird compliance setups. Day to day, i know it sounds like a solved problem. It isn't. Plenty of 2024 networks still leak LM hashes because nobody turned the policy off.
The Security Angle
The 16-byte output is small. That's why a 16-byte hash with the structural flaws LM has means brute force is trivial on decent hardware. Worth adding: you're not breaking cryptography — you're exploiting a bad design. Consider this: that's part of the weakness. Understanding the byte count helps you see why tools can precompute tables (like rainbow tables) so fast for these things.
How an LM Hash Is Generated
Let's walk through the actual process so the 16-byte answer makes sense. This is the meaty part.
Step 1: Normalize the Password
First, the password is forced to uppercase. In real terms, "PassWord123" becomes "PASSWORD123". Also, already a problem — you've cut the keyspace massively. Because of that, then it's either truncated to 14 chars or padded with nulls up to 14. No exceptions.
Step 2: Split Into Two Blocks
Those 14 characters become two 7-byte blocks. Worth adding: block one: chars 1–7. Block two: chars 8–14. If the password was shorter than 7 characters, the second block is just null bytes. That's why a password under 8 chars has a totally predictable second half in its LM hash — it's all zeros in that 8-byte chunk Simple, but easy to overlook..
Step 3: DES Encrypt Each Block
Each 7-byte block is used as a DES key to encrypt a fixed 8-byte constant (the string "KGS!Because of that, @#$%"). DES outputs 8 bytes per block. Two blocks in, two 8-byte outputs out.
Step 4: Concatenate
You glue the two 8-byte results together. Boom — 16 bytes. That's the output of an LM hash. No salt, no iterations, no stretching. Just 16 bytes sitting there asking to be cracked It's one of those things that adds up. Less friction, more output..
What About the Hex Form
When you run pwdump or pull from the registry, you'll see something like 299BD128C110C7A906BABC2158B7B952. Don't confuse the two. That's 32 hex chars = 16 bytes. If you see 64 hex chars, that's usually LM + NT hash paired. The LM portion alone is 16 bytes Simple as that..
Common Mistakes People Make With LM Hash Output
Honestly, this is the part most guides get wrong. They treat "LM hash" and "16 bytes" as the whole story and miss the context.
One mistake: calling the 32-character hex string "32 bytes". It's 16 bytes shown as text. It isn't. If you're writing code that allocates 32 bytes for an LM hash, you've doubled your buffer and your parser will break on real data Still holds up..
Another: assuming every Windows password hash is LM. Nope. Worth adding: nT hashes are 16 bytes too, but they're MD4-based and way stronger. That's why they look similar in dumps. You have to know which is which by context or tool output.
And here's a subtle one — some people think the 16-byte output includes a salt. Consider this: lM has no salt. That's why the same password always produces the same 16 bytes across machines. Practically speaking, wild, right? It doesn't. In practice that means one rainbow table cracks every LM hash of that password everywhere.
Mistaking Empty Passwords
A quirk worth knowing: if the password is empty, the LM hash is a fixed 16-byte value of all zeros. People see 32 zeros and think the account is broken. Tools sometimes show that as 00000000000000000000000000000000. It's just an empty password, represented as 16 zero bytes.
Practical Tips That Actually Work
If you're dealing with LM hashes today, here's what I'd tell a friend Simple, but easy to overlook..
Turn off LM hashing in your domain policy. On the flip side, use NoLMHash registry key or the Group Policy setting. It's a legacy holdover and the 16-byte output is a liability. Done.
When parsing dumps, allocate exactly 16 bytes for the binary LM hash. Because of that, if you're handling hex, parse 32 chars and convert. Don't guess Less friction, more output..
Use Hashcat mode 3000 for LM. It knows the structure, cracks each half separately, and will show you the 16-byte result properly. Don't write your own DES routine unless you hate yourself That alone is useful..
And if you're doing forensics, check for the LM hash even on "modern" images. I've seen Windows 10 machines with LM enabled because of a bad image template. The 16-byte artifact is small, but it tells a big story about the environment.
For Developers
If you're building a tool, validate length strictly. Expect 16 bytes binary or 32 hex. Worth adding: reject anything else loudly. Silent truncation is how bugs ship.
FAQ
How many bytes is the output of an LM hash? Exactly 16 bytes. It's two 8-byte DES outputs concatenated. In hex form it's 32 characters, but that's still 16 bytes of data And that's really what it comes down to. Surprisingly effective..
Is an LM hash the same size as an NT hash? Both are 16 bytes in binary. But they're computed completely differently. NT uses MD4 and is far more secure. Size alone won't tell them apart That's the whole idea..
Why is the LM hash so easy to crack? Because it's only 16 bytes, unsalted, uppercased, and split into two 7-char halves. Each half can be
brute-forced independently with a relatively small keyspace. That structural weakness is what lets older hardware crack LM passwords in minutes rather than days The details matter here..
Can the 16-byte LM hash ever be longer? No. The algorithm is fixed. If you see more than 16 bytes attached to what claims to be an LM hash, it's either padded, mislabeled, or bundled with other fields in a larger structure. The hash itself never grows Still holds up..
Do modern Windows versions still generate LM hashes by default? No. Since Windows Vista and Server 2008, LM hashing is disabled by default. But as noted earlier, misconfigured policies or legacy templates can re-enable it, so never assume it's absent without checking.
Conclusion
The LM hash is a relic of a simpler, less hostile computing era, and its defining trait—a fixed, unsalted 16-byte output—is also its greatest flaw. In practice, whether you're writing parsing code, conducting a forensic review, or hardening a domain, the rules are consistent: respect the exact size, never confuse it with NT, and eliminate it wherever you have control. Understanding those 16 bytes isn't just trivia; it's a small but critical piece of keeping legacy weaknesses from quietly undermining modern security No workaround needed..
People argue about this. Here's where I land on it.
