Passwords: just another bureaucratic annoyance

by Andy Oram

Yesterday I heard of a government agency where the manager required employees to post their account names and passwords on a bulletin board, so they could get into each other's systems in case one of them was out for a day. This was told to me, along with examples of other security policy lapses, by an IT consultant who works for government agencies.

Many workers in human services, she told me, are reluctant to provide data that would be useful to improve the services. She'd like to track homeless people as they move from one jurisdiction to another for instance, to provide better continuity of service and find out what works and what doesn't. The agency staff are afraid that sinister forces within government will misuse data. While we have no lack of sinister forces in government, it appears that the people needing human services are more at risk of snooping by random staff people, facilitated by the awful security practices just mentioned.

I'm not surprised that employees would treat passwords as just one of the many random impediments they have to bypass each day to do their jobs. Given how many regulations reflect political grandstanding rather than life on the street, and how many well-meaning regulations outlive their usefulness, workers have to interpret the rules in a (shall we say) creative manner. I'm sure many employees in private industry get through the day the same way; it's not limited to government. But an even deeper issue is at work.


Karl Fogel
2007-08-08 09:03:15
One problem that most bureaucracies seem to have is the "enter the same data many times" problem. When you go to the hospital, you can end up writing your name and address five different times on five different forms; same at the state department of motor vehicles; etc. I'd guess that one of the problems with government computer systems is that your username and password fall into this category: you have to keep entering them over and over, and sometimes they're not the same username and password (because different systems have different rules for what is a valid username or password). I certainly feel like life got a lot easier after my browser (Firefox) started encrypting all auth creds with a master password, so that it was safe to let it remember creds between sessions. Effectively, that master password is now my one password. All the other stuff is implementation details.

In general, this is the problem that OpenID is meant to solve. But then the problem becomes that all your eggs are in one basket: if someone gets access to your OpenID creds, they get access to everything. Maybe OpenID has some system whereby you can have different levels of password (low-, medium-, high-security) for the same username?

Auditing might help. If every system logs all accesses, and there is a credible threat that the logs will be audited from time to time, then people will behave responsibly while logged in, and identity theft would be more easily detected. In particular, it might be good idea (in OpenID) if at any time I could view a summary of *all* places where I'd logged in, and for how long, in reverse chronological order. Maybe that summary could even be emailed to me once a week. The online summary has to be read-only, though. That way if someone cracks my OpenID creds, they can only view the summary, not change it.

2007-08-09 21:30:55
Governments aren't the only ones with these kinds of problems. I am a consultant who works for mostly private corporations and I have seen some doozies. One great example was this unix sysadmin who simply didn't want to adhere to the IT security policy we crafted for a secured printing system. His ONLY job was to install the Linux systems and then hand over the keys to us for integration testing for the next phase of the project. Instead of installing them and just leaving it at that, the jerk created himself a user account on every box and put an suid shell script in it so he could gain root anytime he wanted. I guess he thought we were dumb and wouldn't notice something so obvious. His excuse was that he didn't want to adhere to the IT process for obtaining elevated privileges because "it would take too long". Anyway, we tried to have the guy fired but he was a nephew or something of someone important and was simply moved to another division, presumably to continue his idiotic habits.