Security is not the most important thing to most people
I'm a security aware sysadmin and yet yesterday I casually admitted that I made less-secure choices because the really secure option was too annoying and potentially inconvenient. In fact this is not the only case where I make this tradeoff, picking a less secure but more convenient option.
This shouldn't really surprise people. In real life security is almost never the most important thing to people, even to security aware people. Even aware, knowledgeable people prioritize other things over security; we disable SELinux, we use fixed-keyed IPSec tunnels, we almost never try to verify new SSH host keys through out of band methods, and so on.
(This is somewhat distinct from how users don't care about security; this is people who care about security but only so far.)
One of the many reasons for this is that most people are not operating in a high-threat environment. We aren't being specifically targeted by attackers and if we take basic broad precautions we'll probably never experience a security breach. This biases almost everyone towards a tradeoff that I can describe as 'availability over security' and it also makes painful security precautions have a very low return on investment; we're being asked to invest potentially a lot of work and aggravation in exchange for what is in practice a very small gain.
(The worst case is when being 'truly secure', whatever that means, means not doing something that we want to do. When I couldn't get IKE rekeying working on my IPSec tunnel, the really secure thing would have been to say 'well, that means no IPSec tunnel at all'. Very few people are going to make that sort of tradeoff.)
(Yes, I know, I bang on this particular drum a lot. That's because I still think that a lot of people in computing have very mistaken attitudes on what security really means and how it can be achieved, attitudes that result in mistake after mistake.)
Why I do IPSec improperly and reduce my security
I've had an IPSec tunnel between my home machine and work for a fairly long time now. Now, I have a confession: during all of this time, the tunnel has had fixed keys.
If you don't know IPSec you may not understand what this means, so let me explain. To simplify a bit IPSec connections are protected by symmetric stream ciphers, which require keys for those ciphers; this is very similar to SSH, TLS, and any other network encryption protocol. But in those other protocols the stream cipher keys are normally arranged on the fly through the session setup protocol and often long-running sessions will be re-keyed periodically. Periodic re-keying (if done securely) both limits the amount of encrypted data an attacker can do brute force attacks on and limits the damage of a key compromise; it's thus generally considered a good idea.
My IPSec tunnel doesn't have any of this. The stream cipher keys it uses are hard-coded into my scripts and it uses the same stream cipher keys for however long until I go through the manual effort to change them. As you might guess, this is far from ideal from a security perspective, even though my keys are completely random.
(I have a program that dumps N bits of randomness from
and I use that to generate keys whenever I decide to rekey.)
In theory it's possible to do better than this, because IPSec has a whole set of systems called IKE to handle exactly the job of negotiating IPSec stream cipher session keys. The problem is that in practice all of this is fiendishly complex, generally badly documented, and doesn't always actually work (at least on Linux, other environments may have better experiences). Part of the problem is that IPSec IKE systems are generally designed and documented for complex configurations where you want things like X.509 certificates and so on; simple scenarios sometimes seem like an afterthought.
(IPSec itself falls into the usual crypto obsession of having too many options and thus quite a lot of ways of blowing your feet off, in addition to the fundamental complexity that you have to understand to use it at all.)
I actually once got an IKE setup 'working' between two systems in that it could set up the initial keys but then things blew up whenever it re-keyed the ongoing connection (I believe that existing TCP connections died, but it was a long time ago so I've forgotten the details). Of course trying to figure out where the bug might be was hopeless so I just gave up (and went to fixed keys, among other things).
(There is a general lesson for security here but you can probably already guess what it is and I think I've probably mentioned it before.)
(I was reminded of all of this pain by a recent package upgrade on my Linux machines that changed things from one IKE system to another. I saw that and briefly considered trying to set up a proper re-keying IKE configuration before I began laughing bitterly at the very idea of wading back into the IKE swamps.)