There have been many publicized events where a lack of security resulted in exposure of private data, such as social security numbers and other identifying information.  So an important aspect of developing networked applications bears focused attention: Any server-side code has ultimate responsibility for validating everything that enters the system, in particular, security credentials.  Even for systems that exist entirely within a corporate network, or where a thin or thick client is created in concert with an application’s server-side components, it’s still safest to assume that a client may be malicious. Often attacks come from within an organization’s network.  Think of the server side as the gatekeeper that stands between the network and your data.

As you architect and build a system that takes requests over a network connection, consider the worst case and plan for that. Approach it this way: Is there a role that your client-side code plays in protecting your data where your data would be compromised if the client’s code were bypassed?  It might be something as simple as JavaScript that validates the range of a number.  If the server-side does not also validate the data, it is possible for a malicious client to corrupt your data by bypassing the client code. That is what you want to avoid.  The resulting damage might be minimal, but it could be quite dangerous when the data is part of a security implementation or allows SQL injection.

Consider Security Implications Beyond the Project at Hand
In practice, the risk of corrupted data or a compromised system is often balanced with other considerations, such as the cost of security or the potential for damage. 

"Making a system more secure almost always results in trade-offs, such as reduced performance, additional development effort, or reduced usability," said Don Branson, TDK Software Developer. "If you are creating an internal application that employees use to view the company’s holiday calendar, the potential for damage is less than for an application used to store resumes or record payroll information."

For example, an application you are building may not store secure information on its own.  Perhaps you’re just building a system for fellow employees to sign up for pager rotation, and you secure it with a simple user ID and password.  So you decide security is not a concern, since at worst, a breach means the pager rotation schedule is lost and has to be recreated.  However, the potential risk is broader than just the system you are building.  Most people use one or a small number of passwords, and re-use them from system to system.  The result is that the password that some people use for the pager rotation will be the same password that they use for their online trading account or banking account.  So there is risk to your system, but there is additional risk to the users of your system.

Despite the risks, application developers often do not take the time to encrypt stored passwords.  The best approach is to use existing software for password storage that was built by someone who understands the potential modes of attack.  Issues not apparent to you at first blush are already known and solved.  For Java applications, Hashing Java is a specific implementation and discussion that is reasonably straightforward.  Applying the techniques and code described there can protect your data and your users’ passwords when your network security is breached and intruders gain access to your database.

Technology solutions to business problems.