Developer Responsibility

As developers we often forget that users put a lot of trust in us to do not just the most efficient and expedient thing to make sure their experience between landing on our site and finally purchasing those tanned buffalo leather swim shorts is quick and easy, but also to do the right thing with their information. We often fail to scrutinize data properly, adding weak points into our applications and possibly providing the information we have stored to a person with less naive motives. We are on the front lines of data security, although most of us only have a pail and a tooth brush and are not expecting any attacks or unscrupulous users to come our way.

Little do we know, our past is pock marked with horrible events of user security and we need to be prepared. Many of you may not realize how insecure the internet fundamentally is. Two and three factor authentication is now the norm, and VPN is now the only way to conduct any business with anyone on a network. There are worms, and SQL injection and many other forms of malicious entities out there. We cant possibly guard ourselves and sites from them all. The net is fundamentally a battleground; a battle between good and evil that will go on for eternity. Where one man stops and says … “I cannot be hacked!” … another picks up and tears them apart. The only thing we can really do is protect the information so that when we are hacked nothing of any value is lost.

This is of course a falsehood. There are plenty of ways to protect a site, but you can put far less energy into protecting the site if you spend some time encrypting data and answering the question that plagues web development – do I really need this datum?.

There are two things we need to discuss; first, the question of whether we need this datum or not. If you are not selling anything, what purpose does asking for a credit card number serve? If you are selling something what reason do you have to store their credit card number? If you have no real answer to this aside from convenience or nosiness, I urge you to reconsider. Just as when you put one of those nasty disclaimers in fine print for the user to sign their lives over when they click a button, you have to accept some terms as well. When they click that button, you are providing an implicit acceptance of the user’s information and are going to keep it safe, not hand it over to spam or store it inappropriately. Consider what you would do if Amazon started letting anyone have access to users credit card information. It is absurd to believe that it would be unnoticed and not cared for. Sensitive information needs to be treated as such.

Now, since you have come to the conclusion that you really need that information stored, its time to start looking into how that works. Do you store it in the Credit_Cards table with a string or group of characters under the field called Number? Probably not. Do you store passwords under plain text? If you do you should go look at my other article on why that’s a terrible idea. You need to encrypt, maybe even something along the lines of having two computers, one not attached to the net. Store the actual number on the second computer and the first computer stores xxxx xxxx xxxx and the last 4 numbers or whatever, for visual reference to the card. It’s a tough road to travel, but im sure you get the point.