Passwords are not stored in the SAM security hive, per se. What is stored there
is a one-way hash of the password. In fact, until very recently, two separate
one-way hashes were always stored on the server - a Lan Manager hash required by
Win3.x, Mac clients, & OS/2 clients; and a NT hash which could be used by NT
workstations only. Lan Manager clients (Microsoft & IBMs legacy network
operating systems - preNT) support a max 14-character password. Any password
less than 14 characters is concantenated with 0's (ie jim becomes
jim00000000000). It is converted to upper case (jim00000000000 becomes
JIM00000000000), and split into two parts. An 8 byte odd parity DES key is
constructed from each 7 byte half. Each 8 byte DES key is encrypted with a magic number (0x4B47532140232425 encrypted with a key of all
1's). The results of the magic number encryption are concantenated into a 16
byte one way hash value. This value is the Lan Manager password
See the weakness inherent in LANMAN hashes? Since the two halves of the
password are hashed separately, if the password is 7 or less characters in
length, the last half is always the same hash - the result of operating on
0000000. People are lazy about such matters. Unless forced, they will use short
passwords. Thus a hacker only has to work on a 8byte hash. To add insult to
injury, LANMAN passwords are all forced to upper case. This eliminates half of
the possible passwords (if non-alpha characters are not required). This makes
the lanman hash very vulnerable to brute force dictionary guessing attacks.
NT-type passwords are derived by converting the user's password to Unicode,
and using MD4 to get a 16-byte one-way hash. The MD4 algorithm is in public
domain. Its used by NT & most unix variants. The algorithm for LANMAN hash
created is presented above.
One-way hashes are named one-way because they can not be reversed. This has
been mathematically proven. So you get a copy of the SAM database and extract
the one-way hashes. You can't reverse the process to get the hash converted back
to the original password string. You don't have to do something so difficult.
Since you know the algorithm, take a dictionary, feed the words through a
hash making program developed from these algorithms and compare the hashes from
the SAM with the hashes you are creating from your word list. Or use one of the
many programs downloadable from the Internet.
This reveals the weakness in 'NT' passwords. What would you do to make this
- Use alt-characters. These may be unbreakable.
- Eliminate LANMAN hashes. Great if you are allowed to mandate only NT
- OPPS. Even then LAN hashes are generated. Microsoft has introduced keys to
strengthen NT's hashes and eliminate LANMAN hashes when desired.
See NTLMv2 and embedded references.
- Encrypt the one-way hashes in the SAM. Admins rarely take appropriate
security precautions with the ERD (emergency repair disks) and backup tapes
which have the security db on them - keeping them in their office or other
low-security locations. A post SP2 hot-fix, syskey
carried forward in later SPs, gives admins much more protection. Syskey
independently encrpts the hashes so that physical access to the server, tapes,
or ERDs is only first step to cracking the passwords. They have to break through
the 128-bit encryption used by syskey before they can attempt brute force
dictionary attacks on the hashes. Sniffer capturing of hashes transmitted over
the network are still a major danger unless you are using stronger versions of
ERD Related Tips:
- NT ERD - never there when you need it
- Contents of NT ERD
- Steps Performed by the Emergency Repair
- Disable a Service or Device that Prevents
Windows NT from Booting
- Cracking Windows NT passwords
- Using the
Emergency Repair Disk to Fix Windows NT Problems
- Repair Disk
Secrets Reduce Downtime
Available for RDISK Registry Enumeration File" Vulnerability
Also see tip: Recover Lost
Windows NT Administrator Password
A vulnerability was discovered in Syskey and Microsoft has provided a patch.