Life of a one-man IT department – Mike McBride
After my experiences today I’m reconsidering the way I look at password policies. I had to go around and install the new drivers for that Canon copier/printer today on about 15 machines. The install involved installing the Canon LPR port, installing the print driver, restarting, and then entering the Department ID information for the print job accounting functions. So I would sit down at a PC, run the installers, and ask the user to enter their password when the PC restarted. Most of them would just tell me what the password was instead of getting up from where they had settled to type it. A couple of these folks had to get up and type it in because they couldn’t remember it. Typing it in had become such a routine that they couldn’t tell you what it was, but they could type it. That told me two things:
1) I’m obviously not making them expire often enough. (I already knew that, but since there are no direct internet-facing PC’s, everything sits behind another company’s whole network infrastructure, and it’s a small enough environment that I can keep a pretty close eye on things, I have been more lax than I would be in any other situation. I don’t make them change it as often as most of you probably do with your users.)
2. You could never use social engineering to get these people’s passwords. They can’t tell you what they are! Maybe there’s something to be said for letting people type in the same password for long periods of time, making it such a routine that they can’t give it to anyone else. 🙂
Interesting take on things. I think definitely a lot can be said for non– , or long-expiring passwords.. but this would only work effectively from a social-engineering standpoint, if the passwords used where quite strong, causing users to be able to memory-type them.. but not be able to verbalise them easily. Of course the way a particular person remembers a password will differ from person to person.. so no guarantees. The upside is that people are less likely to write passwords down, as they do more often with high-rotation password expiration policy.
I think its a good approach in certain circumstances, depending heavily though, on risks associated with exposure of your system to the outside, as he already mentioned. The entire reason for password expiration is to help minimise the risk of a password being cracked, or when cracked, being abused for very long.
I have to wonder however, how difficult it would be to push strong-password policy though the organisation, as the initial time to learn the passwords are going to be (to) frustrating to users, and often also to the very managers/directors that control your policy/budget, possibly leading to the abandonment of the policy.. as I have seen happen quite often.
In the end, its all about educating users and management about the importance of passwords.. why they exist, why your policy is the way it is. Try to have an open discussion about it with the organisation as a whole, not just within the IT department. And this extends to all policy really.. people are better at following policy if they themselves understand the reasons behind policy and security.
If, despite your best efforts, you cannot get a proper password policy enforced or adhered to by the user base, try an external security audit as a way of making the risks transparent. Managers and directors on the whole pay a lot more attention to external parties advice when it comes to this kind of thing, and an audit can in fact be a good tool to build trust with partners and customers, if you advertise that you have been though such a process (and have made changes based on the outcome and advice). This is especially true for public-traded companies.
But the keyword here remains education. I identify a lack of understanding of the (root) problem (and its possible consequences) as the biggest reason companies don’t manage to get good security policy though.