Secure programming tip No. 2: Store what you need, and not one bit more
Before you ask for your customer's snail mail address, ask yourself whether you will ever send them a physical letter through the post office. If email is sufficient for correspondence, you might want to rethink storing home or business addresses. That information costs time to process, takes up disk space, and makes an attractive target for information thieves.
Programmers often think like obsessive hoarders, storing away copies of anything that stands the least chance of someday being useful. This instinct may help debug software, but it leaves a trail of data for anyone to find.
Is every column and table in the database absolutely necessary? When in doubt, make the forms shorter and the database tables smaller. Avoid the temptation to be a data pack rat. Simplify everything. The data thieves will hate you, but everyone else will enjoy spending less time filling out forms.
Secure programming tip No. 3: Avoid trusting passwords more than necessary
Everyone knows the problem with passwords, but no one knows a better solution. People forget their passwords, choose ones that are too simple, then reuse them again and again. Yet no other solutions are as flexible or as simple.
Some companies are already using N-factor authentication by tossing several different hurdles in the way. They might send a text message with a random number to your cellphone and ask you to type it in along with your password. It's a nice mechanism unless you forget your cellphone, burn down the batteries, or find yourself inside a building where the text messages can't reach.
It's always possible to add even more security with special hardware that locks up cryptographic keys. They are expensive, though, and even easier to lose than a cellphone.
Other sites keep track of the IP addresses you use to log into their service. If you approach the system from unknown address, they send you a polite email just in case.
None of these choices are perfect, but they are better than just relying on a password. The important step is recognizing the limitations of a string of letters even if some have the right mixture of uppercase and lowercase letters, numbers, and punctuation marks.
Secure programming tip No. 4: Negotiate requirements
Building secure code is not just something that happens in the code editor. When managers draft requirements and discuss them with developers, everyone should seriously consider how each requirement could open the door to problems down the road.
A feature may be cute, but will it force you to keep additional sensitive information and increase the level of security required everywhere? Is a slick feature worth all those extra headaches? The right time to start securing your code against future breaches is when the requirements document is still flexible and the customers aren't salivating over the features you've promised them.