Let's secure security defaults together

There's some kind of cognitive dissonance in the crypto community, where on the one hand they hammer into people the concept that they should <i>always</i> use trusted libraries and not screw with any of the settings, but on the other hand- many of those trusted libraries have insecure defaults or non-obvious gotchas that require developers to dive into the documentation and, quite often, understand quite a bit about cryptography.<p>It looks like this is often the result of legacy code, need to maintain backwards compatibility, etc. etc.; but I think this is one area where those reasons are absolutely NOT justified excuses. When your entire world is based on security - make your product WORK and make it secure BY DEFAULT; nothing else matters.

Wait a second.<p>If you use pickle to serialize your cookies, and if your secret key is freely available on the interwebz, yes, you've got a problem.<p>If you use json, you've still got a problem, namely, that your secret key is still freely available on the interwebz. People might not be able to execute arbitrary code on your server, but they can still easily modify their cookies to log in as a different user, steal their personal info, etc. etc.<p>If we're going to talk about securing our defaults, I think it's very important that we make the defaults <i>actually</i> secure <i>all the way</i>, rather than just making them slightly less insecure than they currently are.<p>Keep all session data on the server side. Now you've got secure defaults.<p>Or make sure that your secret key is actually, you know, secret.