It’s the second Tuesday of the month, time for T-SQL Tuesday again. This time the invitation to participate comes from Sebastian Meine (@sqlity, blog) with the topic of passwords. It’s a great topic, especially as security concerns are growing regularly.

I would encourage anyone that looks to build their brand, and further their career to write a post for T-SQL Tuesday. It’s easy, just look for the invitation and then publish on the second Tuesday of the month.  Be sure to follow the #tsql2sday tag on Twitter.

You can even go back and write about previous topics, and share your own thoughts and insight. I keep a list of previous topics here: T-SQL Tuesday Topics.

SysAdmin Passwords

I’ve tried to maintain strong passwords for years. I used to have a formula, similar to Bruce Schneier, where I’d use a sentence to build a password. However a few years back I went to Password Safe, and have been using that on Windows, OSX, iOS, and Android, with Dropbox keeping my password safes in sync. I let Pasword Safe generate my passwords, 12 characters), with random digits and I use this to stick passwords into systems.

I use a different password for every system, which has been fine for me. It’s slightly annoying to unlock the safes on a mobile device, but I like the idea that a compromised password on one system doesn’t affect any others.

Years ago, I worked as a DBA and we managed a large number of systems. One of our mandates was that administrative passwords would be changed every 30 days. That was fine for the people running the systems, but changing the administrator password for hundreds of Windows hosts was an issue. We grouped servers (IIS servers, Exchange servers, etc), to make it easier for each administrator to manage the systems, but it was still a challenge to create passwords for each group every 30 days.

I introduced Password Safe, and simplified things. We let the application generate passwords for each group, stored them in the safe, and used a script that took the group and password as parameters to change all the systems passwords. This was still time consuming, but it provided for a limited window to crack a password, allowed us to use longer passwords, and we could also retrieve them when we needed to administer a particular system.

Note that this was just for administrator passwords. We had a separate scheme for service accounts, which was to randomly create a long, 15+ character, password that was used to start the service, but was never stored. Similar to many applications, we couldn’t recover the service account passwords. If we needed one, we changed it, and sent a note to the security group whose event log scanners would note the change.

I know that strong passwords don’t necessarily solve our security issues with hackers and social engineering, but I do think this is the lowest bar you can tolerate. If “sa” and blank, or “sa” and “password”, or “system” and “manager” (for the Oracle folks) work on your database, you deserve to be fired. There’s no excuse for not picking a strong password for privileged accounts.