NT Gatekeeper: NT Password Cracking Tool

Get answers to your security-related NT questions

[Editor's Note: Do you have a security-related question about Windows NT 4.0? Send it to [email protected], and you might see the answer in this column!]

NT 4.0 stores a hashed version of user passwords in the SAM. With enough time and processing power, Security Software Technologies' L0phtCrack can crack these hashes and obtain the passwords. How can I create passwords that L0phtCrack can't crack?

First, here's some background information: L0phtCrack is an NT-password-cracking tool. To obtain L0phtCrack 2.5 or learn more about it, visit Security Software Technologies (http://www.securitysoftwaretech.com/l0phtcrack).

L0phtCrack can retrieve password hashes from the local system registry and from the SAM on NT repair disks or on system backup files (which can reside on the file system or on backup tapes). L0phtCrack can even recover password hashes as they travel across the network. With a command-prompt utility called pwdump2, L0pthCrack can also circumvent Syskey, an NT 4.0 Service Pack 3 (SP3) feature that offers an extra level of cryptographic protection for the data in the SAM. (For more information about Syskey, see the frequently asked question "How do I use the System Key functionality of Service Pack 3?" at http://www.windows2000faq.com/articles/index.cfm?articleid=14762. For more information about pwdump2, visit http://www.webspan.net/~tas/pwdump2.)

After L0phtCrack retrieves the password hashes, it uses different methods to crack the hashes and discover the passwords. (See the sidebar "L0phtCrack's Password-Cracking Methods" for more information about these methods.)

Do uncrackable passwords exist? "How to Make Windows 2000 and NT 4 Passwords Uncrackable," a recent article on the System Optimization Information Web site (http://sysopt.earthweb.com/articles/win2kpass), says they do. To create uncrackable passwords, the article says to include one of 187 special characters in your NT password. (The character list is available in the article.) L0phtCrack doesn't use any of these characters, even if you include them in a custom dictionary (for a dictionary attack) or a custom character set (for a brute-force attack). To see whether including special characters in passwords makes the passwords uncrackable, I ran a test for three user accounts: a, ç (the letter "c" with the cedilla diacritical mark under it), and º (the symbol for "degree"). The passwords of the three accounts were identical to their account name. As Figure 1 shows, L0phtCrack didn't crack the two special-character accounts' passwords. (To speed up the test, in the L0phtCrack password file, I defined a custom character set that included only these three characters, as Figure 2 shows.)

Cracking passwords, however, is simply a question of processing power and time. I'm sure that one of the next releases of L0phtCrack will include these 187 characters. Even then, people who don't have huge amounts of processing power at their disposal will find cracking such passwords impossible. Adding these special characters to passwords has a huge impact on the amount of time a brute-force attack requires. Doubling the character set doubles the number of characters that L0phtCrack (or another cracking tool) must try for every position in the password and exponentially increases the time it takes to break a password hash.

An important note to keep in mind if you decide to use these special characters (or require your users to use them) is ease of use. None of these characters are available from a keyboard's standard keys. Users must hold down the Alt key and type numbers on the keyboard's number pad to create these characters (e.g., I typed Alt+135 for ç and Alt+167 for º for the special characters I used in my test). Such passwords are hard to remember, and users might end up writing them on paper, which could end up lost or in the wrong hands.

Our IT department is moving and must rearrange the contents of the company's file servers. When you copy files and folders to another drive (from the command prompt or by using Windows Explorer), NT doesn't retain the original NTFS permissions, nor does it retain shares and share permissions on the copied folders. How can I retain these settings?

Microsoft provides a set of command-prompt tools that you can use to retain NTFS and share permissions and share configuration settings when you copy files and folders between NTFS-formatted drives. Table 1 lists the tools. Some of these tools come with the NT OS and some are in the Microsoft Windows NT Server 4.0 Resource Kit. Because they're all command-prompt tools, embedding them in batch scripts is easy.

A server in my domain is installed in a dual-boot configuration, and both installations use the same machine domain account. The first installation, a file server, is the server's primary function. I use the second installation infrequently to issue certificates, and I've installed an NT Certificate Authority (CA) on it. To limit the risk for CA private-key compromise, I secured the second installation with Syskey. (I store the system key on disk and keep the disk in a safe place.) For security reasons, the OS regularly changes machine passwords. Changing the password on only one installation, however, generates logon errors when the other installation boots up and logs on to the domain. How can I prevent the OS from changing the machine password in either installation?

You can disable machine password changes with the DisablePasswordChange entry of type REG_DWORD in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters registry subkey. You must set this value in the registry of both installations of your server's dual-boot configuration. Table 2 shows the DisablePasswordChange entry's values and their meanings. The table also shows two related entries: RefusePasswordChange and MaximumPasswordAge.

The RefusePasswordChange entry disables the password-change capabilities of a domain controller (DC) for all machine accounts. If you enable this entry, you must set it on every DC (including PDCs and BDCs). Don't use this entry for the situation you describe, however, because it would disable password changes for all machines in the domain.

The MaximumPasswordAge entry sets the interval for automatic password changes. To use the MaximumPasswordAge entry, you must run SP4 or later.

The DisablePasswordChange setting is an option for the scenario you describe in your question. In all other cases, disabling password changes is, from a security standpoint, unwise. Passwords are shared secrets (i.e., shared between machines and DCs). The longer a shared secret exists, the longer an intruder has to brute-force crack messages that use that shared secret for security. To minimize the security risks and enable password changes in your scenario, you must change your setup and use two different machine accounts, one for each installation.

I recently installed the Security Configuration Editor (SCE) on some file servers. Now the interface of the Security dialog box shows different NTFS file and folder permissions. Also, some permissions have been deleted. What happened?

The SCE installation program automatically installs a new ACL editor. Because the new ACL editor consists of a basic view and an advanced view, it looks as though some permissions are missing, but they're simply in the advanced view. Let's look at a before-and-after-SCE-installation view of the ACL editor: Figure 3 shows the permissions that user Copernicus has before the SCE installation. Figure 4 shows how Copernicus's permissions look after SCE installation in the new ACL editor's basic view. Clicking Advanced brings up the advanced view (which Figure 5 shows), in which you can set more-granular access permissions, control inheritance, change ownership, and configure auditing settings.

The permissions you see in the basic view are groups of permissions. If a user or group is granted only a couple of the permissions contained in a group of permissions, the Allow check box beside the group of permissions won't show up in the basic view of the ACL editor. To see the individual permissions in a particular group of permissions, go to the advanced view of the ACL editor. For example, in Figure 4, you don't see permissions for Copernicus. When you click Advanced, you see the view in Figure 5, which shows that Copernicus has Change Permissions on the subfolders and files of the folder Galileo.

On my local NT machine, I logged on to the domain and accessed the data, even though no DC was available to validate my domain logon credentials. After the logon, I received the message A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on may not be available. What's going on? How can I disable this feature in environments with higher security requirements?

Every time you log on interactively to a domain (aka a local logon), your local system caches your domain credentials in its memory. "Domain credentials" in this context means a protected copy of the hashed password. Because of this feature, you can log on to the domain when no DCs are available or when your machine is disconnected from the network. Logging on with cached domain credentials gives you access only to the local resources on your machine, not to any resources hosted on other domain-member machines.

From a security standpoint, this feature clearly has risks. Some people claim that intruders can access the cached credentials, but exploits of this kind haven't occurred so far. The real concern about credential caching is that users can intentionally disconnect a local machine from the network, for example, to get around the fact that the administrator disabled the machine's domain account, then still log on to the domain. This type of logon, however, gives the user access only to local resources.

You can disable cached-account logons and force a user's machine to contact a DC before the user can log on to the domain. To disable cached-account logons, create the CachedLogonsCount entry of type REG_SZ and set the value to 0 in the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon registry subkey. (Warning: Don't set this value to 0 on mobile users' laptops. These users would be unable to log on with their domain credentials when away from the office.)

You must restart your computer for this change to apply. With this setting enabled, when no DC is available, a user can still log on to a local machine by using a local account. Although this key doesn't appear in the registry by default, NT caches a set of 10 domain credentials by default. The maximum value for CachedLogonsCount is 50.