Many Windows NT-based applications use passwords that the SAM database doesn't store. Applications such as Microsoft Outlook, Internet Explorer (IE), Internet Information Server (IIS), and SQL Server all store passwords in various locations on the system, so be aware of these locations and act to prevent unwanted access.
For example, one of the most widely used applications on NT is IE. Although using IE doesn't require a password, many Web sites you're likely to access with IE do. Poor Web site design leads to all kinds of security trouble, especially when cookies store usernames and passwords that the site requires for access.
Cookies have a programmable lifetime, so you can set them to expire immediately. This action causes the cookies to remain in memory only while the site is using them in a live interactive Web session, so they aren't written to disk. NT immediately writes cookies that contain usernames and passwords that don't expire to the \systemroot%profiles\ username\cookies directory.
Anyone with access to a user's cookie directory also has access to all the cookies it contains, including those that contain sensitive information such as usernames and passwords. A malicious Web site operator who knows which cookies to look for can extract them from the Cookies directory without the user's knowledge. This situation isn't a security flaw in IE. It's just the nature of the HTML cookie specification.
To protect yourself, you need to habitually examine and delete cookies that contain sensitive information—just open the cookie files with a text editor and see what's in them. You also need to complain loudly to sites that store sensitive information in disk-based cookie files, because this practice presents a huge security risk.
The Outlook client doesn't store passwords in clear text anywhere on the system during regular operation. However, if you're accessing a POP3 server, it will transmit passwords over the network in clear text. These passwords are easy to grab with a generic packet sniffer. POP3 requires the use of clear-text passwords, so Microsoft can't do anything to remedy this problem. Nonetheless, if you must use a POP server to get your mail, consider using Authenticated Post Office Protocol (APOP) instead of POP3 because APOP uses encrypted passwords.
Also be aware that SQL Server stores passwords in Registry keys when you configure it to handle its user authentication. Those particular Registry keys have very little protection. For example, when you register a SQL Server system using the SQL Executive, it writes the username and password for that server to the Registry under the HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\ MSSQLServer tree. Obtaining SQL Server passwords is easy for any savvy user with interactive logon rights to the server, so be careful which users you grant the right to log on locally to your SQL Server systems (or any servers for that matter). You'd be wise to disallow remote Registry access on all NT systems that you can. But you must carefully plan this configuration because many network management packages and software installation routines require remote Registry access to operate correctly.
Someone recently discovered that Microsoft's BackOffice Server installation routine leaves user passwords written to disk in clear text and in areas of the file system that regular users can access. During installation, the program creates the reboot.ini file in the \program files\microsoft backoffice directory. If a user chooses to install SQL Server, Exchange Server, or Microsoft Transaction Server (MTS) as part of a BackOffice 4.0 installation, the installation program requests the name and password for the accounts associated with these services.
More specifically, the setup program asks for the account name and password for the SQL Executive Logon account, the Exchange Services Account, and the MTS Remote Administration account, and stores this information in clear text in the reboot.ini file. After the installation completes, the setup program fails to delete the file. Be certain that you don't grant unwarranted file system access to your BackOffice servers. If you have an adequately secured system, you shouldn't encounter this problem. Nevertheless, make sure you delete this file manually after a BackOffice 4.0 installation is complete. For more information about this problem, see the Microsoft article "BackOffice Installer Tool Does Not Delete Password Cache File" (http://support.microsoft.com/ support/kb/ articles/q217/0/04.asp).
