Social Deconstruction II

In a previous post, Social Deconstruction I reflected on a barrier that had been put up on a Thursday, and by Sunday, completely bypassed. I had recent cause to revisit that area again recently and

Barrier bypassed

Barrier bypassed

as you can see, an actual, real gate has been put into the fence. The power of the crowd basically overruled the original intent of the landowner.

Of course, this could have been done from day one.

This is true in the IT world. How often has the security department come and said, “we’re implementing this new security policy” with little input from actual users and are surprised when users get frustrated and try to bypass the new security feature.  I had this happen at a client of mine. In the case of the fence above, people bypassed the security the fence builders wanted (presumably to reduce liability), and by doing so, increased their chance of getting hurt (and ironically, presumably increasing liability).

One of the security features that I think annoys most of us are passwords, or more accurately arcane password requirements. For example, some systems require a certain amount of complexity, but don’t necessarily tell you what the rules for complexity actually are! Yes, I’ve had that happen. Turns out they required special characters, but, only a specific subset of special characters and the ones I tried weren’t on that subset.

Now a minimum password length, makes sense. A one character password can be cracked by anyone. But, what about short maximum password lengths? Yes, perhaps that was a good idea when memory and storage were scarce (ok even then, not a great idea) but not so much these days. Yet, I know at least one system where your password has to be between 8 and 14 characters.

Another annoyance is the “must change every N days” where often N is something like 90 (though I’ve seen even lower). What does this mean? Folks end up with passwords like: Secur3Passwrd$1, Secur3Passwrd$2, Secur3Passwrd$3, etc.

Truth is, many of the so called password rules, actually encourage us to create lousy password, and so we repeat stuff, or write it down or take other steps that make it easier for to use them, but also as a byproduct weaken passwords.

The National Institute of Standards and Technology recently released an updated set of guidelines: NIST 800-63B that discuss good password requirements (note I have NOT read the entire document, just large portions of it).  Spycloud has a decent review here: New NIST Guidelines Acknowledge We’re Only Human. I’m not going to recap the recap here, but I will add what I generally do:

  1. I use a password manager. You can read reviews for finding one that best meets your needs. Personally, I use one that does NOT have storage on the cloud. While in theory they’re encrypted and secure, I get paranoid. (Yes, I do recognize if someone compromises my desktop, they can get access to my local password manager. But on the other hand, if they get access to my desktop, they can probably just install a keyboard logger and I’m hosed anyway.)
  2. I use a different password, automatically created by the above password manager for nearly every site of system I log into.  This ends up meeting most (but not all) of the NIST suggestions (they’re certainly NOT easy to remember, but they don’t have dictionary words, can be as long as I need, most likely are NOT in a previous breech, etc.)

Note, I said most, not all. There’s a few places I used passwords I can remember. These are systems I interact with on a daily or near daily basis, such as my desktop, AND the password manager itself. There would be no point to have a password manager if I couldn’t log into it, or if the password were so simple anyone could guess it.

So, I make sure these passwords are easy to remember, but extremely hard to guess. (For example, they do NOT include the name of my first dog, my mother’s maiden name, etc.)

In conclusion, if you’re in charge of security, make it usable, or else people WILL try to bypass it, simply to get the job done. And, remember, you’re always in charge of your own security, so make it usable, but secure.

 

 

 

1 thought on “Social Deconstruction II

  1. Pingback: Challenge Accepted! | greenmountainsoftware

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s