Bad policy makes for weak passwords

It's unprofessional to break down and sob during a meeting, but I came pretty close a few times last week as I finally began to understand the details of the IT security systems and processes my new company uses to protect itself.

I'm fairly new here, so there's a lot I still don't know. But it wasn't long before it became clear to me that things are deeply wrong. It seems like every week, I uncover layer upon layer of seemingly minor issues that undermine a lot of what we do.

This week, it was passwords. The main problem is that they're easily guessed and frequently shared. My security team continually tells users that they must pick strong passwords and not share them. But we've been unclear with users about what counts as a strong password because we've been unsure about it ourselves.

Most computer systems store a one-way encrypted password in a database. When you attempt to log in, they encrypt what you type and compare that to the stored value. If both match, the system logs you in.

If an attacker can connect to a server, he can attempt to guess the password by just trying various words; password, secret and jamesbond are favorites. But if an attacker can steal the encrypted list or password file, he can launch a more insidious attack. Instead of connecting to the server -- a slow and sometimes detectable process -- he can take a dictionary of common words and encrypt them using the same process as the server and store each in a lookup table.

If an attacker wanted to break into more than one operating system, he'd need one table for Windows servers and three for the three main kinds of Unix. Then, once he'd stolen the encrypted passwords, he could just look in the table and see which word each matched.

A hacker launching an online attack is likely to make a few hundred guesses before he's spotted or moves on. But an off-line attack can cover hundreds of thousands of passwords every second.

The problem is that operating systems' core method of storing passwords hasn't changed for many years, but the speed of computers has increased thousands of times. It has reached the point where if your encrypted Windows password file is stolen, even a low-end hacker has enough computing power to break it in a few days.

It would be nice to be able to make sure that nobody can access our password file and to teach our users not to pick the top 100 risky passwords that a hacker might use in an online attack.

Dire situation

My predecessors spent many thousands of dollars on cracking software and hardware to test the strength of passwords, and they found that about 15 percent of the passwords used in my company are weak. This is actually lower than the industry average, which shows just how dire the situation is in the financial services industry.

But had a lot of work been done to find and educate the users with bad passwords? No. Some grand schemes had been discussed about replacing passwords or improving operating systems so that only good passwords could be chosen, but nothing was ever delivered.

The result: In addition to allowing those bad passwords to be in use, my department was also running a computer that had a duplicate, unencrypted list of all of those bad user accounts and passwords. If someone had stolen that list, we'd have done the hard work for them!

So I began asking team members to call groups of users with weak passwords and discuss better password choices. It turns out that most of the users we've called so far weren't using those accounts and didn't know they had them. At least we can now delete them.

We may have done only half the job with passwords, but in other areas, we've done a job and a half. For example, when my team and I dispose of a computer, we use a utility to wipe the disk clean. We overwrite every part of the disk with a string of zeros. But the tool we use is slow and must run from a floppy disk.

For some reason, my predecessor forced the IT support teams to use a different floppy for each target machine, write a log of the actions back to each floppy and then bring them to the security team to be checked.

This works fine with one or two machines, but after we conducted a disaster recovery test where hundreds of machines had to be wiped and returned to the disaster recovery services vendor, we found that creating and then checking the log data on all of those floppies was a huge waste of time. Nonetheless, it took a lot of convincing for everyone to follow a new process based on more trust in the support team.

I knew I was in a new company when members of the support team finally admitted that they didn't like producing the logs and had just been giving the security staff the same floppies after each test with ancient log entries on them. My staffers had never caught them because they weren't checking. Everyone was just going through the motions.

It's nice to find a process that takes less time for the support teams and less time for my group and actually ends up with disks being wiped clean.

I'm sure these won't be the last problems I encounter, but if I can ensure that we have good passwords and establish realistic policies that get followed, then I think we can improve the level of protection around here. w What do you think?

- This opinion is written by a real security manager, "Vince Tuesday," whose name and employer have been disguised for obvious reasons. Contact him at vince.tuesday@hushmail.com.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about Security Systems

Show Comments