How Windows XP SAM Stored Encrypted Passwords

In Windows XP, the Security Accounts Manager (SAM) database secured local account credentials through a multi-layered cryptographic pipeline rather than storing plaintext passwords. Windows XP converted user passwords into two distinct cryptographic hashes—LM and NTLM—which were then encrypted using keys derived from the account's Relative Identifier (RID) and further encrypted using a system-wide Password Encryption Key (PEK) secured by Syskey. This process ensured that raw credential hashes remained protected even if an unauthorized user gained read access to the raw registry files.

1. Generating Password Hashes (LM and NTLM)

When a user created or changed a password in Windows XP, the operating system generated two separate hashes:

  • LAN Manager (LM) Hash: The password was converted to uppercase, truncated or padded to 14 characters, and divided into two 7-byte halves. Each 7-byte half was converted into a 56-bit DES key used to encrypt the constant string KGS!@#$%. The two resulting 8-byte ciphertexts were concatenated to form the 16-byte LM hash. Due to its lack of case sensitivity, 7-character chunking, and reliance on single-DES, the LM hash was notoriously vulnerable to brute-force and rainbow table attacks.
  • NTLM Hash: To mitigate LM weaknesses, Windows XP simultaneously computed the NTLM hash. The system encoded the original password (case-preserved) into Little-Endian UTF-16 and passed it through the MD4 hashing algorithm, producing a 16-byte digest.

2. Syskey and the Password Encryption Key (PEK)

Windows XP enabled Syskey by default to encrypt password hashes stored within the SAM. The core of this system was the Password Encryption Key (PEK), a 16-byte key generated during installation.

  1. Syskey Generation: The Syskey itself was a 16-byte key derived by default from four registry keys inside the SYSTEM hive: JD, GBG, Data, and Skew1 located under CurrentControlSet\Control\Lsa.
  2. PEK Encryption: The PEK was stored within the F binary value of the HKLM\SAM\SAM\Domains\Account registry key. It was encrypted using RC4 (or 3DES), where the encryption key was derived by computing an MD5 hash of the Syskey combined with a salt.

3. Account-Level Hash Encryption in the V Value

Each local user account possessed an entry in the SAM database located at HKLM\SAM\SAM\Domains\Account\Users\<RID_in_HEX>. Inside this key, the binary V value contained user metadata and the encrypted credential hashes. Storing the hashes followed a two-step encryption routine:

Step A: PEK Encryption

The 16-byte LM and NTLM hashes were first encrypted with the PEK using RC4. To ensure that identical passwords across different accounts generated distinct ciphertexts, Windows XP generated a 16-byte salt for each hash and combined it with the PEK through MD5 to form the RC4 session key.

Step B: RID-Based DES Obfuscation

Before being finalized into the V value, the encrypted hashes were obfuscated using the account's Relative Identifier (RID):

  1. The 32-bit RID was used to derive two separate 7-byte DES keys:
    • DES Key 1 was built using the formula: (RID % 0xFF) + (RID >> 8) + (RID >> 16) + (RID >> 24).
    • DES Key 2 was constructed similarly with alternative bit shifts.
  2. Each derived key encrypted an 8-byte segment of the 16-byte hash structure using the DES algorithm.

Summary of the Storage Chain

The final stored password representation in the Windows XP SAM registry followed this structural flow:

Plaintext Password → LM / NTLM Hash → PEK (RC4 + Salt) Encryption → RID-Derived DES Encryption → Stored in the 'V' Registry Value

Only the Local Security Authority Subsystem Service (LSASS), running with kernel-level permissions, had access to decrypt and verify these credentials during user logon.