Skip to Content
Author's profile photo Frank Koehntopp

Creativity is bad.


This is going to be a rant partly, because it’s just one of these days, and I’m hoping this post will serve as a cure. Maybe it helps others in the process, that’s fine, too.


OK, now that the title got your attention, what is this about? I recently reviewed a number of security related architecture documents, most of them triggered by findings in our internal quality processes. What puzzled me most was the creativity that was put into those, mostly by people whose main job isn’t security.

While I can understand the desire to get a solution fast security is one of those topics where creativity is a really REALLY bad idea. For many different reasons.

When you look at the kind of implementations that are vulnerable to attacks you’ll realize quickly that attackers have an endless amount of creativity available, too. Watch this video to get some ideas:

From the developer perspective this means there is a high probability that any time you’re inventing a new solution for a security problem you might create another exploitable piece of code.

This is especially true for ANYTHING that envolves encryption and/or cryptography based authentication. Everything in that area has been solved, peer reviewed and tested many many times, yet rarely a month goes by with another highly creative and incredibly vulnerable new approach. This is an area that’s easy to do badly for the best of us, spare me the experience with the rest of us 😉

How can you avoid that? Easy. For this special case, stop being creative and rely on what others have already solved.There is a wide variety of secure coding guidance out there, OWASP is an excellent starting point:

If you haven’t yet, moving to a formal SDLC (Security Development Life Cycle) is also a good idea. I liked this recent presentation by @securityninja a lot:

Also, please make sure that whatever you do is based on a threat model. That doesn’t necessarily mean the full formal approach, but it helps if you write down what the threat is that your code is supposed to mitigate. It also helps testing if it actually does what it’s supposed to do.

I’m pretty sure that wherever you work, somebody else has already done something similar. Try to identify the security champions in your organisation, and get in contact with them. Better yet, create a community of security experts where you can discuss and share your solutions. If you’re on your own, the SCN Security Forum is also a good place to discuss. ANYTHING is better than inventing stuff that has already been properly implemented somewhere else.

Another reason why creativity in security is bad is that your code might actually live a long time, and may even need to be maintained. If you implemented a novel approach to a common problem, that makes maintenance harder. Even worse, even if you got it right the first time, another developer doing maintenance might introduce a vulnerability because he didn’t fully understand your approach.

The last reason, adding a business perspective: any new piece of security infrastructure that doesn’t quite work like the other ones introduces complexity. It adds complexity for administrators that might need to come up with new processes to maintain the solution, and it adds complexity for users that barely understand how to use the other solutions in a secure manner.

Please, try to think of that when you are about to implement a novel way of user registration or password reset processes.

So there, I’m done. Anyone with the same problem? Other Suggestions? Feel free to share your best stories in the comments 😉

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Steve Rumsby
      Steve Rumsby

      For most people, security feels a lot like this:

      [embed width="425" height="350"][/embed]

      If you know the reference (watch some of the related videos listed on the right of the youtube page), you'll know how badly things always turn out, and security is much, much, MUCH harder than anything they've ever attempted 🙂

      Friends don't let friends use proprietary or bespoke security software...


      Author's profile photo Susan Keohan
      Susan Keohan

      I do know of a company that was wrestling with VPN security, and the solution was that if they thought someone had tried to crack your VPN, they would send you email.  Only one problem with that.  Guess how you get to your email...

      Author's profile photo Former Member
      Former Member

      It is great to have a job which involves playing under the disguise of working 😉

      The real work is fixing these creative application and infrastructure hacks against the "more stuff" requirements.

      I think security should be more involved in design of solutions.



      Author's profile photo Frank Koehntopp
      Frank Koehntopp
      Blog Post Author

      Julius, I'm actually talking about the design step... 😉

      Author's profile photo Former Member
      Former Member

      Yep, I meant "I also think"...  as in "me too"... 😳

      Author's profile photo Former Member
      Former Member

      Intresting read, creativity can turn bad at times 😈

      Author's profile photo Otto Gold
      Otto Gold

      "Another reason why creativity in security is bad is that your code might actually live a long time, and may even need to be maintained. If you implemented a novel approach to a common problem, that makes maintenance harder."

      🙂 🙂 🙂

      What a nice way how to describe the situation. Very diplomatic 🙂

      cheers Otto

      Author's profile photo Former Member
      Former Member

      practical and useful 🙂