Are Strong Passwords All That Strong?
pondering-on-passwords asks: "I work at a company that is planning to implement strong passwords to increase network security. Personally, I think that this may be counter productive since the passwords will tend to be more cryptic than most people are used to and I believe that they will write them down and leave them very close to their computers. I think this will be a greater risk for our traveling people using laptops. A strict security policy that is enforced may help some, but I still believe that people will end up making their passwords more accessible in the end. I am trying to find some information for or against implementing strong passwords, statistics on security breaches, etc. to back up my beliefs. Of particular interest would be material specifically on strong passwords, types of security breaches (i.e. social engineering, exploiting system vulnerabilities, password cracking, password theft, etc.), and possible alternative security methods (i.e. hardware tokens)."
Maybe you just skipped it, but it sounds like the policy is missing an important issue.
What is the exposure to risk?
System-level root passwords need to be *hard*, if you use them at all. I generally create them with a recursive MD5 hash (with random salt mixed in) until I have a password with two uppercase, two lowercase, 2 punctuation, one digit, and one wildcard character. NOBODY will remember it, but nobody has to - these passwords are written onto a 3x5 card, sealed in an envelope, and locked up in a desk agaist truly dire circumstances.
Anyone with root access via sudo should be able to choose their own password intelligently. If their password is compromised, it's a mandatory written reprimand. This tends to make them careful about ensuring that they NEVER use unencrypted channels - no telnet, no ftp. This might seem harsh, but if a sysadmin is sloppy about choosing their password or tools then they're probably sloppy elsewhere, and repeated violations are grounds for serious concern.
As for everyone else - if an attacker can do much damage with these accounts then the finger still points at the sysadmins. The problem, in this case, isn't the bad password, it's the bad file permissions, unapplied security patches, etc.
For other reasons these users should still have reasonable passwords, but until you have shut off every single service that uses unencrypted or trivially encrypted traffic (telnet, ftp, pop3/imap, etc.) then you're just pissing in the wind if you're counting on them to protect your system. Check the password against cracklib to get users in the habit of choosing good passwords (e.g., no "bob2" passwords), but otherwise put your attention someplace where it will do some good.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
The counter arguement (which prevails at most companies) is that frequent password changes increase security. I've never seen any imperical data to support this claim. The logic is that if someone gains access via a stolen/guessed password, then forcing users to change passwords will close the intruder's door. Yeah, after 90 days! Meanwhile, they've had full access and could have created countless new accounts for themselves.
I've never seen a situation where this policy was coupled with required strong passwords, for the simple reason that (as you said) people who must frequently change strong passwords tend to forget them or, worse, write them down. That doesn't mean some places don't do this, just that I haven't seen it. I'd hate to work at a place like that.
Passwords alone are not enough. Sure, strong passwords are better than letting Bob's father pick "Bobby" or "R0b3r7" as a password, but how secure is a system where an intruder can roam undetected until their stolen password is changed? If you argue that frequent password changes are necessary, then you're admiting that you can't detect an intruder.
If you're paranoid about security and willing to consider other options, you should look into a physical system, such as the iButton. There are others, but this is a link I can quickly find :-)
If all this should have a reason, we would be the last to know.