One of My Pet Peeves

As an IT manager, one thing that’s always driven me nuts is the fact that the password policy generally regarded by folks in the industry as “best practices” is actually pretty far from it.

Via Instapundit, this article about Sarbanes-Oxley compliant password policies being pushed by auditors is a breath of fresh air.  My preferred policy would be infrequent password changes, combined with regular password cracking to root weak passwords out of the network.  You do have to impose some degree of complexity in the password, otherwise people will pick ridiculously stupid passwords.  But some IT people go to ridiculous lengths, and frequent password changes only compound the problem.  The writing down or saving of passwords on the network is a far greater risk than the risk that someone will crack or guess your passwords.  All this “security theater” about complexity and duration of passwords might make auditors feel good, but it does you no good if everyone is tacking their passwords under their keyboards.  If I feel pretty good that a user has picked a good password he or she remembers, I don’t have a problem letting them keep it for a while.  If you’re an IT manager responsible for network security, you should be trying to crack your users passwords on a regular basis.

12 thoughts on “One of My Pet Peeves”

  1. Here’s a nice story to raise your hackles.

    I’ve always pushed for super complex yet easy to remember passwords. For example, many years ago my password was Idahg95JW, which for me meant “I drive a hunter green 95 Jeep Wrangler”.

    We ran password crackers against it and a month later it had figured out the ‘9’ but that was it.

    Then, SOX came along and required frequent password changes. While it’s a great way to make complex passwords, it’s difficult to type them up front. By the time I got proficient at typing it out, it was time to change it.

    It got so difficult to manage my passwords with all the changing that now I just use a plain word and some numbers. Hardly safe, but easier to get my work done.

    My passwords would stand up to years of cracking, no need to force me to change it. But, unintended consequences and all…

  2. The interesting thing is, SOx requires no such thing. This is what has been interpreted by lawyers and accountants who don’t know dog shit about network security.

  3. The military requires a password with two caps, two lowercase, two funny symbols, and two numbers. They also require a minimum password length of 10 characters. The password must be changed every six months.

    Here is an example.
    QWer12#$ty
    Being that the password there is easy to type, I have probably just let slip several thousand user’s passwords. Also consider that when password change time comes around, most people just increment the last digit so the password then becomes QWer12#$tz then QWer12#$ta.
    This is not password security. This is inconvenience and theater in the name of security.

    Someone, somewhere, believes that the greater the inconvenience, the greater the security. This guy is apparently in charge of the way security things are run. The military passwords and the TSA are prime examples of this.

    -Jdude

  4. Jdude nailed it – once people figure out they only have to change one character, they’ll keep the same password, with minor variations.

  5. I absolutely agree. I just got hit with password changes at work and on my hosting service. Mind you, one of the passwords I had to change was a site I just bought the week before. So I had the password an entire week before I had to change it.

    Meanwhile, I could not re-institute my password because it had been used prior. *argh*

    I much prefer a tiered password system (ie: I’ll use one password for things like online registrations, another for more personal stuff, and another tier for financial). But some of my worst passwords are because of forced changes. When you have several hundred sites, tools, etc that require passwords both in personal and work life. You are forced to either implement a system, use a common easy to remember “simpler” password, or to store them externally.

    I am like you, I believe the third option is far worse than either of the first two. I am also firm in my belief that passwords are less likely to be the breech than some code/software security flaw that will by pass your password controls entirely.

    Things that would ensure more security with regards to passwords. Would be a uniform standard. I’d like to see a uniform standard proposed, say ISO 23048 Password methodology.

    Now it could have a lot of leeway, but it would mandate a minimum size (ie: 8 chars) and a minimum “maximum size” (ie: maximum size must be at least 16 chars, but could be much more). As well as a list of allowed characters (ie: Alpha Upper/Lower, Numerics, recognized symbol lists).

    Doing this would facilitate much more complex passwords on my part. Because I could easily create a complex password to use for any of my Gmail, Yahoo, etc email accounts. And I could even create a heirarchal system. That would make it unique to each site or tool. However, I’ve tried implementing this and it becomes chaos. The password is too short on one site, too long on another, this site requires a number, and this one a capital, and this one needs a symbol, but this one can’t accept symbols.

    The end result is I move to a simpler less safe password. I’d love to see a push for a standard (ie: 8 char min, minMax 16 chars, no requirement for capital or lowercase but both available, and a list of common symbols, but the list would be defined and you could check it against the standard. Sites could allow for added symbols. But this set would ALWAYS work if the password met the standard.

  6. If it were up to me, I’d have a cracking application running 24×7. As soon as it figures out your password, it forces you to change it.

    My methodology is not only effective, but it seems to be something people take to. Since I’ve pushed it at work, every time I get moved to a new application I see complex passwords in use (the fact that EVERYONE has the password is stupid, but at least it’s a start).

    Oh, and yes that is not a “SOX Requirement” unless you ask the people responsible for SOX. They will let you know that EVERYTHING from passwords, to Web Service Naming Conventions, to the quality of toilet paper in the bathrooms is covered under the rules.

  7. Thanks for the link!

    Robb, the thing is, it really *isn’t* a SOX requirement. It’s a requirements made by someone interpreting some article on SOX, drawing from commentary on COBIT. Each step includes making things a bit more onerous, because no one wants to risk being too easy and getting in trouble. CEOs and CFOs particularly hate being sent to prison.

  8. Charlie, that’s what I said. It’s not really a requirement, but the SOX people (those given charge of implementing SOX) think it’s their job to tell me when to use nullable value types or not.

  9. Like some here, I have a tiered system – low, medium, and high risk – and my password is based on the tier. I only have to remember 3 passwords. If my password doesn’t meet requirements (or requires frequent changing) I usually end up with a variation of that level’s password that does. Then it gets stored externally, so I don’t forget it (especially if it’s one I don’t need often).

    The thing I do to keep that list safe is simple. The list is a simple text file – which I encrypt using PGP with my high level password, and then store on removable media.

    For someone to compromise that they would need:
    – my high level password (and if they’ve got that, I’m in big trouble anyway)
    – my private key (again, if they’ve got that, I’m in big trouble anyway)
    – physical access to the media with the encrypted file.

    If someone can manage all that, I’m pretty confident there’s nothing else I’m capable of that would stop them, so I’m pretty much screwed no matter what I do.

  10. six months – must be nice. In my department it’s every 60 days and the damn machine remembers the last 20 that you used.

  11. Glad to see someone agrees with me that super-short password change durations are dumb. It’s a straight cause-and-effect. If you make users change their password every 30 days (or you have a saner period like 90-120 days, but they can’t use the last _14_ passwords) then 70%+ will write their password on a post-it and stick it to their monitor. And then where are you?

    My opinion is that resources are better invested in training all users on best practices for coming up with passwords. For example (and in no way do I claim this is the best or only way) I have a small set of common passwords, each based on a pnemonic phrase that’s easy for me to remember, and with a few characters that are easy to change without affecting said ability to memorize.

    All that said, I can’t blame managers for relying on “best practices”. It’s not really reasonable for most organizations to do in-house R&D on functions not part of the core business – yet some of those non-core functions are still critical and need to be done “by the book”.

Comments are closed.