RE: ADS Password Storage Protection

[eric.baechle () dhs gov]

Rolando,

The first couple of Mr. Grimes' suggestions are spot-on, but password cracking is often not the problem.  To understand 
the threat-vectors for your ADS passwords you have to understand how they're stored and shared, which I believe was 
your original question.

In Active Directory the passwords are actually stored encrypted in active directory files.  As mentioned by Mr. Grimes, 
this is the NTDS.DIT file on your Windows ADS Domain Controllers.  The passwords are hashed (a one-way mathematical 
encryption-style function) using a combination of the username and password for the user.  Again as Mr. Grimes pointed 
out, by default Windows stores these using a now-outdated storage format called Lan Mananger.  My methodology differs a 
bit from Mr. Grimes here.  In my opinion, the quickest increase to your security is two-fold:
1)  Force the use of NTLMv2 (New Technology Lan Manager version 2) as Mr. Grimes suggested.
2)  Force complexity requirements of 8 characters with at least 1 number, one capital letter, and one special character 
(You will only give users heartburn by making it more than 8 characters and not effectively increase your security).

Once you do this, reset everyone's password so they must change it at their next login (otherwise the LM hash stays).

You don't really need to worry about cracking of passwords, you just want to make them hard to guess.  In order to 
crack a password, an attacker needs to export your passwords from NTDS.DIT.  Access to do this requires 
administrator-level authority on your Windows domain controllers.  If your attacker has admin rights on your domain 
controllers you're already compromised.  

Second, when a system authenticates it does not send the user's name and password over the wire.  It computes the hash 
and then sends the hash over the wire.  The server then compares the hash sent from the client to the one stored in 
ADS.  If it matches the system _assumes_ the correct username and password was entered at the client.  SMB (windows 
authentication) clients that inject hash credentials already exist in the wild.  If someone has your password hashes, 
they don't need to crack a thing (Google for "pass the hash").

Some additional suggestions on securing your password databases:

1) Turn security logging on!  Monitor mass authentication failures!
2) Set the lockout threashold to something higher than 3, like 25... A human typically remembers 8 things at one time, 
and will get frustrated and contact a helpdesk between 8 and 15 tries.  If a lockout ever occurs from 25 attempts, you 
KNOW an automated brute-force is attacking your system and not just some poor guy that can't remember which of the 4 or 
5 passwords he knows is for that system.
3) Obtain an intrusion detection system and monitor access to NTDS.DIT!  If you need to, run a password dump against 
your system to obtain a definition for the attack (but be sure to delete the hash files that result when you're done).
4) Force your passwords to change often (90 days?) in case you miss someone exfiltrating your password database or 
someone uses the same password that they do for their web accounts.


I welcome a discussion on this topic.  I think that authentication security is one of the most misunderstood topics in 
computer security today.

Sincerely,

Eric Baechle, CISSP/ISSEP, etc...
Senior INFOSEC/OPSEC Engineer
Department of Homeland Security

---------------------------------------------------------------------------
This list is sponsored by: SensePost

Hacking, like any art, will take years of dedicated study and  
practice to master. We can't teach you to hack. But we can teach you  
what we've learned so far. Our courses are honest, real, technical  
and practical. SensePost willl be at Black Hat Vegas in July. To see  
what we're about, visit us at: 

http://www.sensepost.com/training.html
---------------------------------------------------------------------------