How Windows Stores Passwords: LM, NTLM, and the SAM
2026-10-21 · 6 min read
Figure 1: LM and NT hashes, stored in the SAM or NTDS.dit
The hashes behind every Windows login
Windows never checks your typed password against stored text. It keeps a hash and compares against that, and where those hashes live, and how they are built, explains a long list of attacks from offline cracking to pass-the-hash. Knowing the layout is the first step to defending it.
Here is where the secrets sit and what shape they take.
Where the hashes live
On a standalone or local machine, account hashes sit in the SAM, a registry hive locked while Windows runs. On a domain controller they move into a database called NTDS.dit, which holds every domain account in one file. Pulling hashes from either needs high privilege, but once an attacker has it, the whole account list is exposed at once. The SAM dump parser reads the format these dumps arrive in.
LM hashes and why they are a gift to attackers
Old Windows stored a second hash called the LM hash, and its design is almost a lesson in how not to protect a password:
- The password is forced to uppercase, shrinking the pool of possibilities.
- It is split into two seven-character halves, each hashed on its own, so a 14-character password is really two tiny puzzles.
- Each half runs through DES, with no salt.
Together these let LM hashes fall in seconds. Modern Windows disables LM storage, but you still meet it on legacy systems and in old dumps.
The NT hash
The NT hash replaced it and is what Windows uses today. It is the MD4 of the password encoded as UTF-16 little-endian, a 32-character value, covered in detail in our NTLM hash guide. It drops LM's worst habits, no uppercasing and no splitting, but it stays unsalted and fast, so a weak password behind it cracks quickly all the same.
Reading a dumped hash line (worked example)
Hashes usually appear in the pwdump format, one account per line with fields split by colons:
Administrator:500:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::Reading left to right: the username, the RID (500 is the built-in administrator), the LM hash, then the NT hash. Here the LM field is aad3b435b51404eeaad3b435b51404ee, the fixed value that means LM storage is turned off, and the NT hash is 8846f7eaee8fb117ad06bdd830b7586c, which is simply the NT hash of the password password. Feed a line like this to the SAM dump parser and it splits the fields for you, or check the format with the hash identifier.
LM is disabled now, but the NT hash remains
Seeing that aad3b435... placeholder is good news, because it means no LM weakness. The NT hash beside it is still sensitive, though, since the Windows protocol will often accept the hash itself in place of the password. That replay trick, pass-the-hash, means a stolen NT hash can log in without ever being cracked.
How to defend
- Enforce long, unique passwords so an unsalted NT hash resists cracking.
- Confirm LM storage is off across the estate; the placeholder above is what you want to see.
- Limit who can read the SAM and NTDS.dit, since that access is the whole prize.
- Separate admin accounts so one cracked or replayed hash does not open everything.
The takeaway
Windows keeps an LM hash and an NT hash, stored in the SAM locally or NTDS.dit on a domain controller, and both are unsalted. LM is a relic you want disabled, while the NT hash stays a live secret that can be cracked or replayed. Strong passwords, LM turned off, and tight access to the hash stores are what keep the login secrets safe.