7 Simple Ways To Write More Secure Code

Share and Comment

It’s not easy to write secure code, but it’s something that you need to think about before forming the first loop. Managers, auditors, software engineers, and infrastructure architects invested in secure coding, try to imagine all possible worst case scenarios with every piece of the code. While, of course, it’s not possible to anticipate every possible adverse scenario, thinking ahead reduces the number of opportunities to attack. It closes holes and safeguards against a variety of possible security breaches.

While it’s not possible to cover every way to produce much more bulletproof code, here are 7 suggestions that will get you thinking in the right way:

#1: Test all your inputs.

Your code opens doors to the Internet. All software that takes input from the Internet is vulnerable. Think of these doors like paths that hackers can use to sneak into your machine. So test inputs.

#2: Don’t hoard information for future use.

Coders are a little like pack­rats. They like to hoard information, stacking away copies of anything that might be useful at a later date. While this habit is highly beneficial when it comes to debugging software, it leaves a trail of breadcrumbs that a hacker can put to malicious use.

#3: Passwords are not enough.

Theoretically, passwords should do the job if they are done properly—with an alphanumeric string, with a minimum of eight characters, and with a mix of letters, numbers, and symbols. Unfortunately, human error compromises the strength of passwords. People use their personal names or nicknames, names of family or friends, and names of their pets. They use their social security numbers, house numbers, anniversaries and birthdays. Then, if that’s not problematic enough, they forget their passwords, only use simple ones so that they remember, and reuse the same password for all their accounts.

Passwords do work if done right, and, to be fair, nobody has come up with a more flexible or simpler method. However, don’t rely on passwords as your only security measure. According to a hard­hitting article by Mat Honan in Wired, it may actually be time to kill the password. It’s no longer working for civilization.

#4: Discuss risks and options with the team.

Secure code is not just what happens with a code editor. Managers and company executives, many who may have no technical skills, are also involved in the development of software. When requirements are being drafted, everyone involved in the project needs to talk about the potential risk of each requirement.

#5: Build in progressive delays.

Although it may seem counter­ intuitive to slip in some delays in the code because it makes things more inefficient, there is a good reason for it. Attacks are often automated, which means an attack could have hundreds, thousands, even millions of iterations. A bot­­ pretending to be a human user ­­ could literally send a million or more queries. It could also try every possible password combination a trillion times until it stumbles upon the right one. All these attacks thrive on the elegance and efficiency of your code. However, it you build in delays, especially those that get progressively longer, it will stymie these fake users.

# 6: Encrypt much more.

Programmers, as a rule, don’t like to use too much encryption, for some good reasons: it adds still one more step, makes debugging even more difficult, and makes it tougher to track down errors. Elegant coding is hard enough without having to scramble over a pile of enigmatic numbers. An excellent example of efficient encryption can be seen in some of the newest network security software, which uses FIPS 140­2 validated AES­256 encryption to protect all ultra-­sensitive information.

#7: You can’t please everyone.

Users want one thing from computers: ease of use. This is a great marketing idea and one that was extensively used by Steve Jobs to make Macs, iPods, and iPads fly off retail shelves, but it is a terrible idea when it comes to security. When you don’t link up all parts of a system together into one seamless piece, then users have to log into each part. Although it is awkward, it improves security­­ because it drastically reduces the threat of a single weak link allowing complete access to the system.

The Growing Security Threat

Why are all these security measures necessary? After all, it makes coding much more cumbersome and code less elegant. It also irritates users who have to work with less efficient software. However, the reason to write secure code is simply because there is now an enormous need for security. According to the Internet Security Threat Report, the number of security attacks is on the rise each year. In 2013, 552 million consumers had some form of identity information stolen through a breach. This was 62% more than the year before, where there were 253 breaches in total. We may have to rethink everything when it comes to coding and security.

Share and Comment