david wong

Hey! I'm David, cofounder of zkSecurity and the author of the Real-World Cryptography book. I was previously a crypto architect at O(1) Labs (working on the Mina cryptocurrency), before that I was the security lead for Diem (formerly Libra) at Novi (Facebook), and a security consultant for the Cryptography Services of NCC Group. This is my blog about cryptography and security and other related topics that I find interesting.

Developers Are Not Idiots posted January 2019

After spending many years working in information security, as a consultant, I've had the chance to audit a multitude of different systems invented and developed by many different people. While there is a lot to say about that, the focus of this article is about some of the toxicity I've noticed in the field.

If you're like me, you must have heard the security jokes about developers during conferences, read the github issues of independent researchers yelling at volunteering contributors, or maybe witnessed developer shaming in whitepapers you read. Although it is (I believe) a minority, it is a pretty vocal one that has given a bad rap to security in general. Don't believe me? Go and ask someone working at a company with an internal security team, or read what Linus has to say about it. Of course different people at different companies will have different kind of experiences, so don't take this post as a generalization.

It is true that developers often don't give a damn about security. But this is not a good reason to dismiss them. If you work in the field, it is important to ask yourself "why?" first. And if you're a good person, what should follow next is "how can I help?".

Why? It might not be totally clear to people who have done little to no (non-security focused) development, but the mindset of someone who is writing an application is to build something cool. Imagine that you're trying to ship some neat app, and you realize that you haven't written the login page yet. It now dawns on you that you will have to figure out some rate-limiting password attempt mechanism, how to store the passwords, a way for people to recover their passwords, perhaps even two-factor authentication... But you don't want to do all of that, do you? You just want to write the cool app. You want to ship... Now imagine that after a few days you get everything done, and now some guy that you barely know is yelling at you because there is an exploitable XSS in your application. You almost hear yourself saying out loud "an XX-what?" and here goes your week end, perhaps even your week you start thinking. You will have to figure out what is going on, respond to the person who brought the bug, attempt to fix it. All of that while trying to minimize the impact on your personal reputation. And that's if it's only a single bug.

I have experienced this story of myself. Years ago, I was trying my hands with a popular PHP web framework of the time, when one of the config file asked from me to manually modify it in order to bootstrap the application. Naturally, I obliged, until I reached a line reading

// you must fill this value with a 32-random-characters key
$config['encryption_key'] = "";

Being pretty naive at the time, I simply wrote a bunch of words until I managed to get to the required number of letters (32). It must have looked like something like this:

// you must fill this value with a 32-random-characters key
$config['encryption_key'] = "IdontKnowWhatImDoing0932849jfewo";

Was I wrong? Or was it the framework's fault for asking me to do this in the first place? You got the idea: perhaps we should stop blaming developers.

How can you help? Empathize. You will often realize that security people who have worked non-security development jobs at some point in their career will often understand the developers better AND will manage to get them to fix things. I know, finding bugs is cool, and we're here to hack and break things. But some of these things have people behind them, the codebase is sometimes their own labor of love, their baby. Take the time to teach them about was is wrong, if they don't understand they won't be able to fix the issues effectively. Use language to vehiculate your ideas, sure it is a critical finding but do you need to write that on a github issue to shame someone? Perhaps the word "important" is better? Put yourself in their shoes and help them understand that you're not just coming here to break things, but you're helping them to make their app a better one! How awesome is that?

Sure they need to fix things and take security seriously. But how you get to there is as important.

I also need to mention that building better APIs for developers is an active area of research. You can't educate everyone, but you can contribute: write good tutorials (copy/pastable examples first), good documentation, and safe-by-default frameworks.

Thank-you for reading this.

Your mission, should you choose to accept it, is to be an awesome security peep now :)

EDIT: Mason pointed me to this article which I think has some really good points as well:

Another element of a critique-focused report involves the discussion of positive findings of the assessment. As the saying goes, a spoonful of sugar makes the medicine go down.

And indeed, If I liked what I've seen during an audit, I always start a discussion by telling the developers how much I liked the code/protocol/documentation. They are always really happy to hear it and my followed-up critiques are heard way more seriously. Interestingly enough, I've always felt like this is how a good performance-review should go as well.

Well done! You've reached the end of my post. Now you can leave a comment or read something else.



> Was I wrong? Or was it the framework's fault for asking me to do this in the first place? You got the idea: perhaps we should stop blaming developers.

Aren't you just saying that you think we should be blaming 'other' developers with this statement. It isn't your fault for as a developer, but it is the platform developers fault?


woop, well you found a nice contradiction here :)

I guess this part of the article was tangential to the story anyway


About encryption key, Django has a project generator that generates and hardcodes a random one for you. Flask, micro-framework in Python, which emphasizes you can copy-paste 10 lines to get a working site, has a 'replace-me-please' which developers may leave. Maybe it should refuse to run till it gets a random-enough string? Is there a way to determine if a string is strong enough for a key or a copy paste like hellohellohellohellohello?


I agree that blaming and screaming is not a good idea. But, maybe, we should consider "security training" as a basic requirement for a professional developer. Sometimes security-related bugs are obscure and complex; very often, particularly in closed source, enterprisey codebases, there's a complete lack of understanding of coding security behaviours. And THAT is a problem.

You wouldn't like a pair of beautiful and shiny new shoes if they broke down after ten steps. You wouldn't buy a new watch that gets late whenever put in the sun. Essential security and correctness should be basic quality concerns.


I don't think developers are idiots but they can be overconfident or rushed for time which is what causes these issues.


I put my comment here: https://news.ycombinator.com/item?id=18939163


I'm a developer who has worked in security for several years (my job is to fix the issues that my hacker colleagues find, and coach developers on how not to make those mistakes in the first place). I can testify that, sadly, the two major causes of security mistakes are 1) time-constraints and pressure to deliver features, and 2) focus on building a functional application, i.e. all the cognitive effort is spent in trying to figure out how to achieve a certain functional goal, rather than how to do it securely. Often security is "yet another complication" on top of the day to day challenges of development, and if business doesn't consider it a priority then developers won't volounteer to make their own lives harder.


(addendum) So to recap: developers are not idiots, they just have profoundly different priorities.


Another thing security people must understand, even if they are all aware of it, is that, security is never perfect. There are new flaws discovered everyday. It's something that developers cannot handle properly, they have their own problems, their own everyday issues, and a good thing is, for them, to stay focus on what is their jobs. That's why they desperately need good practices about security issues, not morals.


True, it can be easy to miss security issues when on time constraints... though simply testing the code pre-release and thinking with a hacker mindset might be all it takes for the dev to find some of the vulnerabilities before the code is submitted or finalised.

leave a comment...