8 ms·

The importance of this NIST standard cannot be understated. It has a requirement that passwords be hashed with a random salt! Microsoft Active Directory does no

The importance of this NIST standard cannot be understated. It has a requirement that passwords be hashed with a random salt! Microsoft Active Directory does not use salts! I am trying to imagine the consequences to all the businesses and agencies that must adhere to these standards suddenly coming to the realization that they must replace their Active Directory installations and what that will mean for administering all their Windows systems. It's not going to be pretty. You might be thinking, "but these are just guidelines!" Yes, but actually there's loads of existing business contracts with wording that states the business must adhere to all NIST (security) guidelines. Also, you can bet that once this gets finalized other standards will follow suit. It will be interesting to see what Microsoft does because salts were expressly not added to AD because so much functionality cannot work with random salts in place. They're going to have to break backwards compatibility with a lot of functionality and many 3rd party products that synchronize with AD. Entirely new APIs are going to need to be written. It will also become seriously annoying to create keytabs at large organizations since only domain admins will have that power once random salts are in place; making automation very difficult.

helper 10y ago
Will requiring salts break ms-chap-v2?
jrochkind1 10y ago
Presumably Microsoft would add a salt before losing all that business. Perhaps only if you turn on special NIST-mode, in the way of microsoft and backwards compatibility. It might break some functionality, but probably not as much as moving to an entirely different product if you have things written against MS APIs.
- ckozlowski 10y ago
  This is a great example of how smart standards can leverage incredible pressure against vendors to adopt best practices. What will happen is that if the new standard is accepted as is, every single implimentation will have to craft a Plan of Action and Milestones (POAM), and every security officer is going to write in "Waiting for vendor fix". That's a lot of pressure on Microsoft to change this. Will it take time? Certainly. Years in fact. But if you want massive change, this is how you start. I'm a big fan of Active Directory. But I applaud this move. I'm even more excited to see if this will filter down to banks. Probably not as quickly, but one can hope.
- dspillett 10y ago
  > Perhaps only if you turn on special NIST-mode That is pretty much how they worked the Posix compliance requirement for government/forces use for NT/2000: the API was available through an optional (and IIRC not quite complete) module that very few ever turned on even where it was a contractual requirement that it be present. The option you suggest could be present but no doubt not be in use by many people because extension-X, third-party-app-Y, or internal-automation-subsystem-Z, or some feature of AD itself, would break.
deleted 10y ago
[deleted]
ghshephard 10y ago
If a salt matters, that means you can look it up in a dictionary of hashed passwords. Which means its in a very small search space. Which means a exhaustion search would find it quickly anyways. Far more relevant than "salts" would be using a PBKDF (See PBKDF2, SCRYPT, BCRYPT - which come with a salt for free anyways) with an appropriate number of iterations. What was the last year that Rainbow Tables were relevant anyways - 2010? Earlier?
- peeters 10y ago
  Even if you assume weak passwords, there's no comparison in effort when you involve stretching. No salt means you can precompute the hash for the 1,000,000 most common passwords. That'll take maybe an hour or two with aggressive stretching. Then you check it against the million or so records in the database for any matches. Salt means FOR EACH RECORD in the database, you have to compute those 1,000,000 passwords. That means you're talking about decades of computation time. That's a heck of a lot more expensive. And importantly, you have to start that computation AFTER the breach, because that's when you gain access to the salts. Salts are not unimportant.
  - zubspace 10y ago
    Now this is something which i don't understand. Is this really the best we got? If you somehow get into a server with those hashed passwords, you'll probably try to mirror it and everything on the server, to figure out the hashing mechanism. So lets say, time is not an issue, also regarding long lasting APT's. So what will you do with it? Why should you try brute force a million passwords, each one taking 2 hours to decrypt? No, you're smarter than that: Why not create a rainbow table of possible admin account, vips, state actor, etc. How many are those? 100? 1000? Nice, you just reduced the search space by a factor of 1000. That whole circus about hashing... I know, randomly salted hashing makes sense, but true secure password storage is a myth.
  - ghshephard 10y ago
    So - I think we basically agree with each other, that for a straightforward single round of a hash like SHA256, that a salt is now irrelevant (reason - a GPU cluster can check 10s of billions of passwords/second) I think the point I was trying, and perhaps failing to make, is that the three PBKDFs - PBKDF2/BCRYPT/SCRYPT - all come with a salt anyways - so you don't really need to call them out. What I guess I should have made explicit, (and I didn't) is that if all you are doing is a single round of a SHA - then adding a salt at the beginning isn't going to make that password any more secure. If it could fall to a Rainbow Table Lookup, then it will fall in pretty much the same amount of time to a password-cracker - on the order of milliseconds.
ams6110 10y ago
The problem is they are basically saying that almost every "best pratice" recommended over the past 5-10 years is absolutely the wrong thing to be doing. Don't be surprised when people throw up their hands in frustration.
- bo1024 10y ago
  "best practice" according to whom and "recommended" by whom? Maybe by security theater or other sources of BS, but not security experts (who are worth their, ahem, salt).
- tracker1 10y ago
  It's been longer than 10 years, and known for quite some time by most.. The xkcd article is over 5yo itself, and a lot of people pushed for more open passwords for ages... I do one controversial think and that's trim password imput (mainly because of trailing whitespace selection in some apps/oses). Other than that, if you can input it, you can use it... though now doing some unicode normalization for unity combos is probably a good idea prior to hashing. https://xkcd.com/936/ https://xkcd.com/936/
  - hvidgaard 10y ago
    That comic is unfortunately not telling the truth. The password phrase IS 44 bits of entropy, assuming you input random ascii. But any reasonably knowledgeable person trying to crack passwords, will use a dictionary to create a passphrases, rendering this less useful than the first password. Even if you do substitute o/0/ø, i/l/1, a/4, ect randomly. You still need a rather long sentence, and preferably spice it up with simple substitution - now this passphrase is no longer easy or simple to remember.
    - noja 10y ago
      Then why doesn't he update it?
    - whiteandnerdy 10y ago
      I think XKCD is correct here. If you choose four random words from a list of 2048 common words, and your attacker knows that's what you're doing, then your entropy is 4 * log_2(2048) = 44 bits. If the attacker didn't know your strategy and tried to brute force letter by letter it would be much higher - around 48log_2(26)=150 bits assuming around eight letters per word - but like you said, we should assume the attacker knows exactly what strategy we're using, so 44 bits is the better number to work with. Since that's still more than 28 bits, a 'correct horse battery staple' type password is harder to crack then a short random string of mixed characters, even if the attacker knows exactly what your password generation strategy is.
oneeyedpigeon 10y ago
Do those contracts really require adherence to NIST standards, including whatever future changes are made to them? I would have thought they'd be restricted to the guidelines as they are at the time the contract is signed.
- deleted 10y ago
  [deleted]
- failrate 10y ago
  You typically have to renew every few years for DoD.
- deleted 10y ago
  [deleted]
euroclydon 10y ago
Can NTLM, which prevents sending the password itself across the network, work with random salts?
- riskable 10y ago
  No it cannot since the authenticating client won't know the salt. NTLM isn't the only authentication method that is fundamentally incompatible with salts. The way Windows clients perform initial Kerberos authentication (getting the TGT) will break as well. Kerberos is easier to fix though since the protocol was made to work with salts. It's just that the way Microsoft implemented it leaves it vulnerable to pass-the-hash styled attacks. Another issue is how applications handle incoming Kerberos authentication. For example, when you configure IIS to perform Kerberos authentication you (usually) need to specify a service account and provide the password. Instead of storing the password IIS will simply pre-compute the hash (which it can do because there's no random salt) and store the result using DPAPI (I think... Since it's a Microsoft product it may use a different nonpublic API). If using random salts IIS won't be able to do that anymore and will have to work like traditional MIT Kerberos applications--using a keytab (provided by an administrator).
jdc0589 10y ago
additionally, there are rumors (maybe more than that now) that the next round of HIPAA/HITECH /etc... regulations are going to adopt a lot of NIST standards and frameworks. So, this could potentially trickle down to the Healthcare industry.

helper 10y ago

Will requiring salts break ms-chap-v2?

jrochkind1 10y ago

Presumably Microsoft would add a salt before losing all that business. Perhaps only if you turn on special NIST-mode, in the way of microsoft and backwards compatibility. It might break some functionality, but probably not as much as moving to an entirely different product if you have things written against MS APIs.

ckozlowski 10y ago
This is a great example of how smart standards can leverage incredible pressure against vendors to adopt best practices. What will happen is that if the new standard is accepted as is, every single implimentation will have to craft a Plan of Action and Milestones (POAM), and every security officer is going to write in "Waiting for vendor fix". That's a lot of pressure on Microsoft to change this. Will it take time? Certainly. Years in fact. But if you want massive change, this is how you start. I'm a big fan of Active Directory. But I applaud this move. I'm even more excited to see if this will filter down to banks. Probably not as quickly, but one can hope.
dspillett 10y ago
> Perhaps only if you turn on special NIST-mode That is pretty much how they worked the Posix compliance requirement for government/forces use for NT/2000: the API was available through an optional (and IIRC not quite complete) module that very few ever turned on even where it was a contractual requirement that it be present. The option you suggest could be present but no doubt not be in use by many people because extension-X, third-party-app-Y, or internal-automation-subsystem-Z, or some feature of AD itself, would break.

deleted 10y ago

[deleted]

ghshephard 10y ago

If a salt matters, that means you can look it up in a dictionary of hashed passwords. Which means its in a very small search space. Which means a exhaustion search would find it quickly anyways. Far more relevant than "salts" would be using a PBKDF (See PBKDF2, SCRYPT, BCRYPT - which come with a salt for free anyways) with an appropriate number of iterations. What was the last year that Rainbow Tables were relevant anyways - 2010? Earlier?

peeters 10y ago
Even if you assume weak passwords, there's no comparison in effort when you involve stretching. No salt means you can precompute the hash for the 1,000,000 most common passwords. That'll take maybe an hour or two with aggressive stretching. Then you check it against the million or so records in the database for any matches. Salt means FOR EACH RECORD in the database, you have to compute those 1,000,000 passwords. That means you're talking about decades of computation time. That's a heck of a lot more expensive. And importantly, you have to start that computation AFTER the breach, because that's when you gain access to the salts. Salts are not unimportant.
- zubspace 10y ago
  Now this is something which i don't understand. Is this really the best we got? If you somehow get into a server with those hashed passwords, you'll probably try to mirror it and everything on the server, to figure out the hashing mechanism. So lets say, time is not an issue, also regarding long lasting APT's. So what will you do with it? Why should you try brute force a million passwords, each one taking 2 hours to decrypt? No, you're smarter than that: Why not create a rainbow table of possible admin account, vips, state actor, etc. How many are those? 100? 1000? Nice, you just reduced the search space by a factor of 1000. That whole circus about hashing... I know, randomly salted hashing makes sense, but true secure password storage is a myth.
- ghshephard 10y ago
  So - I think we basically agree with each other, that for a straightforward single round of a hash like SHA256, that a salt is now irrelevant (reason - a GPU cluster can check 10s of billions of passwords/second) I think the point I was trying, and perhaps failing to make, is that the three PBKDFs - PBKDF2/BCRYPT/SCRYPT - all come with a salt anyways - so you don't really need to call them out. What I guess I should have made explicit, (and I didn't) is that if all you are doing is a single round of a SHA - then adding a salt at the beginning isn't going to make that password any more secure. If it could fall to a Rainbow Table Lookup, then it will fall in pretty much the same amount of time to a password-cracker - on the order of milliseconds.

ams6110 10y ago

The problem is they are basically saying that almost every "best pratice" recommended over the past 5-10 years is absolutely the wrong thing to be doing. Don't be surprised when people throw up their hands in frustration.

bo1024 10y ago
"best practice" according to whom and "recommended" by whom? Maybe by security theater or other sources of BS, but not security experts (who are worth their, ahem, salt).
tracker1 10y ago
It's been longer than 10 years, and known for quite some time by most.. The xkcd article is over 5yo itself, and a lot of people pushed for more open passwords for ages... I do one controversial think and that's trim password imput (mainly because of trailing whitespace selection in some apps/oses). Other than that, if you can input it, you can use it... though now doing some unicode normalization for unity combos is probably a good idea prior to hashing. https://xkcd.com/936/ https://xkcd.com/936/
- hvidgaard 10y ago
  That comic is unfortunately not telling the truth. The password phrase IS 44 bits of entropy, assuming you input random ascii. But any reasonably knowledgeable person trying to crack passwords, will use a dictionary to create a passphrases, rendering this less useful than the first password. Even if you do substitute o/0/ø, i/l/1, a/4, ect randomly. You still need a rather long sentence, and preferably spice it up with simple substitution - now this passphrase is no longer easy or simple to remember.
  - noja 10y ago
    Then why doesn't he update it?
  - whiteandnerdy 10y ago
    I think XKCD is correct here. If you choose four random words from a list of 2048 common words, and your attacker knows that's what you're doing, then your entropy is 4 * log_2(2048) = 44 bits. If the attacker didn't know your strategy and tried to brute force letter by letter it would be much higher - around 48log_2(26)=150 bits assuming around eight letters per word - but like you said, we should assume the attacker knows exactly what strategy we're using, so 44 bits is the better number to work with. Since that's still more than 28 bits, a 'correct horse battery staple' type password is harder to crack then a short random string of mixed characters, even if the attacker knows exactly what your password generation strategy is.

oneeyedpigeon 10y ago

Do those contracts really require adherence to NIST standards, including whatever future changes are made to them? I would have thought they'd be restricted to the guidelines as they are at the time the contract is signed.

deleted 10y ago
[deleted]
failrate 10y ago
You typically have to renew every few years for DoD.
deleted 10y ago
[deleted]

euroclydon 10y ago

Can NTLM, which prevents sending the password itself across the network, work with random salts?

riskable 10y ago
No it cannot since the authenticating client won't know the salt. NTLM isn't the only authentication method that is fundamentally incompatible with salts. The way Windows clients perform initial Kerberos authentication (getting the TGT) will break as well. Kerberos is easier to fix though since the protocol was made to work with salts. It's just that the way Microsoft implemented it leaves it vulnerable to pass-the-hash styled attacks. Another issue is how applications handle incoming Kerberos authentication. For example, when you configure IIS to perform Kerberos authentication you (usually) need to specify a service account and provide the password. Instead of storing the password IIS will simply pre-compute the hash (which it can do because there's no random salt) and store the result using DPAPI (I think... Since it's a Microsoft product it may use a different nonpublic API). If using random salts IIS won't be able to do that anymore and will have to work like traditional MIT Kerberos applications--using a keytab (provided by an administrator).

jdc0589 10y ago

additionally, there are rumors (maybe more than that now) that the next round of HIPAA/HITECH /etc... regulations are going to adopt a lot of NIST standards and frameworks. So, this could potentially trickle down to the Healthcare industry.