Slashdot responders often savage system administrators for their poor security practices. Whenever I see one of these stories I wonder how much had to do with sysadm cluelessness and how much with internal politics.

One day about a year ago I cleaned up the firewall on our password server. The person who had helped me set it up was still allowed in over secure shell; he was no longer at the University, so I removed his entry from the firewall. About a week later, I got a call from someone in Finance wondering why their batch jobs were no longer able to contact that server.

This is the server that every single sign-on application at the University connects to and sends off username and password to for verification. And there was another server out there with automated shell access to it.

I’d like to say that I blew my top, but I didn’t. That’s just par for the course at the University. I’d like to think that I was firm when I said that this was unacceptable, but I can’t have been firm enough. I extracted a promise from that programmer that they’d find a new home for those files.

A year later, I removed the entry from the firewall again. Same thing; they’d never fixed it. I extracted a promise and a date this time from (the now different) programmer. A few weeks after the deadline, I removed the entry from the firewall, and of course, got a call from that programmer.

But this does bring me to my most effective security test: if this server were broken into because of this feature/backdoor/whatever, what would the response on Slashdot be?

1. Jesus, what can you do? That happens to all of us.
2. That’s a common mistake. Here’s what we do to keep from making it.
3. How could that guy be so clueless?

In this case, I’m going to have to go with “How could that guy be so clueless? Batch shell access to the password server? What the hell was he thinking?”

This morning, we had a meeting about the process that this file transfer is a part of, and I brought up that the file transfer really needed to be taken off of the password server. At this point we even have a data warehouse server solely for file transfers between specific servers. Yay! right?

No, the suggestion was that we open up the password server further so that more people can monitor the progress of that file transfer process.

At this point it’s only a matter of time before we do show up on Slashdot.

The rest of the system is even worse. The same day I discovered that our new authentication system stores every user’s password in a reversible format. It displays them to the student workers when the user calls in.

• The people with access to every user’s password, from the president on down, are our lowest-paid, highest-turnover ITS employees.
• The system that displays the unencrypted passwords uses a single username/password shared among multiple users.
• The system that displays the unencrypted passwords is available from anywhere on the Internet.
• In the past, the help desk could only change a password rather than get the current password. Now, if a hacker manages to social-engineer a password out of our help desk, they’ll get the current password. The real user will never know that their account has been compromised.
• Besides displaying the challenge/response (that is, “what city were you born in”), the system also displays the last four digits of the user’s social security number and their date of birth.
• The password to display this information is an easily-guessed one, the exact kind of password we recommend that our users not use.

That’s just off of the top of my head. This is wrong on so many levels.

Oh, and the final icing on the cake: I’ve been saving up these security issues because we’ve got a security position we’re trying to fill. I found out today, were trying to fill. We’ve decided that security professionals are too expensive. So now I’m going to bring it up after the start-of-semester mess winds down and they’re less easily ignored.

My bet is that we’ll need to open up the server so that more people can monitor these processes.