Recently, I had to fill out some security-related forms with the Canadian government. To do so, I had to log on to a government Web site and create an account using a preassigned, unmemorizable user ID.
While I was doing that, I had to set up a password. It seems that the designers of the government Web site are familiar with XKCD, because their password policy (which also includes frequent password expiration and rules to prevent the reuse of old passwords) seemed like an exact copy of the policy ridiculed here:
Once I managed to get past this hurdle, I had to complete some forms that were downloadable as PDFs. Except that the forms (blank forms!) were in the form of encrypted PDFs, which made it impossible for me to load them with my old copy of Acrobat 6.0 for editing. The encryption was trivial to break (print to PostScript, remove encryption block using an editor, convert back to PDF) but it was there just as an annoyance.
If they invited me to audit their security policy (of course they wouldn’t), I’d ask them the following questions:
- What is the rationale of your password expiration/password strength policy, ignoring best advice from actual security experts who know the meaning of terms like “entropy”? What are the data supporting Draconian rules that, effectively, force infrequent users to change their passwords every time they log on to your system?
- What is the rationale behind your policy to encrypt PDF files unnecessarily? Exactly what threat is this supposed to address, and what is the anticipated outcome of employing this security measure?
- Now that you have successfully alienated your users, what are your plans for detection, analysis, mitigation and recovery in case a real attack occurs? Would you even know when it happens?
I suspect that the real answer to the last question is a no. Security theater is not about protecting systems or preventing attacks; it’s about protecting incompetent hind parts from criticism.