Prefactoring

13.3. Security and Privacy

Security and privacy are complicated issues. You need to deal with both administrative and development facets to make a secure system. Before implementing invoices and discounts, Tim and I consider the security and privacy issues.

13.3.1. Security

With the addition of CreditCard to Customer, CustomerCollection contains some sensitive data. We need to protect that data from prying eyes ("If You Forget Security, You're Not Secure"). Since we used CustomerCollection as the interface to the data, we can assign responsibility for protection of that data to that class and to classes with which it collaborates. We could apply a number of techniques to provide this protection. For example, we could encrypt all information in the collection in whatever persistence mechanism was used to store the collection. That way, the data would be relatively safe even if the file were copied. Only when a Customer is retrieved would the data be decrypted.

Security is not just a matter of encryption, but includes examination of all interfaces into a system. For example, CustomerCollection has a mechanism to search for customers by name. Sam needs to decide where to draw the line between ease of use and security. If the search allows the matching string to be a single character long, an errant user can find all names of customers with only 26 or fewer searches. If the search allows the empty string as a match criterion, a single search could produce a list of all Customer ...