THE SQL Server Blog Spot on the Web
Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search
Home Blogs Downloads   Opml View as RSS news feed in XML

James Luetkehoelter

Nearly any SQL topic presented at times in a slightly eclectic manner.

An open letter to all 3rd-party vendors: DO NOT USE SA ANYWHERE IN YOUR APPLICATION

I've run into this problem again and again. Sometimes I've had luck in convince clients that if a 3rd-party application is hard-coded to use SA is shouldn't even be considered. Sometimes not. With all of the issues that have come up with the SA account over the last 10 years, I find it inexcusable that vendors still hard-code their application to use SA. Some at least let you pick your password, which you can make absurdly complex and then throw out. Others still go with SA and no password (yes, even under SQL 2005). Far too many vendors for this just to be a James-like rant.

How do we solve this? DEMAND that software be changed. Refuse to purchase software where SA is used at all. Only two weeks ago I saw a dictionary attack against the SA account, and that on a SQL 2005 box behind a firewall (meaning it was an employee in all likelihood doing the hacking). I urge all of you - do NOT LET COMPANIES GET AWAY WITH THESE NIAVE SECURITY PRACTICES!

Who's with me? Or am I just insane (a true possibility)

Published Tuesday, September 23, 2008 8:46 PM by James Luetkehoelter
Filed under: , ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

DonRWatters said:

Great topic...  I was once installing a Certificate/Key server, that used SQL Server as the back-end and it had sa hardcoded as the user.  I figured, okay, this is the Cert folks, they KNOW about security.  There's no way I'm going to even have to get upset, they'll understand the issue and fix it.  Nope.  no dice...I couldn't get them to change it.  I talked to my management, their management, the dev team...nothin.  I flipped, and held out as long as I could, but the project had to move and I was the only thing stopping it (according to everyone else).  I acquiesced and only required more mitigating controls.  This was a long time ago, but it was still something that to this day gets my ire up.

September 23, 2008 10:47 PM
 

Aaron Fischer said:

The question that needs to be ask is why third party vendors use SA.  Solve that, and the issue goes away.

September 23, 2008 10:52 PM
 

Andrea said:

You're surely and definitely right. I'm with you. Software with hard-coded credentials is simply badly conceived. Nothing more to say.

September 24, 2008 2:47 AM
 

Stephen Moore said:

I think it would be helpful to NAME NAMES.  I haven't run into this, but would sure like to know who to avoid.  @Aaron Fischer -- is there any real reason other than lazy vendor?

September 24, 2008 12:22 PM
 

Chris Wood said:

James,

I could not agree more especially with the latest SQL security bugs. We have at least one vendor that must use sa.

Chris

September 24, 2008 12:33 PM
 

James Luetkehoelter said:

Stephen,

I think the problem isn't just laziness, it's often ignorance. MS marketed SQL Server 7.0 when it first came out by saying it was so easy you don't need a DBA. That's when the bulk of this started happening. There's also a train of thought with a lot of developers out there is that "a database is just a database - what's the big deal". Many don't realize the complexity nor how closely any RDBMS works within any operating system.

I'm not going to name names, I don't think this is the appropriate forum for that kind of thing. The real problem is that business still purchase these products. We need real push-back from the business level for it to change, and the knowledge of the issues surrounding using SA comes from us, the SQL Server professionals.

September 24, 2008 12:57 PM
 

jchang said:

If you want to impose mandatory rules, it is absolutely essential to be very precise with wording. Too often I have seen people blindly follow rules without thinking.

so should the title be:

DO NOT USE HARDCODED SA ANYWHERE IN YOUR APPLICATION

or as is?

September 24, 2008 1:35 PM
 

James Luetkehoelter said:

Joe,

I think as is - if I had my way no one would use the built-in SA account, either as an option or having it hard-coded. But you do make a good point - it's one thing for someone to be sloppy and use and an entirely different sin to create an application that is hard-coded to use the SA account.

J.

September 24, 2008 2:41 PM
 

Peter W. DeBetta said:

Please don't use sa and encrypt the password and not obfuscate the .NET code that does the encryption (since it is easily reverse engineered.

September 24, 2008 2:59 PM
 

TiborKaraszi said:

I find sa used all over. Frequently by individuals:

"Do you recall the sa password for server X"?

But also by apps, although it doesn't seem to be *that* frequently nowadays.

My analogy is the Administrators account in Windows. Do you have several persons using this account? Probably not. And not even for services (analogy for an app using "sa").

September 24, 2008 3:09 PM
 

James Luetkehoelter said:

Tibor,

Do you find that it appears people don't realize what SA can end up doing on a system, or a network given the necessary configuration? That seems to be the biggest thing I see when people use it - they don't understand the implication if xp_cmdshell is enabled (which, it will be if you upgraded to 2005 and were using it). Or having a concept of even what their service account for SQL can do? Or the SQL Agent subsystems? Is it ignorance, stupidity or an even mixture?

And why can't we get vendors to abolish the use? No one can justify the use of SA. They're lucky if they can justify a sysadmin, but no way can you justify just SA....

Thoughts?

September 24, 2008 3:33 PM
 

James Luetkehoelter said:

Peter,

Good point - people think that just because they can encrypt it or obfuscate it its ok - people, please, JUST DON'T USE IT PERIOD.

Rant off.

J.

September 24, 2008 3:34 PM
 

Hans Olav Norheim said:

Another interesting question is; on the servers where applications use the sa account, on how many of them is SQL Server running as a local admin on the box? Or worse, domain admin or something equally ridiculous?

The combination unsecure application - sa account - SQL Server as admin, is an interesting one.

September 28, 2008 8:50 AM
 

Steve said:

no one should even know SA password but dba's and it shouldn't be used. specific users should be set up for apps with roles, with only what they need, execute on procs, select on tables they might need, etc. Not only are places using SA, but, then they make users for a DB and just make them dbowner and walk away. yikes

October 3, 2008 3:48 PM
 

Denis Gobo said:

Wow, it has been already a year since I wrote A year in review, The 21 + 1 best blog posts on SQLBlog

December 31, 2008 10:38 AM

Leave a Comment

(required) 
(required) 
Submit

About James Luetkehoelter

I am passionate about what I do - which is DBA, development, IT and IT business consulting. If you don't know me, haven't met me or have never heard me speak, I'm a little on the eccentric side. One attendee recently described me as being "over the top". Yup, that about says it - because I only speak on topics that I'm passionate about.

This Blog

Syndication
©2006-2012 SQLblog.comTM
Brought to you by Adam Machanic & Peter DeBetta
Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement