MS SQL Server 2005 Adds Security Features

nycsubway writes "Microsoft is planning to add in its own encryption and decryption to its newest version of SQL Server. From the article: 'The company is writing complex encryption and decryption functionality directly into the product so customers don't have to procure security features from a third party, or roll their own when the product becomes generally available next year.' I would also hope the default sa/password will no longer be there."

Comments

Nice, but...

[seanmcelroy]

The problem almost always lies in insecure middleware that connects to the database, not the database itself. Once information is decrypted by an ADO/ADO.NET data provider, if the accessing application is insecure, this won't do you much good. And by far, that's the largest problem.

Re:Good Thing

[Anonymous Coward]

Microsoft is encrypting the data that SQL Server stores so that WHEN someone breaks in to the server they cannot steal the data. Technically the interesting thing is that they have to encrypt the data keys in the indexes as well.

For everyone else, the notable thing is that Microsoft has decided that unencrypted data is not secure on a server running their software.

sa/password

[djwavelength]

SQL Server 2000 allows you to set the level of authentication to Windows Only (uses the Windows Domain security) or Mixed Mode. You have to specify a password for the sa account. You can have a blank password, but this requires an extra check box that says having a blank password is not recommended.

There is no default sa password...

Misleading

[pvera]

SQL Server has not had a default password since SQL Server 7.

In SQL Server 2000 you would have to explicitly request "sa" to have a blank password, there is no way you can do this by accident. It even warns you in the installer that it is not recommended to leave "sa" with a blank password.

BTW, this behavior is present from version 1.0, it is not the result of a service pack or last minute security update.

Re:Misleading

[stratjakt]

Who cares if it sets a default password. Any DBA with a brain changes it, and it's the first thing they do.

The ones who didnt lost their jobs to india and have nothing to do but post on slashdot about how great mysql's security and encryption model is (actually, does it even have one?)

A DBA at one of my sites proudly called to tell me I can access the server over the internet. I thought he finally set up a VPN. Nope, a fixed internet IP on the database server. No sa password. Sheesh. He's unemployed, and deservedly so.

An SSL tunnel on port 1423 (maybe the wrong port I'm tired) has served me well when people dont want plain data being sniffed on the wire.

Authentication in a 2k+ domain is already more than solid enough for my liking (Kerberos + LDAP = better than any out of the box PAM setup I've ever seen). But oh yeah, microsoft sucks only open source is secure! Mod me up doubleplus groupthink.

Re:MS SQL Server 2005 Adds Security Features.

[archen]

That depends. This is talking about data encryption which as far as I know Postgresql doesn't do either. Postgresql does do SSL connection encryption and can use MD5 hashes for passwords, so if your server is secure, and your passwords are as well, then your data should be secure. The thing to be concerned about is "the company is writing complex encryption and decryption functionality directly into the product ". That's great and all, but who exactly is going to vouch for Microsoft correctly implementing this complex encryption? Are we going to have to take MS's word that it's secure because they told us so? Is it going to be possible for non MS (open source) stuff to connect to an MS SQL database with this stuff turned on?

Re:Am I the only one this bothers?

[whiteranger99x]

And this is stopping you from using third-party security, how...?

thats a foolish statement

[mgoodman]

saying encryption is not security is just foolish. any reasonable security administrator realizes that there are different aspects of security -- and encryption is one of them.

security is about defense, in depth, of your data. simply putting out "bug-free" software will help, but it is not the be all and end all of security. there are other layers that your software relies upon that can be compromised.

strong encryption is a good way to *help* secure your data. sure, it is essentially security through obscurity, but even that has a bad rep.

realize this: if someone wants your data, they CAN get it. you might as well make them jump through some hurdles to get to it. hopefully by the time they crack your encryption the data would be useless anyhow.

also, security through obscurity does help ward off casual hackers. i know i certainly dont want to wait 4 weeks for john the ripper to crack some passwords. id just move on to easier targets.

Re:Its MSFT bashing time...

[Canberra Bob]

Dont forget to continuously keep bringing up MySQL. If SQL Server offers something, either reply with "MySQL already has that", or if MySQL does not, then reply with "who needs that anyway? Thats just bloat". After all, who needs foreign keys, views, triggers, procedures etc?

What's the threat model, and other questions

[BritGeek]

I hate to sound like a harpy about this, but basically we have no idea if this will add any real security at all. "The Devil's in the details"TM.

The obvious questions are:

1. Are they trying to protect against a bad guy who has hacked the database server, and has disk level access to that box, but who has no application level credentials to accessing the data via the database?
2. Or, are they trying to protect against a bad guy who has hacked an application server? In which case, said BadGuy presumably has a valid userid/password to retrieve data using boring but powerful queries such as "SELECT * FROM CUST-TABLE".
3. Or, are they doing some nifty code signing thingy so that, unless the query is executed from a previously signed application, the query won't return plain text data.

Of course, there are other interesting questions here. Do they propose to encrypt the data on a row-by-row basis, in which case multi-row operations become exceedingly "interesting"? Do they propose to simply encrypt an entire table? How many keys will there be? Will you be able to rotate keys? If you can rotate keys, what happens to data encrypted under the old keys?

So many questions, so few answers!

Much more than just a patch

[billstewart]

Sorry, but you haven't stopped the smart ass remarks yet :-)

"Security" isn't just something you fix with a bandaid, unlike "Security holes" which can often be fixed that way. Right now if you don't want crackers cracking into your databases, don't let them onto your database server box. SSL is a bit of a step up, because it gives you more granularity about who can do what once they're there, but it's still not the issue here. Storing the *entire* database encrypted with a single key that is known by the object that lets people access data is a bit more than a bandaid -- maybe it's an arm sling, but it's still an external issue.

Real database security is a major redesign - protecting against people who ask nicely is one thing, but designing the database system so that each data item owner's private data is encrypted with their own keys and shared fields are encrypted with shared keys and reading the raw disk instead of using the DBMS interfaces just gets you cyphertext is much more than external patches. Furthermore, it affects the users' interaction with the database, because now they've got to define which items should be visible to which users and manage the keys they use for that access.