So should we pull the network plug?

Let us concentrate on what conclusions we can draw from the above for designing more secure applications.

The most obvious is probably, you're in deep trouble if your application operates in an untrusted network, and needs to handle data that's valuable, or confidential, or both. You cannot trust that the entity you're talking to is really the one you're talking to (regardless of whether you verified its authenticity based on a password, or its network address); you cannot trust the data you receive is the data that entity sent; you cannot trust that the data you exchange doesn't end up on the hard disk of a crook (or a government agency, for that matter). If you're in such a situation, there's little you can do except using cryptography to authenticate who gets access to your data, and to protect it from eavesdropping and modification. But beware - just using encryption technology more or less at random doesn't automatically give you security (there's a long list of examples of ``failed'' security standards - the 802.11 WEP protocol and Microsoft's PPTPv1 being just two of the most prominent). We will come back to the topic of cryptography in chapter .

On the other hand, there are a number of very useful network services that are fairly vital to office environments, such as NFS, Microsoft's CFS, etc. In their default mode, these protocols offer hardly any protection from network level attacks. If you talk to the users of these protocols about security issues, you will most likely get a blank stare and a shrug. Most people don't care much about risks involving computer hackers walking into their office to steal their data. And in many cases these people are right. In most office type environments, there is an implied trust in the employees. Why use top notch cryptography to protect NFS traffic when the door of the safe remains unlocked throughout most of the day? And concerning strangers walking into their offices intent on doing harm, there are much worse people than computer geeks to worry about.

Thus, it is perfectly reasonable for an application to be designed without taking care to protect from all snooping/spoofing attacks, if you make it abundantly clear to the users of your software that it should not be used across untrusted networks, and in particular not across the Internet. People like to joke that NFS really means No File Security, but still it's the most widely deployed file sharing protocol in the Unix world. The fact that governments in general, and the US in particular, have tried to prevent the creation of secure, crypto-based software notwithstanding, the most likely explanation is that IT managers everywhere believe the risk is small enough, and that additional security of alternative solutions such as AFS or DFS is not worth the the cost and pain involved in deploying them.

However, the reverse is not true either. Just because people like the convenience and performance of protocols such as NFS and CIFS, this doesn't mean you will get away with security blunders that open up their data to random attackers from the Internet. When pointing out potential security problems, I have repeatedly heard people tell me, ``Oh, don't worry about that. People will usually run this code behind a firewall anyway.'' Most of the time, I find this is just a lame excuse. One, I have a problem with statements that say ``usually,'' because the environments customers may want to use some piece of software in are so diverse, you cannot claim to know what situation your code will run in. Second, there's a mentality thing. I cannot understand how programmers can take such a cavalier attitude towards the security of their customers. Sure, you can build a car that falls apart if you go faster that 70 mph, because usually, you shouldn't drive faster than that (in the US, anyway). But would you buy such a car?

Well, enough soapboxing. To sum it up, even with such ``trusting'' applications, there is a bunch of things to be aware of. We'll look at these throughout the remainder of this chapter.