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.