The Sorry State of Secure Software Development?
We Can’t Even Get The Basis Right? Functionality first, security second.
We build bridges that meet general safety standards … We build cars which have safety embedded into every part of the design and manufacturing process … We define standards which keep our food safe from disease … But do we do the same for the creation of our software world?
Few other industries would get away from such poor regard for the safety of the citizen. Imagine if you asked a bridge designer, “Why didn’t you put bolts in the girders?”, “Well, you didn’t ask me too!”, “But, the bridge fell down!”, “Well, you should have told me that not falling down was a requirement!”.
As an industry, computer security doesn’t quite use evidence-based approaches as much as others. Often it is a “Dev Ops just don’t work well with Sys Ops”, and with little the way of real evidence to define that this is the case. But new research — from the University of Bonn — actually delves the knowledge of security within the development process [here]:
The research involved asking 260 Java developers from Freelance.com to write code which will safely store passwords. In the end, 43 of them took up the work. The given task was to setup a user registration system for a fake social media site. Of the resultant split, 39 were male, and one female, and the others did not define their gender. 37 had university degrees and had an average experience of 6.4 years of Java coding:
In order to assess whether being paid more for the task resulted in improved security, around half of the group were paid €100 and the rest received €200. Then they split each of these groups into whether they were prompted to use a given methods or not:
- Use defined password storage method (P100) and paid €100.
- Use defined password storage method (P200) and paid €200.
- Not defined the password storage method (N200) and paid €200.
- Not defined the password storage method (P200) and paid €200.
Generally it took developers around three days to submit their work, and 18 of them had to resubmit their code as the had used plaintext passwords. The reason that 15 of them gave was that there was no requirement given in the specification for secure password storage, and the other three just resubmitted with the same plaintext password.
In the end the results were poor from a security point-of-view, with many developers using encoding formats (Base64), weak hashes (MD5 and SHA-1) and weak encryption of passwords (AES and 3DES):
The worrying thing is that nearly one-in-five selected a method which is not even a hashing method: Base64. The security in Base64 is zero, as it is an encoding method. There was often confusion between the hashing of a password and in encoding them in a scrambled form. Of those who used Base64, the comments included:
encrypted it so the clear password is not visible
It is very tough to decrypt
Overall the researchers found that the developers often didn’t know the difference between hashing and encryption. When it came to salting the password, only 15 out of 43 selected salting, and that 17 out of the 43 had just copied the code from other sites. The researchers, too, found that paying the developers more didn’t lead to better code and that they often had to be told which methods were actually to be implemented. The study also highlighted that the knowledge of encryption and hashing were generally poor, with many unable to differentiate the two of them.
And what is their advice?
The previous work from the research team focused on students, and also highlighted a general lack of integration and knowledge of security into the development process [here]:
Their advice was clear:
- Security knowledge does not guarantee secure software. You can’t just teach someone a few lessons on the importance of security, and that they will then take a lead and actually implement things into practice.
- More usable APIs are not enough. With this, there is one thing in using an API, and another of actually knowing the core theory behind it.
- Explicitly requesting security is necessary. Most studies show, that if security is not implicitly defined in the work, it will often be avoided.
- Functionality first, security second. This tends to be the case for developers. Get it the code to work is highly important, but making it secure should also be a key objective, and at every part of the development process.
- Continuous learning. There is a strong need for continuous learning of the key principles of security, and to share and encourage good practice.
- Conflicting advice. If you search forums, there’s lots of people offering advice, and a good deal of this advice can be conflicting. If possible, teams should develop their own expertise, and share knowledge.
The work backs-up many other studies, and which have identified that the knowledge of cybersecurity within the developer community is generally weak, and that developers will often build something that is functional and forget about security. For some reason, cryptography and cybersecurity methods are just not taught on many software development courses, and this is often leaving systems open to attack.
Let’s continue our dialogue:
“Why didn’t you put bolts in the girders?”,
“Well, you didn’t ask me too!”,
“But, the bridge fell down!”,
“Well, you should have told me that not falling down was a requirement!”.
“So now we will have to test all of the girders now, after it has been built?”,
“Yes. It is my job to build a bridge, and it is yours to make it safe”,
“So, I’ll have to know make it safe?”,
“But don’t you have a degree in bridge safety?”,
“No, I have a degree in drawing nice looking bridges. Is that a problem?”,
“Yes. The bridge needs to look nice, and be safe!”
And, so, the software development industry has generally side-footed issues around resilience — the blue screen of death is something that few industries would have allowed — and in security. Without standards and education, we will fail to build the foundations of a world that is fit for the 21st Century.
 Naiakshina, A., Danilova, A., Gerlitz, E., von Zezschwitz, E., & Smith, M. (2019). “ If you want, I can store the encrypted password.” A Password-Storage Field Study with Freelance Developers. [Link]