Printable View
I've been search google for this with little luck. I know LM hashes in the SAM file only have one salt for all of the stored password hashes, but what about the NT hashes? Do they use more than one salt? Do any hashes in the SAM have unique salts? I just wanted to get the facts straight for a turorial I writing.
Lanmanager, NTLM or NTLMv2?
IIRC the NTLMv2 passwords are stored as an MD4 hash, no salt needed.
As for the 'old' Lanmanager passwords these are DES encrypted.
I wrote something about that a long time ago. I'll see if I can dig it up.
Edit: Found this article. It names the magic number used in the DES encryption.
I thought NTLMv2 hashes were just sent on the wire but not in the SAM?
As far as I'm aware, none of the hashes that NT uses have any salt value.
The reason for this is because they are really plaintext-equivalent (unlike Unix's ones). A further challenge/response is computed and sent over the wire, but the hash itself remains unchanged.
Unix passwords are NOT plaintext-equivalent, that's to say, they aren't sufficient to logon, as Unix checks its passwords unencrypted (or without a challenge/response, anyway, as in ssh, which is still encrypted at another layer).
Mark
Slarty, I'm not sure what you mean by plaintext-equivalent since hashes in the SAM are one way hashes that can not be directly reversed.
According to
http://www.harper.no/valery/PermaLin...ab49ad9a4.aspx
not salt is used in NT hashes but I’d like to find a more authoritative page I can reference. Still looking to find out it LM hashes use not salt at all, or just a single salt for all hashes in the SAM.
At least on NT it only stored the DES encrypted LM passwords and the MD4 NTLM hash.
The DES encryption is done using that magic number. This number is always the same.
One thing to note though is an added obfuscation that's done.
You can also take a look at pwdump, the samba utility to dump your SAM into something samba can understand. Maybe you can find your answer in it's source.
http://us2.samba.org/samba/ftp/pwdump/
Thanks for the link. Would the “magic number” LM uses be considered a salt since it adds some randomness?
Hi
Irongeek, your tutorial[0] about cached passwords is a great work!
I try to answer your above question. I am a bit late with it, but the
flu got me :(
No.Quote:
Would the “magic number” LM uses be considered a salt since it adds some randomness?
In short:
Code:-LM : no salt
-NTLM : no salt
-NTLMv2: has salt (in the challenge/response!)
For those interested, let me elaborate as far as I understand
(somewhat simplified). Taken from [1,2,3,4] mainly.
There are two scenarios to check a login/password: a local SAM
or a network-authentication method to a DC. The procedures are
somewhat related. I am not talking about cached credentials here.
SAM - LM
The password is filled to reach 14 bytes with zeroes, or cut if longer
(often called "null-padded to 14 bytes").
These 14 bytes are split into 2 independent DES keys to encrypt
the plaintext 0x4B47532140232425 twice independently. This plaintext
is, for whatever reason, called magic number. I much more prefer "cafebabe" :)
The two ciphertexts are put together to form the 16byte hash.
SAM - NTLM
The NTLM hash also null-pads the password to 14 bytes, but then
creates a 16byte MD4-hash from a unicoded version of the password,
which enables case-sensitivity. No salt is added. I just mention syskey
as an ancient mean to enhance the strength of the hash.
Network - Authentication - LM/NTLM
LM, as well as NTLM-hash is extended to 21 bytes using 5 nulls, allowing for
3 DES keys. The challenge is DES'd 3 times independently, therefore
the answer is an 24 byte response.
Network - Authentication - NTLMv2
The NTLMv2 uses the same hash as generated by NTLM (!), but adds salt to it:
The 32 byte block has "the salt in it", and for the first time introduced in the networkCode:1. step: Username/Domainname + NTLM-Hash -> 16 byte MD5 Hash. Call it "1stephash".
2. step: 32 byte block: timestamp, server-challenge plus client-challenge.
3. step: "1stephash" + 32 byte block -> 16 byte MD5 Hash. Call it "3stephash".
4. send "3stephash" + 32 byte block (plaintext) to the DC for authentication.
authentication procedure with Windows networking.
"Conclusions"
As per the latest Kerberos[5a,5b]: It is much more secure, but often LM/NTLM
is not deactivated. I would strongly recomment to deactivate LM hash storage
in the local computer SAM[6], and only use NTLMv2[7] in compatibility mode.
Phuh. Done :)
Cheers.
[0 ] http://www.antionline.com/showthread...hreadid=266698
[1 ] http://www.windowsecurity.com/articl...Passwords.html
[2 ] http://davenport.sourceforge.net/ntlm.html
[3 ] http://www.windowsitpro.com/Windows/...3844/3844.html
[4 ] http://www.windowsitpro.com/Article/...7072/7072.html
[5a] http://www.microsoft.com/technet/pro.../kerberos.mspx
[5b] http://www.microsoft.com/windowsserv...s/default.mspx
[6 ] http://support.microsoft.com/default.../q299/6/56.asp
[7 ] http://support.microsoft.com/default.../Q239/8/69.ASP
Cool, that's what I was looking for. Thanks.
WOW, what great information. Now that I have read about the passwords 2K/XP use, I ran the cachedump program and found an account on my pc with a hashed (I'm assuming) password. How do you decrypt that string of characters. This is an XP machine. The logon account is not a local account. I tried JTR but found it to be too complexed (playing with it for an hour or so). Any help?
You can't decrypt them, but you can brute force/dictionary attach them using John the Ripper. See my tutorial for how to do it.