Passwords and other secrets in source code

key-under-matSecrets are bad. Secrets in source code are an order of magnitude worse.

Secrets are difficult to protect. Every attacker goes after the secrets and we must protect our secrets against all of them. The secrets are the valuable part of our software and that’s why they are bad – they represent an area of heightened risk.

What would a developer do when his piece of software needs to access a password protected server? That’s right, he will write the user name and the password into some constant and compile them into the code. If the developer wants to be clever and heard the word “security” before, he will base64 encode the password to prevent it from “being read by anyone”.

The bad news is, of course, that whoever goes through the code will be able to follow the algorithm and data through and recover the user name and password. Most of the software is available to anyone in its source form, so that is not a stretch to assume an attacker will have it as well. Moreover, with the current level of binary code scanning tools, they do not need the source code and do not need to do anything manually. The source and binary scanners pick out the user names and passwords easily, even when obscuring algorithms are used.

So, the password you store in the source code is readily available. It’s really like placing the key to your home under the doormat. It’s that obvious.

Now, you shipped that same code to every customer. That means that the same password works at every of those sites. Your customers and whoever else got the software in their hands can access all of the sites that have your software installed with the same password. And to top it off, you have no way of changing the password short of releasing a new version with the new password inside.

Interestingly, Facebook had this as one of their main messages to the attendees of the F8 Developers Conference: “Facebook security engineer Ted Reed offered security suggestions of a more technical nature. Reed recommended that conference attendees—particularly managers or executives that oversee software development—tell coders to remove any secret tokens or keys that may be lurking around in your company’s source code.”

Which means the story is far from over. Mainstream applications continue to embed the secrets into the source code defying the attempts to make our software world secure.

The thought of compiling the user names and passwords into the application should never cross your mind. If it does, throw it out. It’s one of those things you just don’t do.

Security Forum Hagenberg 2015

sf_logoI will be talking about the philosophy in engineering or the human factor in the development of secure software at the Security Forum in Hagenberg im Mühlkreis, Austria on 22nd of April.

https://www.securityforum.at/en/

My talk will concentrate on the absence of a holistic, systemic approach in the current software development as a result of taking the scientific approach of “divide and conquer” a bit too far and applying it where it should not be.

It may seem at first that philosophy has nothing to do with software development or with security but that is not so. We, the human beings, operate on a particular philosophical basis, the basis of thinking, whether implied or explicit. Our technologies are fine, what needs change is the human that applies and develops technologies. And the change starts in the mind, with the philosophy that we apply to our understanding of the world.

House key versus user authentication

key_goldI got an interesting question regarding the technologies we use for authentication that I will discuss here. The gist of the question is that we try to go all out on the technologies we use for the authentication, even trying unsuitable technologies like biometrics, while, on the other hand, we still use fairly simple keys to open our house doors. Why is that? Why is the house secured with a simple key that could be photographed and copied and it seems sufficient nevertheless? Why then, for example, the biometrics is not enough as an authentication mechanism by comparison?

Ok, so let’s first look at the house key. The key is not really an identification or authentication device. It is an authorization device. The key says “I have the right to enter” without providing any identity whatsoever. So the whole principle is different here: whoever has the key has the authorization to enter. That’s why we protect the key and try not to give it to anyone – obtaining the key or obtaining a copy of the key is equivalent to obtaining an authorization to perform an action, like using the house.

Now, even if you do have a key, but you obtained it without the permission, that does not make you the owner of the place. You are still an intruder, so if someone happens to be around, they will identify you as an intruder and call the police who will be able to verify (authenticate) you as an intruder with an improperly obtained authorization (key). So we have deterrents in place that will provide additional layers of protection and we do not really need to go crazy on the keys themselves.

Should we have an authentication system compromised, however, the intruder would not be identified as such. On the contrary, he will be identified and authenticated as a proper legitimate user of the system with all the authorizations attached. That is definitely a problem – there is no further layer of protection in this case.

In the case of the house, passing an authentication would be equivalent to producing a passport and letting police verify you as the owner of the house, then breaking down the door for you because you lost your key. Well, actually, issuing you with a copy of the key, but you get the point. The false authentication runs deeper in the sense of the problems and damage it can cause than the authorization. With wrong authorization you can sometimes get false authentication credentials but not always. With improper authentication you always get improper authorization.