Security Basics mailing list archives
Re: ADS Password Storage Protection
From: Neil <neil () voidfx net>
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 ---------------------------------------------------------------------------
Current thread:
- ADS Password Storage Protection rolando_ruiz (Jul 14)
- RE: ADS Password Storage Protection Roger A. Grimes (Jul 14)
- RE: ADS Password Storage Protection rolando_ruiz (Jul 27)
- RE: ADS Password Storage Protection Roger A. Grimes (Jul 31)
- RE: ADS Password Storage Protection rolando_ruiz (Jul 27)
- Re: ADS Password Storage Protection Neil (Jul 17)
- Re: ADS Password Storage Protection Eoin Miller (Jul 17)
- <Possible follow-ups>
- Re: RE: ADS Password Storage Protection winshel (Jul 17)
- Re: ADS Password Storage Protection ab (Jul 17)
- RE: ADS Password Storage Protection Depp, Dennis M. (Jul 18)
- Message not available
- RE: ADS Password Storage Protection Harold Winshel (Jul 18)
- RE: ADS Password Storage Protection Depp, Dennis M. (Jul 18)
- Re: ADS Password Storage Protection Stephen John Smoogen (Jul 21)
- RE: ADS Password Storage Protection Roger A. Grimes (Jul 21)
- RE: ADS Password Storage Protection Roger A. Grimes (Jul 14)
- RE: ADS Password Storage Protection Roger A. Grimes (Jul 19)
- Message not available
- RE: ADS Password Storage Protection Harold Winshel (Jul 21)