Tag: security

This editorial was originally published on Aug 10, 2012. It is being re-run as Steve is on vacation.

Many years ago I worked in a small company that only had about 5 or 6 servers. We had one system administrator whose job it was to manage all the servers. One day our sysadmin was on vacation when there was a problem with the Exchange server. One of the other developers worked on the system and ended up fixing it, but changed the service account password while doing so. The next day I walked into the office to find a group of people stymied as to what was wrong with the development server and version control system. Everyone claimed they hadn’t changed anything on that server, and they were right. However our admin used the same domain account for all servers, including my SQL Servers. I changed the SQL service account that day.

One of the recommendations that I learned a long time ago, and one that I make regularly, is that every SQL Server instance should have a separate security account. In that case, I had separate accounts created for each database instance, and for each SQL Agent instance. We used long, random passwords that were never stored, and if we needed to access a password, we just changed it. That kind of flexibility and separation prevented any crosstalk issues between services, and it allowed us to easily alter permissions or passwords for one service without affecting any others.

The other day I saw someone recommending a single service account for all SQL Servers. Someone else recommended a single account for each version of SQL Server, using separate accounts where it’s really needed. That’s a better recommendation, but I still prefer completely separate accounts. I know that some security groups don’t like that, but is it that big a problem? This Friday I wanted to ask you about your experiences.

Do you find separate accounts for each instance (or Agent) to be a security or administrative issue?

I’m not sure why this is unwieldy. Service accounts rarely change, and you could easily script changes to a group of accounts with PowerShell or some other tool. Once I set a service account, the only thing I might ever do later is alter the permissions to add access to a folder. When that happens, I definitely want to have separate accounts for each instance.

Steve Jones

One of the main issues with connecting databases to the Internet is that if a hacker finds a way to get access to the database with credentials, perhaps using a well known account (*cough* sa *cough*) and a weak password, they can get a lots of data. However, even if your database is not on a DMZ or addressable from the Internet, chances are some application that accesses your database is connected to the Internet. Websites are a perfect example of this.

That means our data security is controlled by the security of the web application, and the security coding practices of our developers. That’s a scary in many cases, primarily because we, as an industry, don’t do a good job of actually sharing secure coding practices and habits widely. As much as people talk about and publish information about writing secure code, this doesn’t get spread around to many developers, who have years and years of bad habits. Even here at SQLServerCentral, we don’t have nearly enough information on SQL Injection, which is something I need to work on.

However, even if you aren’t exposing your database server and aren’t vulnerable to SQL Injection, is your data secure? I read a rather sad article from Troy Hunt that looks at how personal data can be leaked. Far too many applications don’t follow secure information handling practices and unintentionally allow information to leak. Perhaps the most common item is verifying whether an account or email address actually exists or not in a login or password reset box. There are other examples, including not properly securing an entire page with SSL, allowing a simple thing like an order number to return user details, or even allowing someone to reset a password by guessing the answer to a security question.

These seemingly benign issues often expose real vulnerabilities. I’m sure many managers and even developers would say that a hacker wouldn’t sit at a web page and try lots of email addresses. That’s probably true. However, does your web application have limits for how often someone can submit code? Extremely powerful scripting tools like Perl, Python, and PowerShell mean that a user could make submissions to your website in an automated fashion, retrieving the code and parsing it to find details.

Most attacks on a system aren’t of the Hollywood movie variety. A hacker doesn’t find some hole and miraculously gain access to data in a few minutes or hours. Instead, a malicious user (outside or inside your organization), might make a series of attacks across days or weeks. They might try millions of emails or order numbers, gathering details and planning their future attacks that will actually reveal sensitive information. All those tools that make your job easier as a developer, or allow complex data analysis, can work just as well against your database as they do with your data.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.9MB) podcast or subscribe to the feed at iTunes and Mevio .

A few years ago, I had a keyboard die. At the time, I needed something quickly and ended up with a Logitech wireless model that included a mouse. I’m not sure of which model, but I’ve ended up getting two or three more Logitech devices over the years. I think I go through a keyboard every 18-24 months, though the mice seem to last longer. For me, having devices available without cords is more important for the mouse than the keyboard, but since Logitech will bundle them, I get both at the same time. I’m currently with a K350 keyboard and an M510 mouse, both of which seem to hold up well.

However, I’m at home, usually working alone, so I haven’t been concerned much about security. In corporate environments, I remember playing jokes by moving someone’s mouse to my desk, and giving them a disconnected replacement, trying to mimic their movement. Or doing the same with a keyboard. That’s a great typing challenge if you ever try it.

I thought about those times when I read this piece on the security of wireless keyboards, or maybe the lack of security. Apparently a relatively simple device can intercept and replace, or just record, keystrokes made on a variety of keyboards. These devices use their own dongles, not a Bluetooth connection, and security is non-existent. Perhaps I’ll take one to the Redgate office this fall and see who’s actually vulnerable.

Actually, I think this is an issue, especially in large companies that may regularly hire consultants. Who knows what temporary workers might do with information they can gather by just sitting in proximity to a domain administrator. Or a DBA. We might be disclosing passwords to all our systems. Even malicious insiders may end up with access they shouldn’t have, including the ability to run queries or commands under another individual’s account.

Since keyloggers are cheap and simple, perhaps this seems like an unwarranted concern. However making the move to actually touch someone else’s machine, and add a device that could be noticed is much more dangerous than just sitting, or even standing with a tablet, by someone’s workspace. Even a simple conversation, asking an admin to look up information could result in a breach of security.

Fortunately this hack targets a few devices, and doesn’t work against Bluetooth devices. However, there are attacks against those, and against wireless access. I know some environments have very sensitive information, or even tight security regulation. I really hope we don’t find our administrators going back to hardlines for administrative access from specific machines, or even only using secured wired because we can’t strong wireless security for our devices.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.3MB) podcast or subscribe to the feed at iTunes and Mevio .

What should we do about passwords? They’re a thorn in the side of administrators trying to keep systems secure, but they’re also an issue for users. Not for most of our users, but certainly for some. In hospitals, or other high stress environments, there are all sorts of issues with users sharing passwords, writing them down, leaving systems logged in, and more. Studies have shown this to be the case, which is something that drives IT people crazy. Why can’t people just use strong passwords and learn to remember one?

I’ve dealt with this in many situations across the last couple decades. I’ve had management get upset that the local LAN password didn’t match their mainframe password, which was apparently, a big problem for managers. I’ve seen warehousing groups not want to have systems logged out, so a single login was used for all users to speed up access for data entry. Applications grown far and wide in another company, with embedded passwords, so that a single password for a domain admin account was unchanged for at least 5 years.

It’s not just normal users. I’ve had separate administrator level and regular user accounts (as did others in my group), yet far too many of us (myself included), managed to use our privileged account for everything from email to web browsing, mostly because it was “too hard” to run as administrator for tasks. A great example of both hypocrisy, as well as the ways that technical people can get around many restrictions that might frustrate other users.

More recently I’ve seen a dramatic growth of Two Factor Authentication (2FA), where logins often result in a text message or other verification scheme in addition to a password. What I usually see here is frustration and irritation from users having to wait to log in. Until something happens. A friend had a virus recently on their machine, and all of a sudden was worried about their finances being secured. They then decided to add 2FA to their various banking logins.

The idea of a password seems simple and easy. At least to many of us that log in a few times a day at our desks. Log in on your phone, or use 2FA everywhere (like I do), and it’s more complex, but still acceptable. Usually a 30-60s delay isn’t a big deal for me. However, if I were in time sensitive situations, like a hospital or law enforcement situation, or worse, at war, I might feel differently. The balance between security and access usually tips to the latter when time is a factor.

Is there a better way? Should we move to an audit method for security in high pressure situations? Just monitor and review later, allowing easier access? Or should we try to find ways to integrate simpler systems into our computer devices? Maybe a physical key in some situations to log someone in? I dislike having physical fall backs, especially given that I’ve seen computer systems, keycards, and more fail at inopportune times.

Ultimately, I think the ideas of trying to authenticate a person quickly might really require rethinking how we can best handle the situation. Maybe staffing should be different in crisis situations with a person monitoring access to an open system (along with auditing). Maybe we should build better embedded systems that might perform authentication quicker, or even use video and machine learning to try and audit in real time, allowing for quicker review and response rather than attempting to stop access initially.

There are likely few situations where this is a big problem. I think for most of us, in many corporate and work environments should just get used to having to log in, potentially with 2FA more often. And we should get used to better using password managers to manage our various name and password combinations.

BTW, if you want to see just how bad developers can be with authentication, check out Troy Hunt’s post.

Steve Jones