Summary

This chapter has discussed many of the .NET issues regarding wireless security. It has also taken a quick look at other wireless security issues, but not discussed them in depth. The bottom line for developers is that you need to consider many more security factors when working with wireless. Not only do you have the problems normally associated with desktop, LAN, and Internet communication to consider, but you also have the natural problems of wireless to consider. Any time you transmit data using radio waves, the data is openly available to anyone within listening range.

Part of your testing strategy as a developer has to include wireless security issues. You might want to check how well someone can receive data from your application outside the company walls. Spend time looking for potential holes in your code based on the operating conditions you find. For example, crackers can and will try to find holes in your data encryption. They’ll look for places where your application leaves data in the open. Once you begin testing the application thoroughly, you might find it easier to build a case for not allowing the application to run on wireless than to try to secure this communication method.

Chapter 14 begins a discussion of the requirement to use the Win32 API to perform some security tasks. This chapter demonstrates how to access the Win32 API using PInvoke. Many developers are convinced that the code access and role-based security implemented by the .NET Framework will answer every need. While this form of security is far superior to anything Microsoft has produced in the past, the fact remains that you still need to access older code and that means understanding the security that code uses. In addition, as demonstrated by the example in the “Working Directly with the Domain Controller” section of Chapter 12, you must perform some tasks using the Win32 API because the .NET Framework doesn’t provide the proper functionality.