Password pain

ChannelInsider bemoaned bad password policies and practices late last week.

It’s a problem. Security (unfortunately) is my specialty, so I know it’s a problem. But it’s going to get worse before it gets better.There was an old User Friendly cartoon where a helpdesk operator spitefully changed an annoying user’s password to something like !Qoh&32;[ or something like that. Unfortunately, we’ve gotten to the point where the industry-standard password policy requires users to have passwords like that–only twice as long.

Let me tell you about one of my clients. Their policy is especially draconian. The passwords have to be at least 15 characters long and have two uppercase, two lowercase, two numbers, two special characters, and two umlauts (OK, no umlauts required), but then they add some other restrictions on top of that. These restrictions make the passwords considerably harder to remember, but they also significantly reduce the number of possible passwords (which is why I won’t disclose the restrictions–and no, I won’t disclose the name of the client either). So the end result is that the passwords look really secure, but really aren’t any more secure than the 8-character passwords they were using a few years ago that had fewer restrictions.

There are several unfortunate results to this situation. One is that it takes several days to come up with a decent password. As a result, passwords get passed around. “Does anyone have a password that works right now?” is a common question I hear. Yes, passwords get passed around. Or, slightly less worrisome, they become collaborative works. Someone hands over a slip of paper with something cryptic like 1977-22@MINal.296 written on it and wants to know why the password policy rejects it. If the first person can’t figure it out, someone else looks at it.

Personally, I think if that password had more umlauts, it would probably get through the policy. But that’s just me.

And then the password age keeps getting ratcheted down. It takes almost 30 days to memorize these stupid things. But by then, the passwords expire and the whole cycle starts over again.

Ultimately the solution is going to be ever longer and ever more complex passwords with ever-shorter lifespans. Maybe 32 characters long, with four upper, four lower, four numbers, four special characters, and four foreign language characters (stuff you have to type by hitting ALT and a four-digit keycode on the numeric keypad). I hesitate to say this, because someone’s going to think that’s a great idea and adopt it. So maybe I should patent the idea to prevent that from happening.

And the result will be ever greater resentment, more password sharing, more passwords on sticky notes attached to keyboards and monitors, and even greater willingness to exchange a password for a piece of chocolate.

Loosen the restrictions a bit, cut users a bit of slack, educate them on the importance of good passwords, and the result can only be greater security. Until then, things are only going to get worse, on all fronts.

It’s too bad Secure Channel didn’t think of all that.

Buffer overflows explained

Buffer overflows are a common topic on a Security+ exam. The textbook explanation of them is confusing, perhaps even wrong. I’ve never seen buffer overflows explained well.

So I’m going to give a simplified example and explanation of a buffer overflow, similar to the one I gave to the instructor, and then to the class.

Read more