Passwords, Part Deux

Another week-long meeting happened today. Started at 10am, brief break for lunch at 2pm, and continued until a few minutes past 5pm.

The first part of the meeting was a summary of the previous meeting for people that had not attended. Excuse me, is that not what minutes are for?

Anyway, we were running through things, and one of the items was the helpdesk system we use. It’s a web-based system with a MySQL back-end.

“So it connects to a database?” J said.

“Yeah,” came my enthusiastic reply.

“And this is where?”

“On the hosting account.”

“And the password for that is?”

“For what, the database or the hosting account?”

“No, I know the hosting account password,” he said, and he’d be right, after they un-ceremoniously snatched it from me the week before. “The database password.”

“Why would you want it? You would never need it unless you wanted to tinker in the database, and I strongly recommend you don’t.”

“But we just need the password,” said J. “In fact, is it one of these?”

And, to my horror, he held up a print-out of all the MySQL database names, and their associated usernames and passwords, to me. He then pointed out that this sheet was in the hand-out that all the attendees of the meeting had been presented with.

I sank a couple of inches farther in my chair. “Yes, second one down,” came my reply.

This company has a huge, massive obsession with passwords. They MUST know the password, even if they don’t actually know what the password does. I could create an account called Ben, make it a member of every privileged group on the network, set a secure password, and nobody would know it existed.

(Memo to self: leave back door.)

Then, I could remove the privileges from the Administrator account, mangle the user profile and logon script etc so that the account was useless at a terminal, and then prevent it from logging on anywhere else. Voila, a useless Administrator account.

Since my last post I’ve learnt that no less than four people, other than me, now know the domain administrator password, because my co-worker “could not be bothered” to escalate their privileges correctly, so he just handed the password to them so they could do it themselves.

“Sorry, sorry. I was busy, I was just on the way out the door,” was his reply. Not excusable. I’ve now got to change the password on every single device – every printer, router, switch, etc (a unified password strategy is not a favourite one of mine, but it was the one I was told to implement) – because of his laziness.

But back to this meeting, where I started complaining about how well-known the password was.

“That reminds me,” said M, the newcomer, “that rescue password you left in the safe for me is not the one that’s in this document,” he said, waving the minutes where J had handily documented the Domain Admin password, against my wishes.

“Why did you open the envelope? Have I died?”

“No, I just wanted to see. You know.”

“Not really.”

“Well, it’s a good job I did, because it’s not the one here.”

“What is the one that I apparently gave you then?”

“It’s pa55word.”

I quickly thought back to why I would have assigned that password.

“That password is for your test-bed CCTV server.”

He was already on the phone. “Can you do me a favour? In the safe, there’s a white envelope, with ‘Bristol Passwords’ written on it. Can you open it and tell me what’s in there? … Uh-huh? … Yep, that’s the one. Yeah, just open it. … Ok. … Yep … Yep … Yeah, that’s fine. Just put it back in the safe now. Thanks for checking.” He turned his attention to me. “Yeah, you’re quite right, it is the one in this document.”

So wait, he’d just told a random member of staff where the admin password was? And this fifth person now knows the password too?

It was 5:02pm. At a natural break in the conversation, I snapped my folio shut, stood up, and said “wow. What a way to spend a day. See you tomorrow!” and briskly made my way out the meeting room.

In nine days time I leave. And I can’t fucking wait.

Leave a Reply