Pretty straightforward - So we use rainbow tables to get passwords of users out of hashes. So why won't Microsoft implement salt on the passwords in Windows to be hash(password+salt)?
Won't this implementation save a lot of grief, at least while implemented on the SAM file when dealing with password cracking of local users?
The handling of passwords in a Microsoft OS is complex because they use passwords for many usages. The OS (or its domain controller) will store a hashed version of the password, but there are also values which are symmetrically encrypted with keys derived from the password or from the hash thereof. The authentication protocols do not include provisions for exchanging salts when some hashing must occur client side. It is difficult to alter the password processing algorithms without impacting a lot of subsystems and potentially breaking the backward compatibility, which is the driving force of the Windows ecosystem.
It goes down to strategic priorities. Microsoft knows that altering password hashing and authentication protocols to include a salt will have some non-negligible costs which they would have to assume (by fixing all the components which are thus affected). On the other hand, not changing the password hashing is rather "free" for them, because a flaky hashing algorithm will not convince customers to switch to other non-Microsoft systems (the OS market is, in practice, a captive market); it takes a lot more to force potential customers to envision an OS switch which is very expensive. Also, password hashing can arguably be qualified as "defence in depth", a second layer which has any impact only once a breach already occurred; as such, it could be presented as being of secondary importance. Therefore, it is logical, if irritating, that Microsoft does not update its poor password processing practices.
Historically, Microsoft did only one update, when they switched from NTLM v1 to v2, and it was kind of necessary because the older LM hash was so weak that it was beginning to be embarrassing. My guess is that it involved a lot of internal hassle and they are not eager to do it again.
The Microsoft system model is substantially different from the usual 'web' (and to a lesser degree UNIX) model - in the MS world, generally you have a number of machine under your own control that are tightly bound to a few central repositories and you're likely to know where they are a lot of the time. (This does break down when it comes to IIS; then, a lot of web apps do their own user control.)
As mentioned in another answer, Microsoft's hashes have been traditionally weak and are probably kept that way for backward compatibility. But it's also not critical to their security model - in the Microsoft model, it's relatively trivial to change a password. It's relatively trivial to force all passwords to change. You've also got a robust method for expiring passwords (so any lost hashes are going to quickly lose their value, definitely within 1-2 months).
You're also operating in a world where benevolent administrators heard non-technical users through the pitfalls of computing; as only one example: not salting means you can have a user update their password while not able to talk to the domain controller and the domain controller can work out the new password hash by just looking at the user's current credential (user+domain+the new password) and their previous credential. This is a big benefit because it means the user experience (changing passwords every xxx days) doesn't change depending on network access.
You may be interested in Microsoft's technical explanation of their password system.
