In this post I’m going to talk about website security. This is just a top-of-the-waves blog post. Consider it a jumping off point for you to dive deeper into specific security subjects. As a software developer, everyone should understand what precautions should be taken to ensure that your company’s website will not appear on the evening news.
I’m not a security expert. I’m also not an expert in the field of encryption. My experience stems from the fact that I’ve been through a few “incidents” in my career involving a user or employee who has broken into the software that I maintain. When your company gets hacked, it humbles you. All your assumptions about how good you are at securing your software go right out the window. The basic problem with security is that you must be conscious of all the tiny details. The potential hacker only needs to find a very small opening.
Here’s is a video (on YouTube) that every developer should watch. It’s very entertaining, but also informative. This video shows a group of white hat hackers who were hired to hack into the U.S. power grid. Their job is to perform the act and then report back to the company on what they need to do to secure their systems:
Watch Hackers Break into the US Power Grid
Notice how these guys obtained a tiny bit of information using a technique called social engineering. This is normally the starting point. Their next step is to install some trojan horses (in their case they installed physical devices on the network of the main office as well as software on some of the laptops).
Most hackers are current or former employees. These are people who already have inside knowledge to get them started. The infamous hacker Edward Snowden was a contractor that worked for the NSA. He was an IT person with enough privileges to get information out of the system, in bulk. He also used social engineering to convince fellow co-workers to give him access to their data.
Other hacked sites involved really dumb programming mistakes. Citi was hacked by a user who realized that the account number was a parameter in the website url. They changed the number and refreshed their browser, allowing them access to over 200,000 accounts (How Hackers Stole 200,000+ Citi Accounts Just By Changing Numbers In The URL).
SQL injection is a very common mistake. Here’s a rather long list of sites that contained injection vulnerabilities: The Code Curmudgeon SQLI Hall-of-Shame.
Hard-coded passwords… sigh. So many devices, so many hacked systems: Hard-coded password exposes up to 46,000 video surveillance DVRs to hacking. Here’s an article about the Internet of Things:These 60 dumb passwords can hijack over 500,000 IoT devices into the Mirai botnet. If you read down the article you’ll stumble onto this quote: “To make matters even worse, the default credentials cannot be changed as they are hardcoded in the firmware and there are no options for disabling them. The telnet service is also difficult to disable.” Never hard-code a password. Always allow a method to change the user id’s and passwords. There should also be a setup that forces the purchaser to change the admin password right away.
Custom encryption or hashing. Don’t do it. Use an existing algorithm and make sure you understand which hash algorithms are appropriate for saving passwords into your database. Use a salt to prevent someone from using a lookup website to reverse a hash. A salt is not optional. There are many unsalted MD5 hash lookup websites. Every developer should read this information on hashing passwords: Salted Password Hashing – Doing it Right.
Don’t Assume Anything
Building a secure piece of software requires the developer to be a bit paranoid. I roll my eyes when a developer begins to spit out an excuse for taking the easy route. Usually the excuse is along the lines of “nobody knows what the name of that database is..” or “how likely is it that someone will…”. Hackers are very smart. Don’t let cheesy Hollywood movies fool you into thinking that hackers are just clever 8-year old kids with some scripts they downloaded from the internet. Hackers can be former developers with a copy of your database. They may have run a bruite-force algorithm on your password hashes and have admin passwords to enter your system. This is the reason for a password policy that forces users to change their passwords on a regular basis. Here’s a really good system for finding all 8-character passwords: 25-GPU cluster cracks every standard Windows password in <6 hours.
Protect your backup files. A backup file can be copied to a thumb drive and then restored to another machine. A potential hacker can run a brute force attack on such a restored system until the cows come home. Once a user-id and password has been found, then the hacker has what they need to enter the real system.
Keep tight firewall controls. It’s sometimes easy to just open up a bunch of ports to make something work. This is OK for testing purposes, but your production system should be as closed to the outside as possible. Here’s an example of a vulnerability for Active Directory from the internet: Researchers show how to steal Windows Active Directory credentials from the Internet.
Finally, here’s a list of common programmer mistakes that can let a hacker into your system: Coding Horror – Top 25 Most Dangerous Programming Mistakes.
Security through Obscurity
There are two basic meanings for this saying. In one instance, instead of securing something, just obscure the name of it (like an admin account with no password, or a linked server with elevated privileges). Don’t fall for this trap. This just means that only external hackers with no knowledge knows about this. It doesn’t mean that they can’t figure it out or that a disgruntled employee won’t use it. Using an obscure user name as the admin user name (instead of “admin”), and using a strong password is OK. Obscuring the admin user name makes it more difficult for a brute force attacker to attack a site. It isn’t going to slow down a laid-off software developer with a copy of your database.
Just for fun, here’s a list of the Worlds Biggest Data Breaches. This list is arranged by year with relative sized circles based on the size of the breach.