Although Windows 98 does not implement built-in security anywhere near the level found in Windows NT, a number of security-related features have been added and/or improved upon from Windows 95. These changes, in a nutshell, are as follows:
Secure channels support includes Point to Point Tunneling Protocol (PPTP), which enables users to connect securely to a remote network, even over an intervening insecure network if necessary. This is accomplished by means of encrypted encapsulated packets and enables one protocol to be nested inside another. Thus, a user can connect, for example, to the Internet via TCP/IP, then establish a secure IPX connection to his or her office network. Support for Secure Socket Layer (SSL) has been upgraded to SSL 3.0, which increases the level of encryption that can be applied to Internet and intranet data exchanges.
Smart card support consists of a two-layer driver model designed to encompass smart card reader hardware, together with the APIs used to authenticate, write to, and retrieve data from smart cards. These cards have at least three important uses: as user authentication in place of (or in addition to) logon sequences, for transacting financial business over the Internet and elsewhere, and as portable data repositories for storing bits of information such as one’s drug allergies or dental history.
Crypto API, Authenticode, and Microsoft Wallet support first appeared as part of Internet Explorer (IE), and they are still being included with the various platform versions of IE.
Table 20.1 summarizes the security features of Windows 95, Windows 98, and Windows NT.
Table 20.1: Security Features in Windows 95, 98, and NT
| Technology | Windows 95 | Windows 98 | Windows NT |
| Authenticode | Add-on (IE4) | Yes | Yes |
| PPTP client | Add-on | Yes | Yes |
| PPTP server | No | Yes | Yes |
| Smart cards | Add-on | Yes | Yes |
| Crypto API | Add-on (IE4) | Yes | Yes |
| Microsoft Wallet | Add-on (IE4) | Yes | Yes |
| Group-level security | Partial | Partial | Yes |
| File-level security | No | No | Yes |
| Object rights and privileges | No | No | Yes |
As you can see from the Table 20.1, Windows NT and Windows 98 share many of the same security technologies, particularly the Internet-related security technologies. The chief way that they differ is in Windows NT’s absolute, “from the ground up” internal security features, which incorporate myriad low-level security checks at every point where objects can be accessed within the operating system.
A good example of the different levels of security in Windows NT and Windows 98 is in file access. In Windows 98 (and Windows 95), security is only on a folder and drive level; you cannot set individual access rights at the file level. In part, this is because there are many different means of getting at a file in Windows 98—through various DOS interrupts, BIOS functions, Windows APIs, and various language (Pascal, C++, and so on) file-access APIs. With these various file-access methods come many resulting security loopholes, which would require extensive patching to fix and would likely break many existing applications in the process. (Keep in mind that much of this code was “adapted” from good old 16-bit code.) Also, there is the overhead such checks would add to file access.
Such compromises were understandably deemed undesirable for an operating system that is marketed more to home users than to business users, who have a greater need for security. As the Internet keeps growing to subsume more of our daily affairs, such security will become increasingly necessary even for the home users, who have been flocking enthusiastically to the Internet.
In short, these differences between Windows 98 and Windows NT center primarily around the thorough way that Windows NT internally checks access rights and in the security hooks exposed at the programming level, which allow programmers to build the same level of robust security into their own applications. This security technology is exposed by what is referred to as the security API. Although this API is considered part of the Win32 API (or of late, the Win Base API), it is fully implemented only in Windows NT.
What these differences mean to programmers is that truly secure applications require Windows NT. This should come as no surprise to you—one of the main advantages Windows NT has over Windows 98 is its extensive built-in security.
Therefore, despite this being a book about programming Windows 98 applications, in this chapter we’ll devote some space to a discussion of the workings of Windows NT’s security. Even if you have no interest in incorporating security in your own applications, knowledge of the security API is important for the following reasons:
Although Windows 98 provides minimal support for the security API, there is good news regarding Windows 98’s support for encryption. This means that you can use encryption with Windows 98 applications to provide an effective level of access control in certain instances. Currently, every function of the crypto API (except those few functions that deal with data in Unicode format) works the same on both Windows 98 and Windows NT platforms.
You will probably not be surprised to learn that only very few of the security API functions are implemented in Windows 98. Your application may call any one of these functions while running on a Windows 98 station, but it had then better be prepared to check the error-return code, note that the function failed, and take appropriate action.
The only correct way to use the Windows NT security API functions is in the context of a server application. While it is possible to design a server application to run on a Windows 98 station, it is not possible to do this where the server application needs to implement Windows NT-level security (using the Win32 security API at any rate). And this would seem to be the case for most, if not all, server applications. The better and simpler approach is to require the application to be run on Windows NT, and simply issue a complaint message and exit if someone tries to run the application on a Windows 98 station.
Having said that, let me also suggest that you may not want to simply perform an operating system version check and then exit if the version number doesn’t match. I have seen some older Windows applications that, when run on the latest versions of Windows NT, get confused and complain that they require a newer version of the operating system. So assumptions about what is or isn’t an appropriate operating system to run an application, based solely on getting the operating system version number, are prone to errors in certain cases. A better approach is to look at those categories of functionality needed by your application that are not currently supported by a subset of the operating systems that are otherwise capable of running your application. Then, when your application loads, have it perform checks for any missing functionality, and either exit or else modify its behavior or functionality accordingly.