Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: ADS Password Storage Protection |
|---|---|
| Date: | Sat, 15 Jul 2006 02:14:01 +0530 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 rolando_ruiz@jetaviation.com wrote:
I'm looking for best practice ways of protecting access to password storage in Active Directory. I have some immediate questions: Where exactly are passwords kept? Are these passwords kept in plain text? How can I protect these passwords from being hacked? (Encryption, restrictions, etc...) Thank you in advanced ________________________________ Jet Aviation Holdings, Inc. Rolando Ruiz
Unless I am mistaken, passwords are stored hashes in %systemroot%\ntds\ntds.dit on the domain controllers. So no, not plain-text. Windows uses a one-way hashing algorithm to hash the password when the password is set and stores that; and then takes a hash of the password supplied with the client authenticates. It compares the supplied authentication password hash to the hash it made and stored when the password was set. If the hashes match, then the passwords must match (in theory). On the other hand, since only a one-way hash is stored, there is no way to derive the password itself from the hash, and so the password is theoretically secure if the hashes are compromised. Except for two things: generally, there are a number of likely passwords a person will use. For example, their name. Or the word "password" (though a lot of people have learned not to do that now). Most of all, I see people leaving their password to what the administrator resets it to. The other exception is that it is possible to do a dictionary or brute force attack, in which another computer tries to hash every possible word from a wordlist or every possible character combination respectively, and compare that to the stored password hashes until it finds a match. John the Ripper, a well known cracker, can do 1,743,539 crypts per second on NT LM hashes on my (fairly modest) computer. That'll go through any short length password pretty damn fast. As Roger said before me, going long is your best bet. Use a phrase, a short sentence you can remember easily. Securing the AD is largely a matter of securing the server itself. Firstly you need to ensure that the DCs are physically secure, or else an attacker can take one offline, extract the ntds.dit file, extract the hashes and run the attacks outlined above. Disabling the less secure algorithms will help (which Roger also mentioned), namely LM and NTLMv1. Be aware that this may break some legacy applications and Windows Embedded devices. Use the principle of least privilege liberally here. Only the bare minimum staff should have administrative access to the AD and the DC servers. Try to avoid giving domain administrator privileges when you can instead give more limited accounts, or restrict the accounts to administer only certain sections (and hence aren't domain admins). Related to the above, separate administrative accounts from your normal desktop accounts. If you're running as a domain administrator on your desktop, you're giving an attacker many more opportunities to gain domain administrator access to your domain. Those hashes we spoke of earlier are often cached to decrease login time and, more importantly, so that roaming laptop users can log in when they are away from the network. Those cached hashes can be dumped and cracked as well. Rename the Administrator account. Its security-through-obscurity, so not good as a standalone measure; but in the context of a holistic security approach, you're adding just one more small stumbling block to an attacker. Though its pretty easy for most attackers to translate the SID straight to the real Admin account. Naturally, you're firewalling your DC, running antivirus, and not doing anything foolish, like using telnet to connect to your server (and especially not using domain admin credentials). Hopefully this will help. If you need more information, I think you will find plenty on the Internet, as well as published books. - -Neil. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEuAIROsIj4a0+XVMRAoesAJ946ByGANx93beTpj/oOr4F0bRCpQCgq4rM VgdSUVEJeWTMxgMuwocIpxg= =7wVk -----END PGP SIGNATURE----- --------------------------------------------------------------------------- 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 ---------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | New rootkit detection tool, user |
|---|---|
| Next by Date: | Re: RE: ADS Password Storage Protection, winshel |
| Previous by Thread: | RE: ADS Password Storage Protection, Roger A. Grimes |
| Next by Thread: | Re: ADS Password Storage Protection, Eoin Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |