Why Software Developers Control Our Security Fate
Here is a great example of why users have to demand that developers up their cyber security game. Unless the developers make smart security choices, we will continue to make life easy for hackers. The examples on how web sites handle passwords described below should make this point clear.
Don’t ever store passwords in plain text – I can’t even count the number of times that I have seen evidence that a web site stores my password either in plain text or in an encrypted form that they can decrypt. The whole idea of a password is that I am the only one who knows it. If ANYONE else can see my password then it is no longer secure and you can no longer be certain that actions protected by that password were actually performed by me.
One indication that the password is stored unencrypted or in a manner that someone else can decrypt is when you, yourself, can see it when you log in to the system that it protects. If you can see it, so can the developer. Or when the system or customer service representative can provide you the password when you forget it rather than making you choose a new one after verifying your identity.
Allow special characters – Have you ever tried creating a password with a special character such as an exclamation point and get some vague error message? Or worse yet, the instruction next to the password field says that you can only use numbers and letters.
Why would a developer stop you from using any characters of your choosing? Because using certain characters cause a problem for the developer. Rather than dealing with this problem, the developer takes the easy route out and says don’t use those characters.
Of course, the fewer the characters to choose from, the easier it is for an attacker to figure out your password. And all because it was easier for the developer. Security decisions should not be made based on how easy the solution is for the developer but rather how secure the solution is.
Don’t modify the password – I recall setting up a password at a bank to conduct online banking. Very diligently I created a good password with a mix of upper and lower case letters and numbers only to discover that the bank’s web site ignored the character’s case. I could enter the password in all upper case, all lower case or in mixed case and any of those choices would grant me access to my account. Why would a bank do this? My guess is that the developers figured that customers would accidentally confuse the case of characters in their password and the bank would “help” their clients by making case irrelevant.
You can easily test whether a system does this by changing the case of characters in your password and see if you can still log in. You may be surprised by the number of sites that this works on.
Sometimes sites will allow you to enter special characters but then strip them out as if they did not exist. Or allow you to enter a 15 character password but then ignore any characters past, say, 8.
Do not ever send me my password in plain text in an email – It is amazing, in this day and age, that systems still send me an email after I sign up with my password in it. Unencrypted. In plain text.
I am sure that this is done as a customer service feature. Surely the customer would like to have an email with their userid and password in case they forget it. Sometimes sites will send you your password in an email when you tell them that you have forgotten it. This means that they have violated the second rule (storing passwords unencrypted or reversibly encrypted) and the fourth rule (sending me my password in email).
If we look at these four rules for something as easy as managing passwords and then expand it to all aspects of a security development life cycle, you can see that developers play a crucial role in the security of the system.
Sometimes developers make these decisions on their own; other times they will ask management or marketing what they would like to do. To rarely do they say that client security dictates that they do it in a particular way.
It is critical, in a development organization, to have someone who acts in the role of security advocate. The person who will say that the organization’s role is to secure the customer’s information even if that means that the developers have to work a little harder. The person who will listen to all the reasons why some feature is a good or bad idea and point out that the decision made reduces system security.
In many cases the head of development is supposed to act in this role. But just like when the Chief Information Security Officer reports to the CIO, the head of development has a conflict. Do I opt for the harder problem to solve, potentially impacting cost and schedule or do I close my eyes and ignore the long term security implications of the decision.
Ultimately, it is the role of the CEO or Board to ensure that such a position exists and is independent of conflict. In many cases, this means that this person reports directly to the CEO.
Food for thought.
Information for this post came from Infoworld.
by 