This instructable will tell you the key steps necessary to designing more secure programs.

Step 1: Where to Begin...

Writing secure code is a must for any programmer but more specifically for programmers who write programs that connect with the Internet. With more and more vulnerabilities being discovered by hackers, you want to make sure your program is sturdy enough to survive all these hack-attacks.

The most important (and the most boring part) is to analyze your code. Usually there are programs that analyze your code for you but sometimes they miss snippets that a human has to find.

I will go over the most basic vulnerabilities in a program so that you can get a look at how to secure your program's code.

Step 2: Take Responsibility

You MUST take responsibility for your own program. If something doesn't work, you can't go blaming something else or someone else. After all, it's YOUR program. You're the one whose designing it and knows its inner workings. Be a man (or woman) and grow a pair in plain English (if you're not a woman ;-)).

Step 3: Make a Threat Model

People tend to think visually, making a model of all the threats against your program is a good idea.

To get a figure of what threats your program will face, know what your program will be doing.

If its a program that connects to the Internet, most likely hackers and buffer overflows are your main concern.

If you're making a game, you need to make sure your program doesn't hog up a lot of memory and resources, as that could slow down and potentially crash your client's computer. Then you'll be receiving a lot of hate mail and angry phone calls about a buggy game that wasn't worth their $45.

If its a program that does a lot of number crunching, you need to watch out for dangers related to numbers (obviously), like integer overflows.

If you are making a database, your upmost concern is safeguarding your data. Nowadays, managers don't care how the database is designed as long as it keeps the data safe from corruption and infiltration.

Step 4: NEVER Trust Data

Usually, you'll be working on a project with a whole team of other programmers. When working on your part of the program, you need to treat everything else as foreign, a possible threat. Seriously. You can NEVER trust data, no matter where it comes from.

This is a key problem with most of today's programmers: they don't validate input!

This serious bug leads to a buffer overflow or SQL injection, where programs just accept whatever data is coming their way without checking it to see if it is in the correct format or length.

You NEED to get in the habit of validating input to your program before doing anything else, otherwise you'll be hacked faster than you can say, "Oops". Validating input is a strong way to secure your program from outside threats.

Step 5: Recognize the Strategic Asymmetry

This is one of my favorites. Remember that as a software developer, the security odds are stacked against you. I like to call this the "Attacker's Advantage, and the Defender's Dilemma." You need to get the code and the designs 100 percent correct 100 percent of the time, and that is impossible. To make matters worse, you must reach this insurmountable goal on a fixed budget, on time, while having to consider requirements of supportability, compatibility, accessibility and other "-ilities." An attacker can spend as long as he wants to find one bug, and then announce to the world that your application is insecure.

I am not trying to scare you, I am just saying that you need to try and stay one step ahead of the hackers. "Try" is the keyword. You cannot sit back and wait for a hacker to exploit your program and THEN fix it, you need to always be on your toes and constantly update your program before it can be attacked.

Step 6: FUZZ!!!!

Fuzzing is a testing technique that was invented to find reliability bugs. It turns out that a percentage of reliability bugs are security vulnerabilities waiting for the right exploit! Sure, a buffer overrun might crash an application, but given a well-crafted malicious payload, the crash might not happen, and the attacker could run code to do his bidding instead. Our motto around here is "today's denial of service is tomorrow's code execution."

Fuzzing is a semi-automated or fully automated process that involves sending random bits of data and input to a program to see how it responds.

Interesting inputs would include environmental testing, such as mouse and keyboard events or API calls.

Tools to fuzz test your program are not really publically available yet, so you're going to have to create a program that does this or rely on some other testing techniques.

Step 7: Don't Write Insecure Code

If you are writing your code in C, C++, C# or any other C-language, PLEASE don't make calls to strcpy or strncat. That is just an exploit waiting to happen. Also, don't use lousy encryption. No custom encryption algorithms are allowed. None. Even if you think your new encryption algorithm is good, most likely it is a variation of an existing, older technique. This means you will be easier to hack.

If you are going to use encryption, always use an industry standard algorithm, like AES (or advanced encryption standard. Though some speculate the NSA has broken this already, it's still your best bet).

Step 8: Read Books

Reading books about information security will teach you some strategies I did not discuss here and help teach you how to make even more secure code.

Step 9: Special Thanks to My Viewers and Followers

I know this is irrelevant to the article, but I would like to thank my viewers and followers. Really. I thought I would be that person who makes how-to articles but only gets like 25 views. Special thanks to you guys. And to those of you who have been asking if I will make a Learn How to Hack - Part 3, how can I not? ;-) I still have plenty to teach.