The best security system is only as safe as its authentication scheme. Although many secure applications exist, users can jeopardize efforts to secure applications by using generic passwords such as 1234, not using any passwords at all, or writing passwords and leaving them in places where they can easily be discovered. Remedies such as password dictionary check or minimum password lengths are available to safeguard potentially unsecured applications; however, not all application security problems can be solved programmatically. Assuming that steps will be taken to exclude reckless password behavior on the part of users, in this section we take a look at the security process of authentication, which involves identifying and validating users, and potentially revalidating users as an ongoing process.
Windows NT users are authenticated by the MSV1_0 Authentication Package that corresponds to MSV1_0.DLL in Windows NT's <systemroot>\SYSTEM32 directory. Conceptually, MSV1_0 is split into two halves. The top half is responsible for receiving the logon request and determining whether the request is to the local or remote Windows NT computer. If the request is local, MSV1_0 passes the logon information to the bottom half of MSV1_0. The bottom half of MSV1_0 in turn authenticates the user by referencing the local security database. However, if the logon request is to a remote Windows NT computer, the top half of MSV1_0 passes the logon information to the local computer's Netlogon service. The Netlogon service in turn passes the logon information to the remote Windows NT computer's bottom half of MSV1_0. When the Netlogon services of two computers communicate, challenge/response occurs. Challenge/response doesn't occur with local logons. The request is answered and returned to the top half of the local Windows NT computer's MSV1_0 through the respective Netlogon services.
We focus mainly on network authentication as it relates to Windows NT LAN Manager (NTLM) security over the network via challenge/response. However, MSV1_0 also supports interactive logons, service logons, and network logons. All forms of logon through the MSV1_0 Authentication Package pass the name of the domain containing the user account, the name of the user account, and some function of the user password. These various types of logon differ in the way the password is represented. For interactive logons and service logons, the client logging on is physically on the computer running the top half of the MSV1_0 Authentication Package. In this case, the clear (unencrypted) text password is sent into the top half of the MSV1_0 Authentication Package. The top half of the MSV Authentication Package converts the clear text password to both a LAN Manager password and a Windows NT password before sending it on to either the Netlogon service or the lower half. The lower half queries the passwords from the Security Account Manager (SAM) and compares the passwords to ensure they are identical.
The following steps are an example of how a user might log on locally or remotely to a Windows NT system:
After the validation process, the user's shell process is given an access token. For Windows NT 4.0, the token is associated with Explorer.exe. The information in this access token is a reflection of anything the user does or by any process that runs on the user's behalf.
Kerberos authentication was developed within the think tanks of MIT. It is a ticket-, session-, and trust-based authentication scheme. The Kerberos Authentication included in Windows 2000 is based on Kerberos v5. When compared with the Windows NT domain strategy, the Kerberos authentication protocol provides the following benefits:
Applications that use process access permissions can take advantage of additional security providers on Microsoft Windows 2000 and can use delegate-level impersonation and cloaking to affect the security credentials used during method calls. Delegate-level impersonation is established by the client process and allows a server to impersonate the client and to pass the client's credentials to remote computers. Previously, servers could impersonate the client only to access local resources. Cloaking is used to hide an intermediate server's identity from a destination server. For example, if Client A calls Server B, which then calls Server C on Client A's behalf, and Server B has cloaking enabled, Client A's identity will be used for calls to Server C.
The transition from the NTLM authentication used in Windows NT 4.0 to Kerberos domain authentication can be very smooth. Windows 2000 services support client or server connection using either security protocol. The transition from enterprise-based services using Kerberos authentication to Internet-based services using public-key authentication (discussed later in this chapter) is mostly transparent to the user.
Almost every Web browser on the market supports a basic form of authentication that involves sending a username and password in clear text over the Internet or an intranet. Unfortunately, this basic authentication allows this information to be stolen by others. Because organizations need to provide secure access to information on their networks and servers, user authentication is an important aspect of a Web server. In addition to the security provided by Windows NT, Microsoft Internet Information Server (IIS) 4.0 includes additional security features that Windows NT uses to correctly identify users, determine their level of access, and create a secure Internet connection.
In this section, we first describe the IIS 4.0 authentication technology. Then we discuss Microsoft's Secure Channel technology, which is used to protect networked data from prying eyes when communicating in Internet or intranet environments after users have been authenticated.
IIS 4.0 provides support for the Windows NT challenge/response authentication, which uses a cryptographic technique to authenticate the password. The actual password is never sent across the network, so it cannot be captured by an unauthenticated source. Challenge/response is supported by Microsoft Internet Explorer 2.0 and later versions.
When Windows NT challenge/response authentication is enabled, the user's Internet Explorer browser proves its knowledge of the password through a cryptographic exchange with the Web server. If the authentication exchange succeeds in identifying the user, the user is not prompted for account information. However, if the authentication exchange initially fails to identify the user, Internet Explorer prompts the user for a Windows NT account username and password, which it processes using the same Windows NT challenge/response method. Internet Explorer continues to prompt the user until the user enters a valid username and password or closes the prompt dialog box.
Windows NT challenge/response authentication takes precedence over basic authentication. If the user's Web browser supports both authentication methods, it chooses Windows NT challenge/response authentication.
Web applications can use simple cookie mechanisms to track and identify users. Cookies are small files sent from the server to the user's computer, where they are stored locally. These identification cookies typically contain a globally unique identifier (GUID) that can be requested and queried by a Web server. Although cookies provide a simple means of identifying users, they should not be used when the information being accessed is considered confidential or private. A cookie can be intercepted in transit, or even copied from a user's computer, and anyone can then use it to represent himself or herself as the cookie's user. Although the concept of stealing cookies is similar to that of stealing logon usernames and passwords, cookies are technically much easier to "borrow."
Digital certificates give users a secure method of logging onto a Web site without having to remember logon usernames and passwords. IIS supports the use of X.509 certificates for access control. Certificates verify identity in much the same way as driver's licenses or corporate identification cards do. They are issued by a trusted certificate authority, either a department within an organization or a public company such as VeriSign or Entrust. How rigorously IIS checks identities or credentials when issuing a certificate depends upon the level of security—or trust—required for the information or application being accessed.
Certificate-based client authentication requires a protocol that can handle certificates at both the client end and the server end, as well as the appropriate requests and replies.
Unique digital identifications, called server certificates, form the basis of a Web server's Secure Sockets Layer (SSL) security features. Server certificates, obtained from a trusted, third-party organization, provide a way for users to authenticate the identity of a Web site. The server certificate contains detailed identification information, such as the name of the organization affiliated with the server content, the name of the organization that issued the certificate, and a unique identification file called a public key. This information helps to assure users about the authenticity of Web server content and the integrity of the secured HTTP connection. The public key, along with another privately held key, form the SSL key pair. A Web server utilizes the key pair to negotiate a secure TCP/IP connection with the user's Web browser. (Although the key pair serves a vital role in establishing a secure link, the key pair is not directly used for data encryption.)
With SSL, a Web server can also authenticate users by checking the contents of their client certificates. These encrypted files are similar to conventional forms of identification such as driver's licenses or passports. A typical client certificate contains detailed identification information about a user and the organization that issued the certificate. Each user enters a password when signing his or her certificate, and this password is required every time the certificate is activated for use. As with a driver's license, mere possession of a certificate does not constitute proof of ownership. Only the owner of the certificate should know the password because it is the key to verifying access.
This method maps the client certificate to the Windows NT server user account and requires a copy of the certificate. The Web server has a client certificate-mapping feature that authenticates users who log on with client certificates, without requiring the use of basic or Windows NT challenge/response authentication. A certificate mapping relates the contents of the user's client certificate to a corresponding Windows NT account, which is a file that defines the rights and access policies of the user. After a mapping is created and enabled for a particular user, each time that user logs on with his or her client certificate, the Web server automatically connects, or maps, that user to the appropriate Windows NT account.
This approach is ideal when the Web site issues its own certificates using a certificate server, such as Microsoft Certificate Server, which is included in the Windows NT 4.0 Option Pack.
When using wildcard mapping, the IIS server doesn't need to possess the client certificate, but instead authenticates the user based on information stored in the certificate, such as "SubjectName." IIS 4.0 also includes a Microsoft ActiveX component that automates the wildcard mapping using an Active Server Page (ASP). For example, a business could set up an ASP page that asks users whether they want to map their certificate to their Windows NT Server user account. If a user chooses to do so, the information in the certificate is mapped to the appropriate Windows NT Server user account.
IIS 4.0 can authenticate users who log on with a client certificate by creating mappings that relate the information contained in the certificate to a Windows NT user account. Using the Web server's certificate mapping feature, IIS 4.0 can either map a specific user's client certificate to an account (a one-to-one mapping), or map multiple certificates to an account. To map multiple certificates, wildcard-matching rules must be defined that create a mapping by verifying only whether a certificate contains certain items of information. For example, to map all users who log on with client certificates issued by a particular organization, a wildcard-matching rule could be defined that automatically maps any certificate issued by that organization to a single user account, rather than creating a separate mapping for each client certificate.
Programmatic Use of Certificates
Client authentication in IIS 4.0 goes beyond pure authentication and access control. Information in the certificate is exposed to both ASP and Internet Information Server Application Programming Interface (ISAPI) applications. As a result, developers try to create custom ASP and ISAPI applications that can serve personalized content, control access, or query databases based on the information fields in the client certificate. Developers can use client certificate authentication, along with SSL encryption, to implement a very tamper-resistant method for verifying user identity.
Microsoft Certificate Server
Internet Information Server 4.0 Option Pack contains certificate management features available through Microsoft Certificate Server, and standard cryptographic API functions available through Microsoft's CryptoAPI, which we discuss later in this chapter. Certificate Server has the following features:
In this section, we discuss the various types of security available with Microsoft SQL Server, including standard security, integrated security, and mixed security.
Standard security uses SQL Server's own logon validation process for all connections. Connections validated by SQL Server are referred to as non-trusted connections. Standard security is useful in network environments with a variety of clients, some of which may not support trusted connections, which we discuss below. Also, standard security provides backward compatibility for older versions of SQL Server.
Integrated security allows SQL Server to use Windows NT authentication mechanisms to validate SQL Server logons for all connections. Connections validated by Windows NT Server and accepted by SQL Server are referred to as trusted connections. Only trusted connections are allowed. Integrated security should be used in network environments where all clients support trusted connections. The clients of SQL Server in a three-tier application are MTS components.
With Windows NT 4.0, MTS components must be authenticated by a domain controller. Authentication of a component by a domain controller over the network adds extra traffic and therefore extra expense. With Windows 2000, Kerberos helps hold down traffic by carrying information that allows direct component authentication without taking a trip to the domain controller.
When the SQL Server logon security mode is set to integrated, an MTS component's login is validated as follows:
When mixed security is used, SQL Server validates logon requests using either integrated or standard security methods. Both trusted connections (as used by integrated security) and non-trusted connections (as used by standard security) are supported. Mixed security is useful in network environments that have a mixed client base. For those clients that support trusted connections, Windows NT validates logons. For clients that support only non-trusted connections, SQL Server validates logons.
When a server's login security mode is set to mixed, a component's logon is validated as follows:
Integrated or mixed security is recommended for enterprise solutions using Windows NT Server, MTS, and SQL Server. Integrated security makes management of logons easier because accounts can be administrated from one source in Windows NT. Also, developers can avoid coding logon IDs and passwords into their components or placing them in ODBC DSNs. Any logon changes under standard security forces components to be recompiled or ODBC DSNs to be tracked down and updated.
As we've said, SQL Server requires a logon ID and password. We'll now demonstrate how a component can implement such a security measure.
A component supplies its logon either through the ConnectionString property of the ADO Connection object, or as a Connection String parameter to the Open method of the Connection or Recordset objects. If a component supplies a logon ID and password, the component connects using standard security. If the component does not supply a logon ID and password, the component connects using integrated security, and within MTS, the component's package identity is used as the logon.
If the connection is through an OLE DB provider, the provider must be notified that integrated security is to be used. The logon ID or password should not be provided, but instead the Trusted_Connection attribute should be set as shown in the following code:
Dim conn as ADODB.Connection Set conn = New ADODB.Connection conn.Provider = "SQLOLEDB" conn.ConnectionSTring= "Data Source=MYSERVER;' & _ "Initial Catalog=Pubs;Trusted_Connection=Yes" conn.Open