Reseting the Hashed Password after enabling Windows File Sharing

Disclaimer: you'll need a good bit of knowledge about OS X, UNIX, and encryption to understand what I'm talking about.


All right, so normally OS X hashes user passwords using a salted SHA1 encryption. It uses shadowing so that you can't obtain the actual hash value using "% nidump passwd".

BUT, if you enable Windows File Sharing, all that changes. OS X re-hashes your password using the much less secure LANMAN encryption. This allows Windows machines to access your files. (LANMAN is what Windows used to encrypt passwords up through Windows ME. Later versions of Windows use NTLM instead, which is stronger.) This is why, the first time you enable Windows File Sharing, OS X warns you that enabling the feature will require your password to be stored in a less secure manner; it's downgrading the hash from SHA1 to LANMAN.

My question is: I'm done sharing files with idiot Windows users - how do I force OS X to go back to storing my password using SHA1?

Thanks guys.

-Bryan

12" Powerbook G4, Mac OS X (10.4.4)

Posted on May 10, 2006 12:08 AM

Reply
4 replies

May 10, 2006 1:17 AM in response to bdkjones

Update: I tried the following and need to know if it truly forced OS X back into hashing my password using SHA1.


I logged in as root, opened NetInfo Manager and clicked on "users" in the tri-pane. I then selected the user who had windows file sharing enabled and looked at the properties in the bottom of the window.

There is a property field called "authentication_authority". On accounts that have NEVER had windows file sharing enabled, this property's value reads: ";ShadowHash;" (minus the quotes). On the account that DID have windows file sharing enabled, the property was ";ShadowHash; [plus a bunch of stuff here that I deleted]".

After I deleted the "extra" part of that value and then logged out of root and logged back in as the account which used to have Windows File Sharing enabled, I went to the Accounts preference panel and tried to enable windows sharing. I got the warning that "this requires your password to be stored in a less secure manner." Previously, I did not get that warning; it just turned on windows file sharing.

So, either OS X is now back to using SHA1 to hash my user password, or I just "reset" the warning dialog and my password is really still hashed using LANMAN.

Can anyone out there tell me which it is?

-Bryan

May 10, 2006 7:27 AM in response to bdkjones

The hashes are stored in "/private/var/db/shadow/hash" so it's pretty easy to see if anything changes or not. So after a quick test, it seems that "System Preferences" > "Sharing" > "Services" > "Window Sharing" > "Enable Accounts…" does take care of converting the hash file info - in both directions ("checking" and "unchecking"). Simply turning off "Windows sharing" doesn't do anything to the accounts, which makes sense since there might be reasons why you might want to turn SMB off or on again, without having to reauthenticate each account.

When the setting in the pref pane is changed, the ' authentication_authority' also changes along with the changes to the hash type, but I don't think changing the ' authentication_authority' through "NetInfo" will affect the password hashes - I think it's more of a flag to tell the system what to use when attempting to authenticate, or to tell the "Sharing" pref pane whether or not to throw up the dialogue about enabling accounts. However, setting the ' authentication_authority' to ";ShadowHash;" then resetting the password does seem to revert the account to using just "salted-SHA1".

May 10, 2006 10:43 AM in response to biovizier

Thanks biovizier. You're absolutely right, deleting the extra text after ";shadowHash;" and then reseting the password for the user's account does seem to force OS X to rehash the password using SHA1.

Just in case someone else has this question in the future, here's how to verify that your password is hashed in SHA1:

Log in as Root and open the /private/var/db/shadow/hash folder. You'll see files with long, weird names. You'll also see an XML file (with the extension *.state) for each of the files with long, weird names. The XML file contains several tags that tell OS X information about the hashed password - things like when it last logged on, when it was created, how many times login failed, etc.

We're interested in the other files - the ones that don't end in ".state"

To verify that SHA1 is being used, open the long, weird files in textedit. You should see something like this:

000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000059G31HJ75BR54210P07Y57BC57094D643H78K8765L98C6X000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000

There should be a few more zeros; I've cut some out here to save space.

What should NOT exist, is the following:

57Y083D243109VGR45Z4B65812R8M087H65HJ8OK95T89L8JHL9000000000
000000000000000000000000000000000000000000000000000000000000
0000000059G31HJ75BR54210P07Y57BC57094D643H78K8765L98C6X00000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000

The second Hashed value does not start with zeros. This hash value is not SHA1. It is the less secure encryption method required for compatability with Windows.

If your hash file opens with zeros, you're using SHA1. Otherwise, follow Biovizier's procedure: Open NetInfo, select the user account whose password needs to be changed back to SHA1, look at the "authentication_authority" value, make sure the value is set to ;ShadowHash; and that no additional text follows that string, then reset the affected account's password. You can then log back in as root and re-check the hash files using textedit and you should find that the hash file opens with solid zeros instead of letters and numbers.

Do NOT manually edit the hash files in textedit. One of those files is the hash for the Root password. If you change that hash file, your root password will no longer work (because when you type MYPASSWORD, OS X will hash that string and find that the hashed value no longer matches the stored hash value in /private/var/db/shadow/hash and OS X will therefore reject your password as incorrect) and you will quickly find yourself locked out of your computer for good.

And finally, just in case you have the computing power of the NSA and are thinking about running the hashes I've listed here: A) They aren't the right length; I've left some characters out and B) I randomly substituted different alphanumerics in for the ones in my real hashes with no rhyme or reason.

Which brings me to another point: NEVER post your hashes online. Yes, it takes a TON of computing power to break them, but still, they're hidden away for a reason!

Anyway, I hope this helps other security buffs out there.

I'm going to make a suggestion to Apple that OS 10.5 be changed so that when you unclick "windows file sharing" the OS immediately rehashes your password in SHA1 again.


-Bryan

May 10, 2006 11:01 AM in response to bdkjones

" follow Biovizier's procedure: Open NetInfo, select the user account whose password needs to be changed back to SHA1, look at the "authentication_authority" value, make sure the value is set to ;ShadowHash; and that no additional text follows that string, then reset the affected account's password. "

I guess I didn't emphasize it enough in my earlier post, but "unchecking" the checkbox beside the user's name in "System Preferences" > "Sharing" > "Services" > "Window Sharing" > "Enable Accounts…" seems to be enough rehash the password using only salted SHA-1 - I would suspect that this is the "recommended" GUI way for doing it.

Turning off "Windows sharing" by itself doesn't do this, probably in case you want to turn it back on again. For example, suppose the server has to be restarted after changing a configuration file - it would be a hassle to have to go in and re-enable whatever subset of accounts need to be granted access.

The rest of my comments (re resetting the password) were just ramblings speculating on where in the various chains of events the ' authentication_authority' plays a role...

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Reseting the Hashed Password after enabling Windows File Sharing

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.