Encryption

So far, we've discussed only one aspect of security: authenticating users and authorizing tasks. Authentication is the heart of security design, but it's not the only consideration. With a network sniffer, a malicious user could extract ticket GUIDs, usernames, and passwords as they flow between client and server, not to mention sensitive data such as credit card information. If you use integrated Windows authentication, malicious users won't be able to retrieve passwords and account information, but they will still have easy access to any other sensitive data transmitted between the client and the server-side object. In fact, if you're using the SOAP format, this information is sent in clear-text messages.

The only way to protect communication in a distributed system is to use encryption. There are two basic approaches:

• Use SSL to enable automatic encryption. This is supported only by components hosted in IIS.

• Use the cryptography classes in the .NET Framework to selectively encrypt sensitive data.

The first approach is far easier to implement, provided you're using an XML Web service or a remote component hosted in IIS. It also ensures industrial-strength protection. The second option is significantly more work, but it allows you to protect sensitive data in specialized scenarios (for example, where you want to encrypt only a portion of the data exchanged between client and server) or when the environment doesn't support IIS and SSL.

Note

Even if you use SSL encryption to secure distributed communication, it's still worthwhile to explore the custom cryptography classes provided with the .NET Framework. You can use these classes in a variety of scenarios. For example, the same code you use to encrypt messages can be applied to secure persisted data, such as files on the hard drive or binary fields in a database.