Voice of the DBA

Tag: security

  • Automated Driving

    In the book Red Thunder (highly recommended), the highways are under the control of some computer system. You approach a highway, get into some merge lane, and then a freeway computer takes control of your car, disconnecting the steering and foot controls and drives you along. When you want to get off, you signal, the computer moves you to an off ramp, and then releases control. It’s efficient, with the computer putting cars bumper to bumper, with a few inches between them since everything is under control.

    It sounds great to me, but I’m not sure we’ll ever want to completely put our transport under so much computer control. However people are trying, with automated subways and trains, but many of these still have an operator. There are quite a few projects looking at bringing this type of control to cars, though I’m not sure if we’ll ever get approval for something like this without some type of closed track that only allows automated cars.

    Think about all the issues you see in computer software, even supposedly well-written software. There are always bugs and unexpected code paths or even demands being made of the software. There’s also not enough testing to convince many people that we can really write extremely high quality, complex software that can handle something like traffic maneuvers.

    Then there’s the security. Whether it’s a central system that controls flow on a road or a distributed system in each vehicle, can you imagine the possible consequences if there were some security breach? What if someone finds a way to do some sort of SQL-Injection like attack, such as the one I show above?

    As much as I’d like to be able to ride in my own car, but have it handle the driving chores sometimes, I’m not sure our technology is anywhere close to the level it would need to be for me to trust it.

  • 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.

  • MERS

    Imagine you have this idea. You’ll build an electronic database designed to record rapidly changing data for assets that move between companies. You make contacts with the various companies and your system acts as the middleman. You are the central database, reducing the costs these companies have by trying to keep their own systems in sync. But what happens when your database becomes the legal record and it’s not up to date?

    That is what might have happened with the MERS system. It is supposed to record the mortgage titles, linking homeowners with their mortgage holder. Since mortgages are often sold many times during their lifetimes, MERS was supposed to reduce the costs and time involved with each sale. By having MERS maintain title, recording fees and time is reduced as everything is centralized. Theoretically, this is what we want centralized databases to do: make things more efficient and accurate.

    But that’s not always what happens. We make mistakes, we have coding bugs, and a single database could easily have many mistakes in it. In fact, this is why having a single database for a distributed system could be a bad idea. Multiple databases can allow you to compare data, and perhaps track down any discrepancies between systems.

    This is one reason that a data warehouse can be a valuable addition to your company. By taking feeds from multiple systems, and standardizing the information, it’s easier to use. However that ETL step can provide a valuable double check of your data, and a good feedback look can enable you to find data quality issues and correct them.

    I don’t know if the MERS system has data quality issues, but if they are going to be a legal system of record, their data has to be accurate.

    Steve Jones