Configuring Secure Client Authentication

When you configure a Mac OS X Server as an Open Directory master, you enable both a SASL-based (simple authentication and security layer) Password Server and a Kerberos key distribution center (KDC). Once a client participates in that server's Open Directory domain, client users and computers can take advantage of these secure authentication services.

When you create a network user in an Open Directory domain, that user will have a password type of Open Directory, and will be able to use the Password Server and Kerberos. However, if you import lists of users, or migrate users from previous versions of Mac OS X Server, these users may have a password type of Shadow. However, once you change a shadow password for an Open Directory network user, the password is automatically upgraded to an Open Directory password.

Historically, UNIX passwords used the crypt function to generate encrypted passwords. A password or string, when "crypted," would result in an encrypted version of the password, which looks like random characters. There is no known function that can directly reverse the encryption back into its original text. However, because using the crypt function on a given password will always result in the same random encryption, no matter which computer you use to perform the encryption, it is possible to crack passwords via brute force. You just use the crypt function on random strings (or lists of words) and compare the result to the original encrypted password(s).

Early versions of UNIX stored user records in places readable to all users. Although this made managing user information much easier for system administrators, it also made it much easier for those with malicious intent to subvert the user records for their own uses. Since attackers could copy the entire contents of the user database, including the encrypted passwords, they could transport this information offsite (or for the really bold, just use local computing resources) and use brute force to crack passwords at their leisure.

Early versions of Mac OS X did this as well, storing the encrypted version of user passwords in semi-public locations. In the following example, user1's password was side042walk, and the encrypted version of that was stored right there along with the rest of the user information:

nidump passwd / | grep user1 user1:Ro8wktYdhRWYI:505:505::0:0:UserOne:/Users/user1:/bin/bash

As of version 10.3, Mac OS X and Mac OS X Server store the encrypted passwords of local users in locations that only the system (and the system administrator) can access, making it much more difficult to do offline brute force attacks. Also, various encryption methods more modern than crypt are used.

Using Shadow Passwords

As of version 10.3, both Mac OS X and Mac OS X Server store encrypted versions of each local user's password in /var/db/shadow/hash.

With shadow passwords:

• Files are stored in /var/db/shadow/hash.

• Files are readable only by root and the system.

• Each user gets his or her own file.

• Each user's filename is not based on user name, rather based on his or her GUID (generated user IDautomatically generated).

• Each file contains the password encrypted or hashed in possibly several different ways.

• There may be a .state file for each user, which contains information such as date and time the file was created, a count of failed logins, the last login date, and whether the password needs to be changed. This is stored in XML format.

This is a sample listing of the contents of the shadow directory:

The pwpolicy utility (in /usr/bin) shows that there are several types of hashes stored in Mac OS X. Note that later we will look at the same command on Mac OS X Server, which supports more hash types.

client1:~ root# pwpolicy -getglobalhashtypes SALTED-SHA1 SMB-LAN-MANAGER SMB-NT

SHA-1 is considered to be fairly strong and secure, and is on by default. Once you enable Windows Sharing, the other two hash types, SMB-LAN-MANAGER and SMB-NT, will be enabled only on a per-user basis after you enable Windows Sharing for each user.

SHA-1 is a function in the SHA (secure hash algorithm) family of cryptographic hash functions. SHA-1 produces a 160-bit digest of its input, which can contain a maximum of 264 bits. Because it is salted, the same password will have a different SHA1 hash each time it is set or changed; two users with the same password will have different hashes, making it that much more difficult for an offline attack.

A one-way hash function should have two characteristics. It should be one way; it should be impossible to apply any functions on the hash to recover the original text. It should also be collision free; no two inputs should result in the same hash. For more information about revelations that the SHA-1 hash function may not be collision-free, and what that means in practical terms, see Bruce Schneier's "Cryptanalysis of SHA-1" at http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html.

To illustrate the use of various hashes, examine this user2's shadow hash file before and after windows services is enabled. Here is the hash file before enabling Windows Sharing. dscl was used to find the GUID of user2 (because the shadow hash file is based on the GUID):

dscl localhost read /Search/Users/user2 GeneratedUID

The next step is to use that GUID to find the specific user hash in /var/db/shadow/hash/:

more /var/db/shadow/hash/09A5DB08-FEF3-425D-BC6C-D6D66C690795

This shows us the shadow password for user2. The pwpolicy command returns the type of hash stored in the user's shadow hash file:

pwpolicy u user2 -gethashtypes

In this case, user2's hash uses the SALTED-SHA1 encryption method, which is considered fairly strong and secure.

Because the password is stored in a nonrecoverable form, if you want to store a differently encrypted hash of the password, you have to give the operating system the user's password to generate the new hash. In the following figure, the OS is asking for the user's password when enabling Windows Sharing.

The following figure shows the updated contents of user2's shadow hash file. Note the new strings at the beginning of the file, which represent the new hashes SMB-NT (also known as NTLMv1) and SMB-LAN-MANAGER (sometimes known as "lanman"). The pwpolicy command shows that user2's shadow hash file contains three hashes: SALTEDSHA1, SMB-NT, and SMB-LAN-MANAGER.

The man page for pwpolicy reveals the purpose for all of the hash types, in the section "Stored Hash Types." The following table contains information about the hashes supported by Mac OS X.

Hash Types for Windows Sharing in Mac OS X

Hash Type	Also Called	Used for Compatibility with
SMB-LAN-MANAGER	lanman	Windows 9.x file sharing
SMB-NT	NTLMv1	Windows NT/XP file sharing

Many authentication protocols use a challenge-response mechanism. Just as it is no good to transmit the password over the network in the clear because eavesdroppers could capture and reuse the information, the same problem exists if you send the hashes over the network. If you used a hash of the password instead of the clear-text password and sent that over the network, eavesdroppers could simply reuse that hash. Instead, the authentication protocols require the client and server to compare their results of complex calculations on the hash, hopefully combined with some randomness; if the calculated results are the same, the server can assume the client knows the password. Again, the password is not sent over the network, and the hash is not sent over the network; rather, the result of calculations using the hash is sent over the network. The strength of the authentication protocol is affected by the strength of the hash itself, as well as the strength of the calculations involved.

Identifying NTLM Hash Vulnerabilities

One problem with the SMB-LAN-MANAGER hash type is that it is a fairly weak encryption type. If someone obtains a shadow hash file (by obtaining root access somehow), he or she can generate the password from the hash. Third-party (and unsupported by Apple) programs such as John the Ripper can break this hash in a matter of days. The SMB-LAN-MANAGER protocol, or LM, was introduced with Windows 3.11, and it is considered very weak.

Note

To generate and store the LM hash, all characters in the original password are converted to uppercase before hashing, resulting a much more limited keyspace to begin with. Because LM uses the Data Encryption Standard (DES) to generate the hash, and DES requires a fixed key size for its input, the password is either truncated to 14 bytes or padded with null bytes to make it 14 bytes. Those 14 bytes are split into two 7-byte keys. Each of these two keys is used to DES-encrypt the characters in the constant string "KGS!@#$%". The result of each DES encryption is 8 bytes of output. These two 8-byte outputs are concatenated, resulting in a 16-byte hash, which is stored. For more details, see www.ubiqx.org/cifs/SMB.html#SMB.8.

The SMB-NT authentication protocol, also referred to as NTLM, was introduced with Windows NT 3.1. It is similar to LM, with some improvements. The hash of the password is stronger, for example.

Note

To generate and store the SMB-NT hash, the original password is not converted to uppercase, which allows for a much larger keyspace to begin with. The password is hashed with the MD4 message digest method instead of DES. MD4 can use an arbitrarily-sized input, so the password does not need to be truncated nor padded. The result is a 16-byte hash that is much better than the LM 16-byte hash.

Though the NTLM protocol uses a stronger hash, it uses the same challenge-response algorithm, which provides only 56-bit encryption.

Note

Unless you specifically configure your Windows clients otherwise, it is likely that they will start with the worst possible authentication protocol, even though they can support better levels protocols, with the goal of being able to connect to older servers.

If someone obtains a shadow hash file (by obtaining root access physically or logically), he or she can generate the password from the hash pretty trivially. Third-party programs such as John the Ripper can break weak passwords with this hash in a matter of days.

More Info

See http://support.Microsoft.com/kb/147706/ for more information about the weaknesses of SMB-LAN-MANAGER and SMB-NT. For instance, the article claims that "hardware accelerators costing $250,000 have been built that can find either the LM or NTLM password-derived key in 3 to 6 days no matter how long the password is. These numbers change as technology gets better. . .Having the password-derived key of a user does not allow an attacker to log on interactively but, with special software, it is sufficient to access network resources as that user."

In order to remove the SMB-LAN-MANAGER and SMB-NT hashes, it is not enough to simply disable Windows Sharing. You must disable Windows Sharing for each user, and you need to enter each user's password in order to do this.

This brings up the importance of physical as well as logical security. If someone manages to get root access to your computer (by physical or logical means), he or she has access to your hash files and can crack your passwords in a matter of hours or days.

Removing NTLM Hashes

In version 10.3, Mac OS X Server automatically ran a Password Server; however, in version 10.4, the Password Server is not turned on until you configure a server as an Open Directory master.

When you create local users with the Accounts pane of System Preferences, or even with Workgroup Manager, you are creating users with shadow hashes. Mac OS X Server supports a few more types of hashes for local users. The following is an illustration of the hashes supported for local users under Mac OS X Server (note that the getglobalhashtypes works only in Mac OS X 10.4).

When you create a new local user, the CRAM-MD5, RECOVERABLE, SALTED-SHA1, SMB-LAN-MANAGER, and SMB-NT hashes will all be stored in that local user's hash file.

Some services, such as WebDAV, require a hash that is recoverable. If you are not using such services, you can disable the storing of various hashes with pwpolicy:

Here are the contents of a shadow hash file for a local user in Mac OS X Server. Please note that the number of characters in the hash does not reflect the security of the hash method. The most secure hash method, SALTED-SHA1, uses only 64 characters.

Contents of a Shadow Hash File for a Local User

Column	Contains Password Hash Type
132	NTLM and NTLMv2
3364	SMB-LAN-MANAGER
105168	CRAM-MD5
169216	SALTED-SHA1
2171240	RECOVERABLE

Some services, such as WebDAV and APOP, require recoverable hash methods, which need the clear-text version of the password to generate the necessary hashes. If you will not need certain hashes to be stored, disabling them is a good idea. The following screen shot shows how to do this with the pwpolicy command:

The pwpolicy command will affect only newly created local users. For existing local users, you can use Workgroup Manager to disable storing various hashes. However, in order for the hash change to take effect, you will have to either assign a new password or have the user change his or her password.

The Password Server in Mac OS X Server supports a larger group of password hashes than Mac OS X client does. If the Password Server is running, you can use telnet to communicate directly with the Password Server running on port 3659, also known as apple-sasl in /etc/services. (Note that the "Connection refused" is because IPv6 is enabled; you can safely ignore this refusal, and in fact, it will be handled for you automatically.) As you can see, there are more hashes supported by the Password Server, such as MS-CHAPv2, which is used for the VPN service.

Again, the Password Server is enabled when you configure a server to be an Open Directory master. When you create network users in the Open Directory domain, those users will have the password type of Open Directory. When you inspect the user record, the user should have two values for the AuthenticationAuthority attribute: one for Password Server and one for Kerberos.

In the following figure, the Workgroup Manager Inspector is used to examine the AuthenticationAuthority attribute of a network user, and there are two values. One starts with ;ApplePasswordServer; and the other starts with ;Kerberosv5;. Although you may not be able to see them in the line, you can copy and paste the full attribute into a text file and examine it.

In comparison, here is what Workgroup Manager shows for a local user that has been migrated from an earlier version of Mac OS X Server and still has the user password type of Crypt Password. Note that you can click the menu and migrate the user to a Shadow Password type.

Here is an example of a local account that has a user password type of Shadow Password. Note the Security and Options buttons.

Clicking the Security button will give you a GUI equivalent to the pwpolicy command to enable or disable the storing of various hashes in the user's shadow hash file.

Note that you cannot change NTLMv1 without also changing NTLMv2. Also note that NTLMv1/NTLMv2 are not listed separately as available authentication methods when you use pwpolicy. Although they are available, they both use the same root SMB-NT hash, and therefore do not have their own listing.

Note

For a user, if you use Workgroup Manager, click the Advanced button, and click the Security button to disable or enable an authentication method, the changes do not take effect until the user authenticates (or you specify a password for that user).

While you are examining user password settings with Workgroup Manager, you should also check out the password policy options, accessed via the Options button.

Finally, here is what Workgroup Manager has in the Advanced tab for an Open Directory network user. Note that the globe in the upper-left corner shows that you are looking at the /LDAPv3/127.0.0.1 domain, rather than /NetInfo/DefaultLocalNode. The User Password Type is Open Directory, and the user's PasswordID is displayed. The PasswordID is completely separate from the GeneratedUID, from which a local user's shadow hash filename is generated.

Note

pwpolicy is a utility that was originally written to be used on Mac OS X Server, but now can also create a limited set of password policies for local users. One of the primary uses of this utility is to require a minimum password length. The following command will force users on local computers to create passwords of at least 12 characters, whether or not they are connected to a directory server:

pwpolicy -n /NetInfo/DefaultLocalNode a administrator setglobalpolicy minChars=12

Defining Kerberos Pre-Authentication

An additional improvement in authentication security in Tiger Server is Kerberos preauthentication, which you could implement in Panther Server, but only by modifying the user principal via the command line. Pre-authentication requires a potential client to prove that it is making a legitimate request of the KDC in order to prevent brute force attempts at cracking the session key.

In order to obtain a ticket granting ticket (TGT), a potential client contacts the KDC with a KRB_AS_REQ (Kerberos authentication service request). The KRB_AS_REQ contains a user principal name, but in Tiger, it also contains an authenticator: a timestamp encrypted with the user's password. A potential cracker will not have the user's password with which to encrypt the authenticator, the KDC will reject the request, and the transaction will stop there.