Until now, we have assumed that hackers use network-sniffing software to intercept confidential data; however, there is as much danger in forged or spoofed data. Chapter 5 on SMTP/POP3 demonstrates how the sender can specify the originating email address arbitrarily, making it easy to send an email that appears to have come from someone else’s account. One can imagine the havoc this would cause if a student were to send an email purporting to be from a professor saying, “All lectures have been canceled. You can all go home now, and we’ve decided to give you all an A+ on your exams.”

This chapter deals with the tricky issue of confirming that a client is who he says he is and that no fraudulent activity is taking place. Authentication systems must be able to validate supplied credentials securely against trusted sources and also to ensure that the message has not been tampered with in transit.

This chapter is structured in four distinct sections. The first section deals with Microsoft authentication systems, such as NTLM and .NET Passport. This is followed by a discussion on techniques to detect data tampering. The chapter continues with an explanation of secure sockets layer (SSL), one of the most common security mechanisms for data delivered via Web sites. The chapter concludes with coverage of some other related authentication technologies, such as .NET permissions and legacy authentication schemes.

To guarantee the identity of a client, you need to trust one piece of information that is unique to that client and that cannot easily be determined or faked (e.g., IP address, Windows username/password, or some other credential). Authentication systems prevent the masquerading of credentials, but they cannot protect against a careless user compromising the security of a Windows password.

Several different types of authentications are applicable to different scenarios. If you are developing a solution for an ISP, then the chances are the ISP can be sure which client base has what IP address and, thus, can use IP addresses as credentials. When developing a Windows-only intranet application, you can trust Windows logins. Internet service developers may use a combination of the IIS authentication options or a custom username and password system.

The most basic form of authentication is IP address validation, where access to information is granted only if the IP address of the client is within a given range. This scheme is used by ISPs to limit access to technical support to current customers. They can do this because their customers will have IP addresses in the range that was assigned to the ISP. IP spoofing would defeat form of authentication, but this is not an easy undertaking. Only a select few determined hackers are capable of carrying it off.

IIS authentication

Although this book focuses on stand-alone software, using IIS as a server is always an option not to be dismissed lightly. This approach does remove some of the flexibility from the system, and it becomes necessary to use the encryption and authentication mechanisms that Microsoft provides, rather than proprietary protocols. IIS5 provides five kinds of authentication: anonymous, basic, NT challenge/response (NTLM, standard for Windows 9x and NT), Integrated Windows (Kerberos, standard for Windows 2000 and XP), and digest. The latter two options are not available on IIS4. Each kind of authentication offers varying degrees of interoperability and security.

The most basic form of IIS authentication, if it has a right to be called authentication, is anonymous. This is where the clients do not have to supply any credentials and are automatically granted IUSR (guest) privileges. This allows them to read and write files, but not to generate any graphical interface or access certain API functions.

One step above this is basic authentication. This forces the client to supply credentials in base64 (basically, clear text). This system is completely interoperable between browsers, but offers very little security; however, when combined with SSL, this is a secure solution.

Moving toward the Microsoft world, we have NT challenge/response, or NTLM. This is quite secure and cannot be broken without significant effort, but it can be hacked by a determined individual. NTLM is supported on IIS4 and all versions of Internet Explorer. The credentials supplied by the client will have to match those of a local account on the server.

Digest authentication was introduced in IIS5. There has not been widely publicized case of any hacker breaking digest encryption. It is compatible with most versions of Internet Explorer. Again, the credentials supplied by the client will have to match those of a local account on the server.

Kerberos provides one of the highest levels of security for authentication available over the Internet. It requires access to a domain controller and works only on IIS5 and recent versions of Internet Explorer.

To access authentication options on IIS, click Start→Control Panel→Administrative Tools→Internet Information Services. Right-click on the server in question, and click Properties. Select the Directory Security tab and press Edit (Figure 9.1).

Figure 9.1. IIS authentication dialog.

The screen in Figure 9.1 shows the authentication options for IIS. In this case, the lowest form of security is selected as the default. Options exist to upgrade this to basic authentication or NTLM. The option for digest authentication is not enabled here because this particular server has no access to a domain controller.

Apart from the security versus interoperability trade-off, there is also a security versus performance trade-off. On a benchmark computer (Pentium 3, 450 MHz, 128 Mb RAM), each of the preceding authentication systems was tested for performance in a high-load environment.

When accepting anonymous connections, the computer handled 860 requests per second. With basic authentication, the computer handled 780 requests per second, proving to be the fastest authentication mechanism, albeit with little security. NTLM incurred an additional overhead, reducing the overall speed to 99 requests per second. Digest authentication clocked in at 96 requests per second. With Kerberos authentication, the computer could handle only 55 requests per second. Finally, with full-blown SSL, the server dropped as low as a mere 2 requests per second.

Passport authentication is where users can be identified by their Hotmail email addresses. Other passport-supporting email accounts do exist, but Hotmail is the most prevalent. This form of authentication is not meant to secure international fund transfers, but it certainly suffices for personal communications. The advantage of passport over in-house-developed systems is that many people already have a Hotmail email address, and thus do not have to reregister their details.

Passport authentication is used primarily for Web sites, but can also be applied to applications, MSN Messenger being a good example. The online help for .NET Passport is centered on Web site development, but it is possible to implement a proxy service built as a programmatically accessible Web site that your application could connect to. This could then be used to obtain personal details from a user-supplied passport.

Passports are available in two flavors: preproduction and production. Preproduction passports are free, but only a limited amount of personal information can be extracted from a passport. Production passports are not free, and Microsoft will inspect your site or application before you are granted a production passport. You do, however, get the benefit of being able to read full personal details from visitors’ passports. Furthermore, a preproduction passport does not have the functionality to perform a sign-out operation.

The first step in implementing .NET Passport–enabled software is to obtain what is known as a site ID. This is simply a number, which is given to you when you register your details with Microsoft .NET Services Manager. On www.netservicesmanager.com, click Applications→Create Application, and then fill in all of the necessary fields.

Once you have a site ID, you can download the Passport SDK from www.microsoft.com/net/services/passport/developer.asp. This SDK should be installed on the server on which you intend to deploy the Web site, or the proxy server that is to provide passport services to the .NET-enabled standalone applications.

The final step is to download a private key that is to be installed on the deployment server. This can be downloaded under Manage Applications, in .NET Services Manager. The key comes in the form of an executable, which must be run from the command prompt as follows:

Partner###_#.exe /addkey
Partner###_#.exe /makecurrent /t 0

Where ####_# differs for different installations and site IDs. At this point, you may then run the passport administration utility (Figure 9.2). Enter your site ID in the space provided. Then press the Commit Changes button.

Figure 9.2. .NET Passport Manager Administration dialog.

To test the system, start and stop IIS using Computer Management, or the IIS snap-in, then press Refresh Network Map, and Commit Changes again. You should see the following Web site appear: http:/localhost/passporttest/, as shown in Figure 9.3.

Figure 9.3. .NET Passport test page.

Pressing the Sign-In button will bring you to a cobranded login page for Passport. On successful login, the browser will display the URL that was specified during the site ID signup procedure

Hashing is a one-way algorithm in which data can be converted to a hash value, but a hash value cannot be converted back to meaningful data. It is used in conjunction with encryption to ensure that messages are not tampered with in transit. Modern hashing systems include Message Digest (MD5) and Secure Hash Algorithm (SHA-1).

When a hash value is produced from a block of plain text, it should be computationally difficult to generate a different block of text that would yield the same hash value. A standard property of hashing algorithms is that a small change in the input text creates a large change in the hash value. Hash algorithms always produce output values with the same length, regardless of the amount of input text.

In practice, a hash value is generated for a given message, and then the message and the hash code are encrypted together. When the message is decrypted, a hash must match that of the message; otherwise, it may have been tampered with. Even though it would be impossible for a hacker to read this encrypted message in transit, it would be possible for him to alter the contents of the transmission, which could result in misinterpreted communications.

Another useful application of hashing is the secure storage of usernames and passwords. If an application stores username and password pairs in a database, it is easy for a professional hacker to access this database and read them off. If the password is hashed, the hacker cannot tell what the original password was. When the legitimate user enters a password into your application, the entered password will be hashed, and if it matches the value in the database, then the user is granted access.

This may pose a problem if the user forgets a password because the application cannot determine the original password from the hash. A system should be in place to replace passwords from an administrator’s account. More importantly, if the hacker can guess the hashing algorithm used, he could generate a hashed password, replace the existing one, and gain access. For this reason, where data integrity can be compromised, the hashing procedure should be combined with another form of encryption such as 3DES.

Hashing can also be used to prevent unauthorized data mining of online services. If you provide an Internet-based service that is accessed via a custom-made client (e.g., a DLL that provides currency conversion based on live exchange rates, or whatever), and you want only paying customers to access the service, the last thing you want is a competitor to use a packet-sniffing tool to determine what data you are sending to the server and create a product that uses your service without paying you. The obvious solution is to use asymmetric encryption; however, let us imagine that performance is the overriding factor, and asymmetric encryption would cause an unacceptable processing overhead.

A keyed hash (or a hash of the payload with an appended secret string of characters) of the data included in the header creates only a small overhead, but it makes the header impossible to re-create without knowing the hash key. This affords no security against your competitors’ reading what is being sent back and forth to your server, but it prevents them from generating their own client; however, you should take care that the client cannot be disassembled to view this key easily. A tool such as Dotfuscator (www.preemptive.com) can be used to obfuscate the code and help hide this key from prying eyes.

A real-world example of this system in use is the Google toolbar. This utility can display Google’s page rank for any given Web page. Google does not want people to be able to data-mine these values using automatic processes, so the request that the toolbar component makes to the Google server contains a keyed hash code for the Web site in question. It is difficult to predict this hash code, and requests made without this code return an error. Full-blown asymmetric encryption was not used in this case because it would have created unacceptable overhead for the servers to return data that is basically available to anyone.

Using SHA

Create a new Windows application in Visual Studio .NET as usual, and draw two textboxes on the form named tbPlaintext and tbHashed. A button named btnHash is also needed. Click on the button and enter the following code:

C#

private void btnHash_Click(object sender, System.EventArgs e)
{
  byte[] entered =
  Encoding.ASCII.GetBytes(tbPlaintext.Text);
  byte [] hash = new SHA1Managed().ComputeHash(entered);
  tbHashed.Text = Encoding.ASCII.GetString(hash);
}

VB.NET

Private Sub btnHash_Click(ByVal sender As Object, _
  ByVal e As System.EventArgs)
  Dim entered() As Byte = _
  Encoding.ASCII.GetBytes(tbPlainText.Text)
  Dim hash() As Byte = New _
  SHA1Managed().ComputeHash(entered)
  tbHashed.Text = Encoding.ASCII.GetString(hash)
End Sub

This code converts the text entered in tbPlainText into a byte array, and then passes this byte array to the ComputeHash method of the SHA1Managed class. The hash code is generated by an instance of this SHA1Mananged class. By substituting SHA1Managed with SHA512Managed or even MD5cryptoServiceProvider, the hashing will take place using that algorithm instead of SHA1.

You will also require the relevant namespaces:

C#

using System.Text;
using System.Security.Cryptography;

VB.NET

Imports System.Text
Imports System.Security.Cryptography

To test this, run it from Visual Studio .NET, type some text into the textbox provided, and press the button. A fixed-length hash will appear in the second textbox as shown in Figure 9.4. A small change in the plain text will cause a large change in the hash value, which will always remain the same length.

Figure 9.4. Secure hashing application.

The most common form of security used over the Internet is secure sockets layer, or SSL. SSL is a secure stream protocol, which uses both symmetric and asymmetric encryption, combined with digital certificates to provide authentication. Digital certificates can be bought from a certificate authority (CA) such as Thawte or Verisign. In order to buy a certificate, you need to prove your identity beyond doubt, which may involve providing a letter from your bank manager or the articles of association for your company. The certificate contains details of your server’s DNS name and your organization, and it is encrypted by the CA’s private key. The public key for every CA is installed in every browser, so anyone on the Internet can be sure that your company, and no one else, operates the machine that serves the page they are looking at. Furthermore, all data sent between client and server is encrypted with RSA.

SSL is defined in RFC 2660. The most common use for SSL is securing Web pages, but it can be equally applied to email, FTP, or news. HTTP over SSL (HTTPS) operates on port 443; SMTP over SSL (SSMTP) operates on port 465; and NNTP over SSL (SNNTP) operates on port 563.

SSL provides end-to-end encryption and authentication. Whenever a browser views a secure Web site, a padlock appears in the status bar. Clicking this icon will authenticate the server as belonging to a particular company, in a specific location. This is achieved by using server certificates.

A certificate has to be issued by a CA in order to be globally accepted. It is possible to create self-signed certificates, but these would generally be deemed trustworthy only within your organization. A digital certificate signed by XYZ Corporation would be trusted by employees of XYZ, but probably wouldn’t be trusted by the general public.

The most common form of digital certificate is known as X.509. This is an international standard maintained by the IETF Public Key Infrastructure (PKIX) working group. X.509 comes in three versions: v1, v2, and v3. Version 3 is the most commonly used form. The certificate comprises various fields that identify the holder, the issuer, and the certificate itself:

The subject has several predefined fields (Table 9.1), some of which are standard, but there are no strict guidelines as to what can or cannot be included in the subject line.

The certificate is not encrypted, but its contents are held in either Base64 or Distinguished Encoding Rules (DER). This is to facilitate transmission over plain-text email and to make it more difficult to sniff certificates from the network.

Some common myths about certificates should be mentioned in this context. Contrary to popular belief, certificates are not only used for Web page authentication; they can also be used in email (S/MIME) and general-purpose data (IPSec). Another common fallacy is that the private key should be kept in the HTTP root of the server it authenticates. This is akin to leaving the house keys under the doormat. The private key should never be transmitted over the Internet because if it is lost, it will need to be reissued. The issuer generally does not retain private keys for customers.

If you ever enter your credit card details into a Web site, the first thing you should look for is the padlock icon in the bottom right-hand corner of the browser. This icon not only means that the communications with the remote site are secure, but also that you can click on this icon and assure yourself that the company with which you are dealing is the owner of the Web site you are viewing.

Server certificates for real-world Web sites need to be obtained from a CA. For development purposes, however, it is possible to make self-signed certificates. A useful utility for creating self-signed certificates is IBM KeyMan (www.alphaworks.ibm.com/tech/keyman). You could also use Keytool, which is part of the Java SDK from Sun, but this utility doesn’t have a GUI and is more awkward to use.

The steps to enable HTTPS using a self-signed certificate and IBM KeyMan on IIS are as follows:

Whereas server certificates authenticate a Web site to a browser, a client certificate authenticates a browser to a server. Client certificates are only used for maximum-security Web sites, such as online business banking. Client certificates are available free of charge from Thawte. They are used to send and receive encrypted emails and to authenticate your email address to recipients. You will need to have a passport or social security number to receive a client certificate.

A basic client certificate only authenticates the email address, not the person who sent the email. To get your name on the certificate, you need to have a bank manager or attorney vouch for your identity. The rest of this section assumes that you have, at this point, received a client certificate from Thawte.

To view the client certificates installed on your system, open Internet Explorer. Click on Tools→Internet Options→Content→Certificates (Figure 9.5).

Figure 9.5. Internet Explorer Certificates dialog.

Clicking on View→Details→Subject on this screen will show which email address this certificate authenticates. Pressing Export will produce an X.509 (.cer) file, which is used in the next example program.

Reading certificates

Certificates can be read using the X509Certificate class (Table 9.2) in .NET.

Table 9.2. Significant methods and properties of X.509 certificates.

Method or Property	Description
GetCertHashString	Returns the hash value for the certificate as a hexadecimal string
GetEffectiveDateString	Returns the effective date of this certificate
GetExpirationDateString	Returns the expiration date of this certificate
GetFormat	Returns the name of the format of this certificate
GetIssuerName	Returns the name of the certification authority that issued the certificate
GetKeyAlgorithm	Returns the key algorithm information for this certificate
GetKeyAlgorithmParameters	Returns the key algorithm parameters for this certificate
GetName	Returns the name of the principal to which the certificate was issued
GetPublicKeyString	Returns the public key for the certificate
GetRawCertDataString	Returns the raw data for the entire certificate
GetSerialNumberString	Returns the serial number of the certificate

To write a short .NET application to read certificate files, create a new project in Visual Studio .NET. Draw two textboxes named tbCertFile and tbDetails. Add two buttons, btnBrowse and btnExamine. You will also require a File Open Dialog control named openFileDialog.

Click on the Browse button and add the following code:

C#

private void btnBrowse_Click(object sender, System.EventArgs
e)
{
  openFileDialog.ShowDialog();
  tbCertFile.Text = openFileDialog.FileName;
}

VB.NET

Private Sub btnBrowse_Click(ByVal sender As System.Object, _
 ByVal e As System.EventArgs) Handles btnBrowse.Click
   openFileDialog.ShowDialog()
   tbCertFile.Text = openFileDialog.FileName
End Sub

Once we have the name of the certificate file, we can use an X.509certificate object to decrypt the file and extract some pertinent information.

Now click on the Examine button and enter the following code:

C#

private void btnExamine_Click(object sender, System.EventArgs e)
{
 X509Certificate x509 =
 X509Certificate.CreateFromCertFile(tbCertFile.Text);
  tbDetails.Text = x509.GetName();
 tbDetails.Text += x509.GetIssuerName();
}

VB.NET

Private Sub btnExamine_Click(ByVal sender As _
System.Object, ByVal e As System.EventArgs) _
Handles btnExamine.Click
  Dim x509 As X509Certificate
  x509 = X509Certificate.CreateFromCertFile(tbCertFile.Text)
  tbDetails.Text = x509.GetName()
  tbDetails.Text += x509.GetIssuerName()
End Sub

You will also need to include the relevant namespace:

C#

using System.Security.Cryptography.X509Certificates;

VB.NET

Imports System.Security.Cryptography.X509Certificates

To test the application, run it from Visual Studio .NET. Click Browse, and locate your .cer file on disk, which you have previously exported from Internet Explorer. Press Examine, and you should see information about the issuer and the certificate owner, as is shown in Figure 9.6.

Figure 9.6. Digital certificate reader application.

Any programmer familiar with Java will know about the sandbox imposed on applets. This protects client computers from accidentally executing Java code that could potentially damage that computer. The restrictions include file reading and writing and connecting to a computer other than the one that the applet was downloaded from.

.NET offers the same sandbox architecture, which provides users with a facility to execute untrustworthy code without risking damage to their computers. There are several levels of sandbox, from trusted local computer to potentially dangerous code downloaded from an unknown site on the Internet.

Although there is no widespread usage of .NET applets running inside Web pages, there will be in the future. At present, the most significant impact the .NET sandbox will have on code is when a program is executed directly from a network share. This type of application deployment could be used on a corporate intranet, where a small application is executed from a central server at every login to record employees’ working practices and the like.

Code running from network shares is restricted in several ways. It cannot write arbitrarily to the local hard disk, but it can use an unlimited amount of isolated storage space on the local computer or the network share from which it was executed. Because unmanaged code cannot be governed by .NET, any assembly operating within a sandbox cannot make a call to unmanaged code. This includes any use of legacy COM controls or Windows API functions. Restrictions also apply to reading environment variables, performing reflection, and accessing the event log.

To view or edit the run-time security policy in .NET, you can access this from Control Panel→Administrative Tools→Microsoft .NET Framework Configuration. Then click Runtime Security Policy (Figure 9.7).

Figure 9.7. .NET permission configuration utility.

The System.Security.Permissions namespace offers facilities to check permissions programmatically and impose further restrictions on the code. There seem to be very few circumstances in which it would be necessary to impose further restrictions on an intranet application.

An interesting feature of code access security in .NET is the isolated storage feature. This is one idea that was not adapted from Java, unlike so many other features of .NET. This feature enables applications deployed over an intranet or other semitrusted source to read and write a limited amount of data to the host computers. If the application could read and write arbitrarily, the privilege could be exploited maliciously to read your personal emails, but isolated storage is a clever solution to this problem.

Isolated storage, as the name suggests, is where a small amount of hard disk space (10 Kb) is allocated to any particular application originating from a trusted Internet site. The folder where this data is placed is well away from the system folders and anything else that may contain user data. Each application is allocated its own folder and space such that untrusted applications cannot read each other’s data. The amount of isolated storage allocated to any particular application is configurable. This can prevent rogue applications from hogging too much disk space. Intranet-originating applications are allocated unlimited isolated storage.

To use isolated storage from within a .NET application, obtain an IsolatedStorageFile object and then create a stream to it. This stream can then be used in the same way as a FileStream.

C#

IsolatedStorageFile IsolatedStore;
IsolatedStorageFileStream IsolatedStream;
IsolatedStore =
IsolatedStorageFile.GetStore(IsolatedStorageScope.Assembly,
   null,null);
IsolatedStream = new IsolatedStorageFileStream("data.txt",
   FileMode.CreateNew, IsolatedStore);

VB.NET

Dim IsolatedStore as IsolatedStorageFile
Dim IsolatedStream as IsolatedStorageFileStream
IsolatedStore = IsolatedStorageFile.GetStore _
   (IsolatedStorageScope.Assembly, _
   Nothing,Nothing)
IsolatedStream = New IsolatedStorageFileStream _
   ("data.txt", FileMode.CreateNew, IsolatedStore)

Access to isolated storage in the case described above would be allocated on a per-assembly basis. Isolated storage can also be allocated on a per-user basis, per–domain name basis (for Internet code), or a combination of the above.

If a hacker were to break into an e-commerce site successfully and capture someone’s credit card number, some unfortunate person would get stung financially; however, if the same thing happened on an interbank network, a country’s economy could be ruined overnight. Banks and financial institutions use a diverse array of cryptography and authentication systems, which are not accessible to the general public.

The threat to security so far has been pictured as a lone hacker trying to steal credit cards; however, a rogue nation or terrorist organization could use a network of supercomputers to bring down a large national bank in order to cripple a country’s economy.

Most banks use private leased lines between their branches so that the confidential information does not come into contact with the public phone network. ATMs usually employ VPN links to the bank. ATMs are limited to a maximum value of transactions they can perform, so it would be impossible to use one rogue VPN connection to drain a bank of its capital.

When a bank needs to communicate with a second financial institution overseas to perform, it must use the public phone network. Where communications between two banks happen on a daily basis, a private virtual circuit (PVC) is set up between the two banks. This reduces the amount of foreign data on the line, but neither bank actually owns the telecom connection. The communication will be very strongly encrypted in one of two main formats: ISO 8730 or SWIFT.

This chapter has looked at the mechanisms for guaranteeing the identity of network clients over the Web and on Microsoft networks. The structure and use of digital certificates in a distributed environment were discussed. Extending the topic to real-world scenarios, we looked at how banks use authentication to transfer billions of dollars safely across phone lines.

Sample code was provided to demonstrate how to process a credit card payment securely over an SSL connection. This type of facility is commonplace in most e-commerce solutions, point-of-sale systems, and many other software products.

The next chapter introduces the concept of application scalability (i.e., how software performs under heavy usage and when designed to run reliably for long periods).