My reply was a bit cryptic and prompted replies from Eric Kool-Brown and Brian Arkills that pointed out that one-way hashes can't be decrypted (at least not without some brute forcing):
This blog post is a follow up to that conversation with more details now that I can take advantage of the luxury of having a more than 140 characters to use. So, why does Password Sync fail to run on a Federal Information Processing Standard (FIPS) compliant machine and what is going on under the covers? This is because FIPS compliant systems bar the use of MD5 hash algorithms, so they block Password Sync when the tool tries to access MD5 functions. Does Password Sync use MD5 functions for encryption? The answer is No . Here's what is actually going on under the covers. User passwords are stored as a non-reversible hash in Windows Server Active Directory Domain Controllers (DCs). When our password sync agent attempts to synchronize the password hash from a DC over a secure RPC interface, the DC encrypts that password hash using an MD5 key. The MD5 key that the DC uses is derived from the RPC session key and a salt. Once this happens, the password hash is now wrapped in an MD5 encryption envelope. The password sync agent gets this encrypted password hash from the domain controller over the secure RPC interface. The following is a code snippet how the MD5 hash key is generated.
byte[] ComputeMd5(byte[] sessionKey, byte[] salt) { byte[] data = new byte[sessionKey.Length + salt.Length]; Buffer.BlockCopy(sessionKey, 0, data, 0, sessionKey.Length); Buffer.BlockCopy(salt, 0, data, sessionKey.Length, salt.Length); using (MD5 md5 = new MD5CryptoServiceProvider()) { return md5.ComputeHash(data); } } |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.