Windows 2003 Password Encryption

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I am working on a NT 4 - Windows 2003 Active Directory migration. I am
interested in finding out information about the hashing algorithm used when
storing user passwords in Active Directory.

The Windows 2003 AD implementation will be supporting NT 4, Windows 2000 and
XP clients so will be using Kerberos and NTLM v2 for authentication.

Does anyone know the following information:

Which algorithm is used to hash a user password before it is stored in
Windows 2003 Active Directory (via Kerberos and NTLM v2)?

Does Windows 2003 use salting before applying the hash? (i.e add the user
id to the password before hashing)

How many times is the hash applied to the password when encrypting the
password in Windows 2003 Active Directory?

Also could you point me to resources to confirm this, I cannot seem to find
resources on the web that defines this.

Thanks in advance.

S
 
Hi,

Windows can store passwords in two ways. LM Hash (weak) or NT Hash (pretty
strong if users can come up with a good strong password).

For LM Hash -- among other things DES is used to create a hash
For NT Hash - MD4 is used

Salting is not used when storing the passwords - hashes. Yes all Windows
computers will create same hash for same password. You can actually buy
on-line pre-computed hashes (but to store all possible combinations for LM
Hashes it would take 166 Terabytes of space and for all possible NT Hashes
generated from password shorter then 15 characters it would take about
140,959.235.198 exabytes...)

I did quite a few password audits for my customers and NT Hash can only be
cracked if they used easy to guess passwords (dictionary attack) while LM
Hash can be cracked in few days if users came up with really complex
passwords (but majority of passwords stored as LM Hash were cracked in about
6 hours or less).

Account Passwords and Policies
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/bpactlck.mspx

How to prevent Windows from storing a LAN manager hash of your password in
Active Directory and local SAM databases
http://support.microsoft.com/kb/299656/en-us/

I hope this helps.
 
Thank Miha - that really helps.

Do you know have many times the NT Hash is applied? Is it just the once?

Thanks,
S
 
Do you know have many times the NT Hash is applied? Is it just the once?

Sorry, I don't have this information. My guess would be only once.
 
LM hashes really aren't hashes. In LM your password is converted to upper
case and broken into two 7-character chunks. These chunks are used as the
key to encrypt a well-known constant with DES. It worked OK 15 years ago,
but it's cryptographically weak now.

NT hashes are real hashes. The hash is a single application of MD4 on the
(case-preserved) password; the result is stored in Unicode. There is no salting.

You didn't ask, but in case you're curious... cached credentials are a hash
of a hash. Your Unicode password hash is concatenated with your user name
and domain name; all this is hashed with MD5 and stored.

Steve Riley
(e-mail address removed)
 
Thanks for the information Steve - Interesting, so cached credentials use
salting by concatenating the user name with the original MD4 hash, and then
encrypted using a stronger encryption algorithm - MD5.

I assume that the cached credential is now heavily encrypted compared to the
password hash stored in AD.

Thanks,
S
 
Hi,

Storing hashes in Active Directory was never a problem. Tools that "know"
how to extract hashes from AD never work directly against the AD database
and they don't care how they are stored or encrypted in AD database. What
they do is use DLL injections against LSASS service. Once LSASS loads this
DLL, tools will use same API that LSASS would use to access the hash.

Still, you would need physical access to the server and appropriate
credentials on the server (administrator) to be able to install/run such
tools or on/against active directory server.

Still, it makes more sense when looking at security to use active directory
cached credentials then to use local user accounts.
 
Back
Top