

Let's secure security defaults together - jessepollak
http://jessepollak.me/2012/11/13/lets-secure-secruity-defaults-together/

======
slavak
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 _always_ 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.

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.

~~~
InclinedPlane
This is one of those things that just shows how immature the software industry
still is.

Often times when people talk about software they talk about feature lists. And
they talk about things like design, security, performance, robustness as
secondary aspects and often times as things that can be bolted on later. But
the reality is that this is exactly backwards. Security, elegance,
performance, etc. are fundamental to the operation of a tool, including
software. The difference between a tool that does those things well and one
that doesn't is not some tiny detail, it's the difference between a tool that
is so good it takes over a billion dollar market and one that is relegated to
failure.

Look at, say, cars for example. Some cars differ on features but the biggest
difference is in the overall design, fit-and-finish, and attention to detail.

------
kijin
Wait a second.

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.

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.

If we're going to talk about securing our defaults, I think it's very
important that we make the defaults _actually_ secure _all the way_ , rather
than just making them slightly less insecure than they currently are.

Keep all session data on the server side. Now you've got secure defaults.

Or make sure that your secret key is actually, you know, secret.

