22

I find it quite difficult to believe that the passwords in Active Directory for Windows 2008 R2 are still stored using the unsalted MD4 (aka "NT Hash") algorithm.

Can it really be true?

I've been revising my understanding of password storage recently, and learning how to use PKDBF2 properly. Then I thought I'd look up what major commercial organisations used. At which point I put my head in my hands! Unsalted MD4 in Windows. And that's an improvement on the LM hash. And there are plenty of other bad examples. /etc/shadow with a decent crypt is just about the only good implementation in major commercial / opensource.

MySQL's OLD_PASSWORD is terrible, even the new PASSWORD is just unsalted SHA-1 twice.

Is the general commercial / opensource sector really that bad?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Richard Gadsden
  • 501
  • 1
  • 4
  • 11

2 Answers2

18

NTLMv1 uses MD4, v2 uses MD5, and the Windows implementation of Kerberos uses a KDF using HMAC-SHA1 for AES 128/256. Active Directory can actually store multiple types of hashes of passwords depending on what you are wanting it to do, and what versions of protocols are enabled.

Yes, Active Directory uses unsalted passwords. Is this a security problem? Theoretically yes, but practically probably not. The AD database was designed to be stored in a protected environment where only trusted people have access to the actual file, and only trusted systems can read the data in the file. A salt really only adds value if the particular store containing the password is accessible by potentially non-trusted people and/or non-trusted systems like a SQL database that also contains content. If you are letting anyone and everyone access the AD database you have bigger problems than password salts.

Then of course the other side of this goes to backwards-compatibility as well. Microsoft has to make sure the current version of AD is backwards compatible with the one 4 versions prior. Is this good for security? Not really, but they would be crucified if the versions weren't compatible. Are they changing the hashes to something more secure? Yes, albeit slowly.

Steve
  • 15,155
  • 3
  • 37
  • 66
  • 3
    And doesn't Active Directoy need plain text password to encrypt the session key in a Kerberos ticket ? In which case it must store password in a reversible symetric scheme. The *local* password cache uses a salted hash, though, and you can disable it if you don't need offline logon (wich is rather rare, from my experience). – ixe013 Jul 07 '11 at 20:06
  • IIRC Active Directory doesn't store an encrypted value unless you explicitly enable it, but I can't remember if thats for a different function. And good point about local cache. – Steve Jul 07 '11 at 20:53
  • 1
    you're forgetting that backups are rarely threated as "sensitive" so access to password hashes is not so unlikely – Hubert Kario Jul 11 '11 at 23:11
  • 1
    but MS could very well have started with supporting a newer hash in Vista/7 era and then starting to roll out new methods as default after 2015 where Win Server 2003 was stopped, or possibly even a bit later, rather than carrying this all the way to 2021 because it is STILL the case that MD4 is used. also NTLMv2 is not password storage but rather authentication for Kerberos. – My1 May 25 '21 at 11:20
  • Even NTLMv2 just uses MD4, in case anyone still wants to know. Source: I implemented the spec for our own SMB implementation. – Daniel Jun 10 '21 at 02:40
  • To clarify some confusing terminology: there is a difference between the "NTLM hash" (also known as an "NT hash") and the NTLM authentication protocol. This NT hash is defined as MD4(password). NTLMv1 and NTLMv2 are two versions of this protocol: the former splits the NT hash into three DES keys, and the latter derives an HMAC key from it by computing HMAC-MD5(NT hash, username + domain). So both versions of the protocol use the NT hash as their base secret. While you could technically also store the HMAC result if you don't want to support NTLMv1, DC's actually just store the NT hash. – AardvarkSoup Jul 22 '21 at 11:28
3

Yes, Windows domain controllers still store unsalted MD4 password hashes, to enable legacy NTLM authentication and Kerberos authentication with the legacy rc4-hmac-md5 cipher.

By default, Windows also stores three Kerberos keys for each password: two of which are derived via PBKDF2 and one via DES-based key derivation method. The MD4 hash is unsalted can be computed much more efficiently, though, so that one is generally used for password cracking.

You could argue that when an attacker is in the position to steal hashes from the account database they don't really have to bother cracking any passwords. They could just impersonate any user via pass-the-hash or golden/silver ticket attacks. I don't agree with this perspective, though, as people tend to reuse passwords for different services: compromising an organisation's domain is one thing, but also getting access to private employee mailboxes is another.

I once had a pentest assessment where we obtained hashes from a decommissioned legacy domain, but couldn't reuse many of them them in the new domain because the latter required bimonthly password changes. However, after we cracked 70% of the legacy hashes we were able to come up with variations of plaintext passwords (by replacing year and month numbers in them) that gave us high privileges in the new domain. This would have been much more difficult if Windows had used a stronger password hashing scheme.

AardvarkSoup
  • 577
  • 2
  • 10
  • 1
    As far as I know, it's not that they store MD4 to enable Kerberos arcfour-md4 usage, but that arcfour-md4 was *created* to allow re-use of already stored MD4 hashes (on domains that got upgraded from NT4.0 era to AD). – user1686 Jun 19 '21 at 17:02