Paranoid Penguin - Mental Laziness and Bad Dogma to Avoid
On a related note, consider the digital certificate, which consists of a couple key pairs (one for signing/verifying, another for encrypting/decrypting), identity information (such as your name and organization) and various Certificate Authority signatures. Conventional wisdom says that every digital certificate must have an expiration date, the shorter the better, in case the certificate's owner unexpectedly leaves your organization or the private key is somehow compromised. The consequences of either event could include bogus signatures, illicit logins or worse.
This worst-case scenario assumes two things. First, if the certificate's owner leaves your organization, it may take a while for the certificate to be revoked (and for news of that revocation to propagate to the systems that use certificates). Second, it assumes that the certificate's passphrase can be guessed or brute-force cracked easily.
But, both of these are solvable problems. If you're deploying a Public Key Infrastructure in the first place, you need to configure all systems that use certificates either to download automatically and use Certificate Revocation Lists (CRLs) from your Certificate Authority, or better still, configure them to use the Online Certificate Status Protocol (OCSP). Many events can lead to a certificate's need to be revoked besides reaching some arbitrary expiration date, and managing your certificates diligently and using CRLs or OCSP are the only reliable means of reacting to those events.
Regarding certificate passphrases, setting passphrase complexity requirements is generally no harder for digital certificates than for system passwords. The situation in which it can be most challenging to protect certificate passphrases is when machines use certificates (for example, Web server SSL/TLS certificates), which usually requires either a passphrase-less certificate or a certificate whose passphrase is stored in clear text in some file to which the certificate-using process has read-access privileges.
The bad news is, in that scenario, renewing the server's certificate every year doesn't solve this problem. If it's possible for people to copy a server's certificate once, it's probably possible for people to do so every year, every six months or as often as they need or like. The solution to this problem, rather, is to protect the certificate at the filesystem/OS level, especially its passphrase file, if applicable.
Does that mean certificates shouldn't have expiration dates? Of course not! I'm simply saying that, as with password aging, if this is your only protection against user attrition or certificate compromise, you're in big trouble anyhow, so why not employ a variety of protections that allow you to relax a little on expiration dates, as you ought to be doing those other things anyhow?
For as long as I've worked on information security in large corporations, I've been told that e-mail encryption is only for geeks, and that business users lack the technical skills necessary to cope with it. I've always found this sort of amusing, given that it's usually us geeks who accuse business people of having too-short attention spans.
But, is using PGP or S/MIME really that much more complicated than using, say, LinkedIn? I know which I would rather spend time on! (I am, however, an admitted geek.)
How much of the inconvenience in e-mail encryption really falls on end users? Nowadays, I would argue, very little, especially if your organization can support a PGP key server or can incorporate S/MIME certificates into an MS-Exchange Global Address List.
In practice, key management tends to be the biggest headache with e-mail encryption—specifically, getting a valid/current digital certificate or PGP key for each person with which you need to communicate. But, this need not be a big deal if you set things up carefully enough on the back end and give your end users local settings that allow their mail client software to search for, download and update their local copies of other people's keys transparently.
One can go too far, of course, in coddling end users. I've seen organizations issue keys without passphrases, which makes those keys trivially easy to copy and abuse. I've seen other organizations issue passphrase-protected keys, but then send people their new key's initial passphrase via unencrypted e-mail! Obviously, doing things like that can defeat the whole purpose of e-mail encryption.
My point, really, is that modern e-mail encryption tools, which typically support GUI plugins for popular e-mail readers, such as MS Outlook and Squirrelmail, are exponentially simpler to use than the command-line-driven tools of old. Given a modicum of written documentation—a two-page instruction sheet is frequently enough—or even a brief computer-based-training module, nontechnical users can be expected to use e-mail encryption.
This is too valuable a security tool for so much of the world to have given up on!
There, I'm starting to feel better already! But, I'm not done yet. On to some mental laziness that never fails to annoy and frustrate.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Reply to comment | Linux Journal
2 hours 29 min ago
- Yeah, user namespaces are
3 hours 46 min ago
- Cari Uang
7 hours 17 min ago
- user namespaces
10 hours 10 min ago
10 hours 36 min ago
- One advantage with VMs
13 hours 5 min ago
- about info
13 hours 38 min ago
13 hours 39 min ago
13 hours 40 min ago
13 hours 42 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?