« Jackson, Steve Jackson | Main | Redistributionism by Any Name »

March 28, 2006

IT Insecurity

Perhaps the most damaging aspect of IT security, particularly in large enterprises, is that security policies are not generally set by computer or network security experts. Instead, people who are reckoned to be security experts because they've done it before (without, generally, any user feedback on what they have done, and excepting disaster often not even getting feedback from other security people) are generally put in charge; or worse yet, non-technical managers are put in charge, of making IT security policies. This leads to policies that seem to be quite secure, but are actually not. In particular, most companies really cannot get password policies right, and in the process generally reduce their security.

Consider the typical enterprise: a few computer systems put in a long time ago were gradually built on, expanded and replaced; along the way, numerous other systems were created to solve various tactical problems, and these too were, over time, built on, expanded and replaced; there is a constant press to build on, expand and replace old systems and to create new systems to solve current problems. (Remember: by and large, computer systems exist in enterprises because they solve problems of some kind or another, at least theoretically.)

This leads to a situation where there are many, many dependencies between systems, largely undocumented; there are many systems that no longer really do anything, but appear to; there are many systems that have unknown user bases; and most of the systems don't talk to each other even to the extent of agreeing what a valid user identity might be. (And yes, there are tools to solve these problems, which involve installing more systems....) As a consequence, a user might have one id/password for the corporate portal or blog, another for the email system, another for the network/his computer, another for access through the firewall/proxies to the external Internet, and a half dozen others for other systems. In the perfect case, all of these systems authenticate the user (that is, determine that he is who he says he is) via the same system, so that one id/password combination gets the user into any systems he needs; and in fact via single sign-on the user should only have to login once to gain access to all of these systems. In practice, virtually no company has fully integrated their access and identity management, and in most companies I've worked for, a given user has an average of some 2 or 3 user ids and between 5 and 10 passwords to remember. And this is where it gets fun, because of security policies that don't work as intended.

Let's say that I have 3 ids that cover 12 systems, and some of them are integrated with a centralized user store so that I only have to remember 4 passwords. That's not bad, as enterprises go, actually. But generally each of these systems that is not integrated with the common user store will have their own password policies, which may be similar to but not quite the same as that of the common user store. (Typically, corporate IT policies will drive security policies to resemble, but not match, each other, because different systems can support different subsets of what the administrators want to implement.)

Now, I can remember 3 ids and 4 passwords, and which systems they apply to. (Some people can't; I have lots of practice.) But there are challenges to my memory, from the aforementioned policies. First, passwords are almost always required to be at least 8 characters. This makes it more difficult to break an encrypted password, should you acquire one, since each additional character doubles the number of possible combinations you have to try. Second, passwords are almost always required to have different types of characters in them (capital and small letters, numbers, non-numeric characters). This means that an attacker cannot cut out possible combinations by limiting the character set he tries to crack against. These are good policies. Now for the bad ones, in practice, that sound good, in theory.

Password reuse is often restricted, so that, for example, the last 12 passwords cannot be reused. This sounds good: it means that if an attacker manages to break a password, it will (once changed) not be useful to him for another year. But in practice, it means that you now have to remember a series of passwords at least one longer than the amount you are unable to reuse, or that you have to remember a new set of passwords each time you are required to change passwords. And rest assured, the passwords will be forced to change on different days, so that you are forced to remember new passwords and forget old ones several times per month.

Password complexity is generally enforced. A typically draconian password rule is at least 2 each of capital letters, small letters, and numbers and at least 1 other character must be present, and no character can appear more than twice. (Note that 7 of the minimum 8 characters of your password are generally constrained.) In addition, to make cracking passwords based on user knowledge more difficult, variations on your name or id, and often other bits of information, are generally forbidden. In some cases, variations on common words, where numbers are used to replaced digits (1 for l, for example) are also forbidden as too easy to crack. These also sound good in theory, but are in practice problematic. First, different systems are able to implement different parts of this kind of rule set, so that in practice a password that works on one system may not work on others, so that the user cannot even set all their passwords to the same value. Second, the complex passwords that result are difficult to remember, and in combination with the passwords changing on different dates and not being reusable, this makes the memory problem much, much harder. Exponentially harder, in fact. (Also, from a brute force cracking perspective, it means that I as an attacker could eliminate a large part of the potential password set, because those passwords would violate the rules.)

Passwords are generally forced to be changed every month in a large enterprise. This is a good idea, because it means that a cracked password is only good for a limited time, but it results in more problems, because of the complex password requirements and lack of ability to reuse passwords. The practical upshot is that it becomes nearly impossible to know your ids and passwords after about 4 months of working within such a security regime. "Nearly" impossible, but not impossible: there are in fact three strategies that users can take to cope with this problem.

The first strategy is of only limited use: do things manually. People learn to avoid things that cause them pain or inconvenience, even if the that is limited to embarassment (at, say, having to call the help desk to get password reset) or lost time (as they try several possibilities). So once systems are too inconvenient to use, people will not use them except when they are required to as part of their job. Peripheral systems (the kind that keep, say, documentation on processes, "important" company news, tracking records, bug reporting systems, frequently asked questions and the like) fall by the wayside as too much additional trouble.

The second strategy is fantastic, and I highly recommend it if you cannot change the security regime at your enterprise: create a system. I won't detail mine, for obvious reasons, but in general you want to create a base password, and make every other password a permutation of that. For example, as an "easy" system, let's say that your base is the ever popular "password". You can vary this to meet the password requirements I gave above by adding capitals: "PassWord", digits for numbers: "Pa55Word", and the occasional symbol: "P@55Word". But then you add in an additional factor, the current month, so that as you change your password each month, you know the current one (assuming you've been using the systems, so that you're forced to change monthly) will have either this or last month's symbol in it. For example, you could use the following set of passwords: "P@01Word", "P@02Word", "P@03Word" and so on to "P@12Word". Assuming, of course, that your security system does not flag "Word" as being a dictionary word, and refuse to let you use it as a part of your password. (Speaking of bad security rules: this one works fine if you're checking the whole password, but really badly when checking a substring of the password.)

But let's face it, most people are idiots. I know that this sounds mean, but having been involved with supporting people using computers over close to two decades now, pragmatism demands that I realize reality. The world is simply not as nice as we'd like it to be. And given that most people are idiots, and that even those people that are not idiots are often too busy to make up a password scheme like I suggested above (particularly when there will almost always be at least one application or system that forces you to violate your password scheme), virtually all enterprise users eventually default to the third practical solution: write down all of your passwords and ids.

Now this is a security no no: I don't (as an attacker) have to guess your ids or break your passwords if you hand them to me on a piece of paper. Think Prisoner of Azkaban here, where Neville wrote down the passwords to the Griffindor common room. But it's not the users' fault that they have to write down their ids and passwords: the security system forces them to do so. (I've twice been at companies where I've had to do so, in one case because of a system that assigned passwords on its own, random 5-character passwords, and in the other case because I coldn't come up with a system that would match all of the disparate rules of the various systems I had to use.)

So guess what I found this morning?

I blame the security guys, though, not the poor secretary who had to remember not only her own passwords, but those of the directors she supports. Although, perhaps taping it to the computer was a bit much; she could at least have locked the list in a drawer.

Posted by jeff at March 28, 2006 9:00 AM

Trackback Pings

TrackBack URL for this entry:
http://www.caerdroia.org/MT/mt-tb.cgi/914

Comments

Posted by: Aubrey Turner at March 28, 2006 9:09 PM

Posted by: Aubrey Turner at March 28, 2006 9:11 PM