An old and well worn addage is “Do as I say, not as I do”, generally in a fit of hypocracy when the listener is asked to ignore the example being set by the speaker. The fallacy of that statement was addressed by the series of “I learned it by watching you” advertisements trying to drive home the point to parents that children are more likely to learn from example than from what the parent says.

In the Applications Security space we are big fans of telling developers what they should and shouldn’t be doing in order to produce secure applications, which is all well in good so long as we are not violating those very same instructions within our own properties. If developers are visiting their enterprise’s security portal and see examples in practice contradicting the secure coding and design standards on display on the very same portal, it completely undermines those standards.

Having raised this more than once and been given a liteny of excuses of why it is acceptable (there isn’t anything of value on this website, we wanted to get the content up now and we can always go back and fix the problems, it is only for internal employees anyway, etc), the same excuses that developers of any other project will put forth for why they don’t need to build security in for this release, I really wonder about the effectiveness of the message the application security community is trying to convey. If we can’t even get our own organizations to embrace our suggestions, obstensibly folks that “already have the religion”, what is our hope of getting converts to that message elsewhere.

So for various security organizations, the risk profile of your application is not an acceptable excuse to ignore your own security recommendations; if you are not going to abide by your own mandates do not bother asking others to do so. “Do as I say, not as I do” is a very ineffective strategy. Developers WILL notice your lapses and no amount of trying to create a justification of such a lapse based on the risk profile of the application in question will buy you any crediblity to restore that which was just lost. The risk is not to the confidentiality or integrity of the application, but rather to the integrity of the message the security organization hopes to convey. Even if the underlying message is completely valid, a kid being told by a parent presently working through another pack of cigarettes for the day isn’t going to buy that they themselves shouldn’t smoke.

And a special message to OWASP, the same applies to you, and your various caveats throughout your website do not make it ok to ignore your own advice. Saying

“You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your subscription. Do not use a valuable password as it will occasionally be emailed back to you in cleartext. “

when subscribing to a mailing list is not OK. It doesn’t matter that there is little security risk even if someone does compromise the password – the entire point of this post was to establish that security risk is not the only consideration. You undermine your message when you choose the easy route – why should I hash my passwords when it is obvious OWASP, whose job is communicating security, doesn’t think it is important that they do.  Similarly, I think it would be great if you set “AUTOCOMPLETE=off” on your login form, like you suggest in your various coding recommendations, and similarly switch to a generic message if either the username or password is wrong, rather than telling me that specifically the username or password is wrong. Incidentally, MediaWiki would be all the better if you had those changes adopted into their mainline branch, which is the least you can do having leveraged the project.

~ Joshbw