Secure programming tip No. 5: Add delays to your code
Many attacks rely on using a computer to relentlessly try and try again. It may take thousands, millions, trillions of iterations, but the computer doesn't care. Some people screenscrape databases by sending millions of queries pretending to be a user. Others try trillions of potential passwords until just the right one is found.
The trick is to add progressively more delay to confound these bots. In many cases, you don't want your software to be very fast or very efficient. You want it to be fast enough to support the right humans but much too slow for the attacking bots to get much accomplished.
Some log-in programs double the delay with each incorrect password. Some databases limit the number of queries coming from each IP address. Some systems deliberately send an email request to a human to slow you down. It's all in the interest of security because humans won't notice the extra second or two, but a bot will be bored to the point of being ineffective.
Secure programming tip No. 6: Use encryption more often than you think you should
Encryption is often underused because it adds yet another step to the machinery -- and makes debugging that much harder. It can be hard enough to find errors in a system; it's even harder when the data is some inscrutable pile of numbers.
But what's inscrutable to you is also inscrutable to the attackers. Locking up personal data before storing it in the database saves you the trouble of worrying about the database, the underlying operating system, and to some extent the hypervisor that might be running underneath it all.
The right amount of encryption doesn't need to reduce functionality. I examined a number of different examples in my book "Translucent Databases" that can still provide useful services while protecting personal information. Plus, extra protection is itself a feature.
Secure programming tip No. 7: Build walls
The need to add security often can't compete with the demand for ease-of-use. People hate to keep logging into different parts of the system, but it can be dangerous to link all of the systems and powers together into one portal. One weak link compromises everything.
There is no easy way to decide just how easy it should be for a user to navigate the system and accomplish what they want with just one click. The easier you make it for the legitimate user, the easier you make it for an attacker who slips in.
It can make sense to segregate the most sensitive operations into a separate system and require people to log in again when they want to use it. A bank might give a portal the ability to check status and deposit money, but it might require substantially more authentication before money is withdrawn.
Secure programming tip No. 8: Tested libraries -- use them
Encryption is hard to do well, and even the best theory and carefully built code can have loopholes and backdoors. It's usually a mistake to reinvent a well-tested library, but it's even more problematic with encryption. Well-tested libraries are more important in this field than others. Choose better code here and don't invent your own algorithms.