How can we stop the spreading insecure coding examples attraining classes, etc.?

[tholleb at teknowledge.com (Tim Hollebeek)]

Really, the root of the problem is the fact that the simple version
is short and easy to understand, and the secure version is five
times longer and completely unreadable.  While there always is some
additional complexity inherent in a secure version, it is nowhere
near as bad as current toolkits make it seem.

Demo code generally demonstrates some fairly powerful capability;
the reason it is often short and sweet is because lots of effort
has gone into making it possible to do useful things with minimal
effort.  Unfortunately, it is often the case that much less effort
has gone into making it possible to do the same thing securely, so
that code is quite a bit longer.  You're right, if there was more
of a pushback against broken demo code, maybe more effort would go
into making it easy to do things securely, instead of insecurely.

I think part of the problem is that people have fallen into the
trap of thinking that security is supposed to be hard and that
checking all your errors is supposed to bloat your code by a factor
of five, instead of wondering why library functions are designed
in such a way that omitting complex logic around them fails in an
insecure way.  Secure code can be short and sweet, too, just not
with most of the languages and tools that are currently popular.

This is an old, old problem.  strcpy is insecure, and any code
involving strncpy or a length check will be longer and/or more
complex.  But this is really just an artifact of the fact that
buffers don't know their own length, making an additional check 
necessary.  There is no reason why the secure version couldn't 
have been just as short and sweet, it just wasn't done.

Tim Hollebeek
Research Scientist
Teknowledge, Corp.