This is a great article on some of the pitfalls of the security mindset – the post is essentially based around the quote “The more secure you make something, the less secure it becomes”. A quick snippet:

I recently attended two conferences on Usability, Security, and Privacy. The first, SOUPS (Symposium on Usable Privacy and Security), was held on the Google campus in Mountain View, California, the second at the National Academies building in Washington, DC. Google is a semi-restricted campus. People can freely wander about the campus, but most buildings are locked and openable only with the proper badge. Security guards were visibly present: polite and helpful, but always watching. Our meetings were held in a public auditorium that did not require authorization for entrance. But the room was in a secure building, and the toilets were within the secure space. How did the world’s security experts handle the situation? With a brick. The side door of the auditorium that led to the secure part of the building and the toilets was propped open with a brick. So much for key access, badges, and security guards.

Recently I encountered a policy that obviously dealt with user circumvention of security controls. It was the typical draconian AD password policy – 8 characters, upper, lower, numeric, special character, no repeats of the previous 24 passwords, change every 45 days, yadayada. On the surface the policy makes sense – it is sufficiently long and complex enough to prevent brute force, and the requirement to change the password and not repeat it should prevent any termed employees from having unlimited access to shared accounts. There are a couple other measures in place – every client has software that extends the normal delay Windows inserts into a failed login attempt to an even more annoying time (seriously, first failed attempt – 30 second wait, and it just goes up from there) and the AD will delay authentication as well, so brute forcing is already a bit impractical. A termed employee who is of the mindset to abuse a shared account that they still have access to isn’t going to wait 45 days, they will abuse it in a week.

In general I am fine with the policy myself as I can generally remember an esoteric string of characters fairly easily, provided it is within a short period of time of first being exposed to it or I have used said string three or more times. I think I am probably an exception. Many people, when faced with a complex password are just going to write it down, making the system much less secure. Clever people who dislike the policy will change the password 25 times in a row so they can just go back to their old password, and so forth. Unfortunately for the latter category there were equally clever AD policy setters who decided that a password cannot be changed if it had already been changed once in the previous two days. Arguably what this has done was cause people who had committed ONE secure password to memory to now either use variations of the same password (which really achieves very little – someone who knew the password was Secret!01 is naturally going to try Secret!02) or to be one of those folks who just writes it down.

And then there is the little scenario that cause me to think up this whole post. I had access to a shared account. It was set up quite a while ago so that we could grant access to a server for folks in a different AD hive without creating seperate users for each (which is lazy and not great practice, but they only need access for a small window at which point the password can be changed). I immediately changed the password after the account was setup, since the default password sucked, for a number of reasons. Unfortunately the folks that were actually going to use the account weren’t ready for it for a decent period of time, and by the time they were ready I had forgotten the password, as I never used it after that initial change (first thought from me – “Crap, I should have written that password down”). I ask our friendly admins to change it, and they do – to “Password1″ (not sure how they got passed the requirement for special characters), email me said password, and ask me to change it. I immediately go try, but since the password was changed in passed two days, I can’t. Hurray draconian password policy, because of you now I have to wait until tomorrow to update the password. Granted a two day exposure window for a crappy password isn’t a huge deal, especially since outside of a test SQL server and a webserver it has no access, but it does demonstrate that in our effort to make something *more* secure, we can be counterproductive.

So when deciding what security controls to put in place I think it is a good idea to not just look at the surface. One question I have not heard asked at very many design meetings of security controls is “How will the control we are implementing end up working against its own intent?”. One way a control will be its own undoing is if it sets up security as the enemy of the users, because then the users will invalidate the control. “Make me change my password to something I can’t remember – well my good friend post-it will remember for me.” “Make me buzz in all my friends at the conference just so they can use the toilet, then I am going to prop the door open”

~ Joshbw