Programmers Who Don't Understand Security Are Poor at Security
A university study confirmed the obvious: if you pay a random bunch of freelance programmers a small amount of money to write security software, they’re not going to do a very good job at it.
In an experiment that involved 43 programmers hired via the Freelancer.com platform, University of Bonn academics have discovered that developers tend to take the easy way out and write code that stores user passwords in an unsafe manner.
For their study, the German academics asked a group of 260 Java programmers to write a user registration system for a fake social network.
Of the 260 developers, only 43 took up the job, which involved using technologies such as Java, JSF, Hibernate, and PostgreSQL to create the user registration component.
Of the 43, academics paid half of the group with €100, and the other half with €200, to determine if higher pay made a difference in the implementation of password security features.
Further, they divided the developer group a second time, prompting half of the developers to store passwords in a secure manner, and leaving the other half to store passwords in their preferred method—hence forming four quarters of developers paid €100 and prompted to use a secure password storage method (P100), developers paid €200 and prompted to use a secure password storage method (P200), devs paid €100 but not prompted for password security (N100), and those paid €200 but not prompted for password security (N200).
I don’t know why anyone would expect this group of people to implement a good secure password system. Look at how they were hired. Look at the scope of the project. Look at what they were paid. I’m sure they grabbed the first thing they found on GitHub that did the job.
I’m not very impressed with the study or its conclusions.
Subscribe to comments on this entry
Tatütata • March 27, 2019 7:22 AM
Isn’t this rather a demonstration of management failure? I.e., the specification is incomplete or non-existant, but the “Auftraggeber” implicitly expected the underling to make up for this.
Hex encoding is still not the worst possible option.
At a place I worked at, a critical application logged all mainframe interactions in a file visible to all users on the workstation. This included user credentials (why???), which were synchronised with the general Microsoft authentication system. Whoever wrote this garbage knew it wasn’t quite a good idea, as the password was “encrypted”: Caesar cipher with an offset of one, which isn’t quite nearly as secure as ROT13.
Management was full of themselves with so-called PRINCE2 methodology, and shelves of binders full of charts and procedures, but in the end, the code grinder in Bucarest or Mumbai was on his own, and the finished product the real specification. I didn’t have access to the source code, and reading decompiled Java byte code only made me dumber. I did have a copy of the holy grail, a sheet of paper photocopied by generations of monks from a medieval manuscript describing the fundamental business logic and transaction validation rules.
I don’t think that paying a big management consultancy a 5 or 6 digit amount would have produced a much better result that the 100€ or 200€ charity raffle.
I’m interested in a new title from MIT Press, Adam Barr: The Problem with Software — Why Smart Engineers Write Bad Code, but from the blurb and the few available excerpts I’m afraid I might be disappointed.