A long time ago, in an IT department far, far away, I managed a wide-area network comprised of about 120 users.

This was during the havoc-filled days of the budding Internet, where new worms and viruses cropped up almost daily with names like “LoveLetter” and “Red Button.” These malware packages, exceedingly virulent and easy to deploy, were almost all enabled in some way or another by poor user (and administrator) behavior.

Being somewhat fascinated by these types of attacks and responsible for guaranteeing my association’s security, I decided it was again time to audit the security of my users and our hardware.

Here comes that creepy network administrator …

During this period, Windows 2000 was “on its way,” with almost all of us bound to the Windows-world, making use of Windows NT 4.0 for servers and Windows 98 for desktops. NT was a solid server OS, performing admirably for years in the business world, but like all operating systems of the period, rife with vulnerabilities. Windows 98 suffered from similar weaknesses, and due to backwards-compatibility requirements, both operating systems defaulted to the “weakest” configuration possible. (By this time, it was possible to disable the weaker “LanMan” hashing solution via configuration settings.) These problems led to the development of tools such as L0phtCrack and Cain and Abel. With these tools in hand, any savvy administrator, or budding hacker-twit, could start cracking passwords.

So I did.

I cracked all of them.

Have you ever tried to tell a 60+ year old CEO that his password of “banana” was insecure? What about the scary accounting VP, who probably understands the math behind entropy calculations a lot better than you do, that they can’t use their password, (“money123”), literally everywhere?

Their responses tend to be somewhat … indignant. Especially when informed they needed to change them. Evidently, cracking their passwords and telling them that entropy matters was not something they expected from their IT administrator. (If you’re interested, I have a rant … err … white paper discussing password entropy available for free download here.)

What is your admin doing?!?!

Now, I was fortunate enough not to hear the phone call I’m sure my VP received from our CEO after I told him he couldn’t use “banana” as a password for our network. I’m also pretty sure this was not the first phone call they received related to my hacker tendencies.

But I was not asked to stop guaranteeing our association’s security, so my VP did their job. The biggest negative was that the particular CEO in question was never really comfortable with me again. I was OK with that as long as I was allowed to continue to secure our environments and buy toys to play with.

For most of my users, the impact was less … noisy. A lot of them sheepishly changed their passwords (and then promptly wrote it on a sticky note), and asked me to let them know if I cracked them again. A few users fought back, as I discovered in my next cycle, when my password cracking produced results such as “StillHaveAJob,” “HowsThisForSecure” and “JoshIsATool.” Seeing as how these passwords were now meeting my restrictions and were therefore stronger, I snickered and moved on.

After a few cycles, I remember having a discussion with my VP about restricting access to the network for my users who just didn’t seem to “get it.” Changing from one insecure password to another wasn’t going to cut it, and I had been preaching at them for months about the issue. How about I just cut them off when they’re proven insecure?

The answer was a solid, “No.”

They had to listen to me argue for at least an hour. Without getting the slightest bit annoyed, they politely informed me these were very non-technical staff, and I was going to have to find a way to make it work. In other words, still a “No.”

I remembered being pretty frustrated with this response, thinking we were making a decision based upon making our users’ lives easier without taking into account the overall security of our entire network.

What’s that network for again?

I was wrong, of course. (Even though I wouldn’t tell my VP that at the time.) How was our association supposed to survive without the revenue generated by salespeople? How were our policy people supposed to communicate with the government sans email? How was really anyone supposed to do their jobs without network access? Regardless of the procedures I put into place to restore access when these staffers were identified, it would never be fast enough. They’d be disconnected when it was the most inconvenient, and it would impact their jobs. We were not DARPA (Defense Advanced Research Projects Agency); this would never work in our environment. The realized downtime for these “bad actors” would have a very real impact to the association’s bottom line, and only a minor-to-moderate impact on the security of my network.

Guaranteeing the revenue that paid for my network was a relatively new concept for me.

Adding a little fear to network access

This doesn’t mean that I haven’t wanted to provide a little more real time “feedback” to my end users when they pick ridiculous passwords. But If all we do is provide negative reinforcement, our users do learn behaviors to avoid, but they don’t understand why they should avoid them in the first place. Ultimately, when left to their own devices, and not accessing our “aggressively-secure” network, they will fall back into their old behavior patterns.

Teaching the why as well as the how

Over the past 25 years, I’ve seen hundreds of password security requirement displays. Be it on the login itself, as a pop-up dialog, or as a document disseminated to staff, all these requirements miss two key elements: Why the rules are in place, and why our users should care. It’s pretty easy to assume as an administrator that your users are going to “understand” this particular network login provides access to critical assets. You’ve heard the saying about what happens when we assume, right?

Your users do not understand your requirements. They don’t understand the overall impact to password entropy created by just adding a single upper-case character (or what password entropy even is, for that matter). It’s up to you to inform them. A little fear-mongering can be good here, but ultimately, what we are going for is comprehension. This will help alleviate the frustration that ensues when they are unable to generate passwords that meet the complex requirements you’ve implemented. (Which is about as close as we’re going to be able to get to “punishing” these users. Seriously, even I hate being forced to perform a password reset.)

Inspiring secure behavior is an ongoing conversation, not an edict. It’s pretty easy to correlate security training with other, shall we say, less glamorous training environments. Yet, your users are people, and most of the time they have their jobs because they’re good at them. That job frequently has nothing to do with your role, so they are not required to understand the ins and outs of the technology. They just need it to work. Securely. It’s up to you to maintain the dialogue with them to inspire changes in their behavior. Here are couple of ideas to get you started:

  1. Presentations, webinars, etc.: You’d be surprised at how effective a 20-30 minute webinar can be. Get some time on their calendar, take one of their passwords, and crack it. Show them how little time and effort it really takes for you to break in using their login, and what the repercussions would be to the entire system. No one wants to be the one responsible for a data breach.
  2. Reminders, far and wide: You can use your email signature, login pages and your corporate intranet. Remind them why your requirements are there, and why they are important! Change their screensavers, or let them know during actual login. The medium used is less important than reminding them of the issue.
  3. Gamification:While not everyone thinks they have time to play, using simple solutions like trivia quizzes, team challenges (whose password is stronger?) or stand-alone games that grant points and rank users, all have an impact. A little bit of competition can be healthy, as long as you’re not using it as a cudgel. (Well at least not too much.)

This dialogue doesn’t have to be painful. In fact, there are lots of ways to make it fun and memorable. You can do more than just enforce stringent security protocols and beep at them. (More details on how to enforce stringent protocols and beep at them can be found in a white paper I published here.) From presentations to reminders to gamification and more, there are lots of ways to inspire better behavior. You just have to be creative, and remember that just because it is your priority, doesn’t mean it is the priority of every other staff member.

Since 1994, Joshua Hiller has been a professional software developer and security analyst, working as a private contractor, team member, and team leader. Specializing in automation, integration, penetration auditing and forensics, Josh has over 15 years experience working in the non-profit industry in roles such as application developer, department director, and vice president.

A married father of three girls, Josh’s interests include; art, comic books, fantasy, science (and science fiction), application and network security, software development and tropical fish. His favorite type of cichlid is Astronotus ocellatus (Oscar), followed closely by Andinoacara rivulatus (Green Terror). If left alone for long periods of time around new software or technology, Josh is highly likely to take it apart to try and figure out how it works. At random, infrequent intervals, Josh likes to create games out of interesting puzzles he’s encountered.

Since 1994, Joshua Hiller has been a professional software developer and security analyst, working as a private contractor, team member, and team leader. Specializing in automation, integration, penetration auditing and forensics, Josh has over 15 years experience working in the non-profit industry in roles such as application developer, department director, and vice president. A married father of three girls, Josh’s interests include; art, comic books, fantasy, science (and science fiction), application and network security, software development and tropical fish. His favorite type of cichlid is Astronotus ocellatus (Oscar), followed closely by Andinoacara rivulatus (Green Terror). If left alone for long periods of time around new software or technology, Josh is highly likely to take it apart to try and figure out how it works. At random, infrequent intervals, Josh likes to create games out of interesting puzzles he’s encountered.

There's More To Discover

Subscribe today for more thought-provoking content.
  • This field is for validation purposes and should be left unchanged.