Voice of the DBA

Tag: passwords

  • T-SQL Tuesday #58–Passwords

    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.

  • Should You Write Down Your Passwords?

    Today’s editorial was originally published on June 27, 2005 and is being reprinted today as Steve is out of town.

    According to Jesper Johansson, senior security program manager at Microsoft, the security industry is giving out the wrong advice by forbidding people to write down their passwords. Strong passwords are impossible to remember and lead to people picking easy passwords or using the same password across all the systems that they access.

    And using the same password across all systems us poor security. I tend to agree with that in most cases because if one system is compromised then all of them are. However, for the administrators, it’s problematic if all systems have different passwords. Then the cost (in time) of administering these systems goes up. I admit that in most of my jobs I’ve used the same sa password on all servers and the same administrator password on all systems. The caveat is that we change those passwords often, usually every 30 days and always when an administrator leaves. While a security breach would leave all systems vulnerable, the window of opportunity is fairly small.

    Bruce Schneier says that it’s impossible to remember strong passwords. And now password cracking programs are hip to the 3 for e and 0 for o replacements (and others). Plus with distributed cracking programs and cheap hardware, it takes less and less time to crack passwords for anyone that truly wants to get at your systems.

    It’s quite a quandary for people. To me there are two problems we are trying to solve. One is protecting systems for the administrators. These are more technically competent people and should be required to build stronger passwords. The system that I liked the best over the years was the central storage of all our administrator passwords (Windows Admin, SQL, Exchange, service accounts, etc.) in a central storage file. We used Password Safe for this on a network share accessible to administrators only. We changed the file password periodically and scripted changes of the various passwords every 30 days. Usually we’d solicit some theme and assign an administrator to change the passwords.

    The other problem is how to get users to create and deal with complex passwords. Of all the suggestions that I’ve seen, I think writing them down is a good idea. Make stringent requirements, 12 characters, mixed case, numbers, etc., require changes often, but allow them to write them down. Not on sticky notes, not posted, but maybe a card that they keep in their wallet or purse. Or these days, maybe their cell phone.

    Now if we could just somehow secure your cell phones. Maybe outlaw Bluetooth?

    Steve Jones

  • One Time Passwords

    Facebook seems to be constantly under fire for one privacy issue or another. I think it’s likely something that they will deal with forever, since their fundamental purpose is to find ways to share data with others and many people don’t understand the tools that Facebook has built for them. As I follow the growth of Facebook and see the new features that they add, I think they do have some commitment to making it easier for people to better secure their information and only share it in the way they want.

    Recently I saw on the Facebook blog two neat features that I really liked, and I think might be nice additions to SQL Server. One was the ability to remotely log your account off from other locations. This could be handy for people that might access Facebook from a public terminal and forget to log off. We can easily have an administrator do this in SQL Server by killing off a session.

    The other feature was the addition of a one-time password for someone that might want to access their account from an unsecured terminal. At first I thought I’d never need to use this, but then I thought about all the times that I had accessed a server from a friend’s computer. Or how often I had a request for some data that required a new account. What if I could setup a one-time password for an account in Reporting Services that would allow someone to view a report, or download some data without permanent access?

    It would be an interesting way to handle ad-hoc access to systems. In the past I’ve usually enabled a specific  account for a short period of time, but then I’d have to set a reminder or remember to do disable it. That wasn’t something I always remembered to do.

    However allowing someone a one-time password might be a good way to allow them access to data they need on a limited basis. I could see the need for a one-time execution of a report being a feature that would allow me to distribute data easily for a single use. It could be very useful in ensuring that accounts that were granted rights did not have them forever.

    Steve Jones

    This was also published at SQLServerCentral, which includes a discussion of this piece.

  • Should You Write Down Your Passwords?

    According to Jesper Johansson, senior security program manager at Microsoft, the security industry is giving out the wrong advice by forbidding people to write down their passwords. Strong passwords are impossible to remember and lead to people picking easy passwords or using the same password across all the systems that they access.

    And using the same password across all systems us poor security. I tend to agree with that in most cases because if one system is compromised then all of them are. However, for the administrators, it’s problematic if all systems have different passwords. Then the cost (in time) of administering these systems goes up. I admit that in most of my jobs I’ve used the same sa password on all servers and the same administrator password on all systems. The caveat is that we change those passwords often, usually every 30 days and always when an administrator leaves. While a security breach would leave all systems vulnerable, the window of opportunity is fairly small.

    Bruce Schneier says that it’s impossible to remember strong passwords. And now password cracking programs are hip to the 3 for e and 0 for o replacements (and others). Plus with distributed cracking programs and cheap hardware, it takes less and less time to crack passwords for anyone that truly wants to get at your systems.
    That’s quite a quandry for people. To me there are two problems we are trying to solve. One is protecting systems for the administrators.These are more techincally competent people and should be required to build stronger passwords. The system that I liked the best over the years was the central storage of all our administrator passwords (Windows Admin, SQL, Exchange, service accounts, etc.) in a central storage file. We used Password Safe for this on a network share accessable to administrators only. We changed the file password periodically and scripted changes of the various passwords every 30 days. Usually we’d solicit some theme and assign an administrator to change the passwords.

    The other problem is how to get users to create and deal with complex passwords. Of all the suggestions that I’ve seen, I think writing them down is a good idea. Make stringent requirements, 12 characters, mixed case, numbers, etc., require changes often, but allow them to write them down. Not on sticky notes, not posted, but maybe a card that they keep in their wallet or purse. Or these days, maybe their cell phone.

    Now if we could just somehow secure your cell phones. Maybe outlaw Bluetooth

    Steve Jones