Slashdot Mirror
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."
Encryption is not security....
...
Encryption is not security....
Encryption is not security....
Encryption is not security....
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.
Be very, very careful what you put into that head, because you will never, ever get it out. -Thomas Cardinal Wolsey
I don't have to work in SQL very often so in those times that I do I reply quite heavily on the MSDN API listings of the T-SQL commands. I'm mostly just looking for the syntax and maybe a couple of examples since I'm not doing anything difficult here.
Today I went to look up something and have found that the MSDN has turned into a giant advertisement for SQL server 2005 and if the useful information is still there it's buried.
It's really sad that today I looked up some syntax on the mySQL site and prayed it was the same on MSSQL.
I can completely understand why my customers don't like it when we change the layout of screens now.
Encryption algorithms are hard to design well, but if you've got a good algorithm and understand the conditions for using it, you can use almost anybody's code for it, and most people these days understand that you need to use academically vetted stuff and not just roll your own snake oil. But encryption protocols and other forms of packaging for algorithms can be just as hard, and something as pervasive as Microsoft database programs will be very widely used by people who don't Read The Free Manual, which means that even if they design it very very well there'll still be people who use it for things it wasn't designed to do securely, because they're trying to do a much broader range of things.
This is a harder problem than basic SSL-for-Credit-Card-Numbers, which is trying to let the client enter some bits on an unprotected Windows box hanging off the Internet, pack them in an armored box, and ship them to a usually-almost-as-badly-protected server on a well-advertised Internet connection, and optionally do some validation on whether one or both ends are really the machines Verisign thinks they are. That's a pretty well-solved problem, though it took a while to iron out the design issues early on an iron out all the bugs in the code, but general-purpose solutions to "database security" are pretty hard.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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?
And this is stopping you from using third-party security, how...?
Join the TWIT army now!
I think this is a good thing.
Since Windows XP, Microsoft has done almost a 180 (well...maybe like a 135........but still) in terms of security. They've put extensive security-related features into XPSP2 assuming it ever comes out, their newest server is locked down as tight as anything can be out of the box (although enabling stuff isn't difficult, it's not online by default) and they generally use standards-based encryption.
I think that MSSQL 2005 security will probably be very good. Or at least, *good enough* The government probably can read everything anyways -- but the point is, if Joe Hacker (or Jaing Hackerong) can't read it without expenditure of time and money beyond anything he would have access to, then the mission is accomplsihed.
The whole point of cryptography is not to keep people from reading what you're saying. It's to raise the cost of figuring it out so high that it's not worth it to most people to break.
So, if the default password is stoopid, (or even if it's smart), you should change it right away!!, duh! Otherwise, you're just asking to be bent over the barrel.
I remember when I first installed WinNT on a computer, (shudder - glad I won't be doing that again). First thing I did was change the administrator account to another name and disabled the 'guest' account. Same thing with that stupid '1234' default password on my RT314 router from Netgear - changed it immediately. Even if the default password was 'X87z2gh9', why would you not change it?
I mean, c'mon. It's called taking a little responsibility for yourself.
"A revolution without dancing is... a revolution not worth having"
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?
Having your db engine do encryption is great...if your biggest threat is an attacker reading the binary db image from disk. Much more likely threats to data are associated with compromised accounts, and this won't help you then.
If your web app needs to read credit cards out of the database, the account it runs under sees them in the clear, even if your db did super fancy encryption. If you don't want other users to see that data...GIVE THEM SEPARATE ACCOUNTS AND USE ACLS!!!!! Db encryption sounds good but is pointless in most scenarios.
Premature optimization is the root of all evil
The obvious questions are:
- 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?
- 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".
- 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!
"The time is always now" - Victor
How true...
(Note to self: remove encryption ASAP!)
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
"So imagine the scenario where you want to have your data encrypted so that just in case someone breaks in, they can't pull the data out."
First off, this is total BS and would way too much burden on the Database server. So much for making Sql Server faster and more scalable. The minute you start encrypting the data, the database is going to slow down tremendously. The only way I know of to maintain the same performance as without encryption is to use some sort of hardware accelerator.
I can't help but feel this encryption thing is a poor excuse for bad flaws in windows and sql server security. If the OS was secure and the people managing the systems are deligent about security, you wouldn't need to encrypt the data.
yes, but what is so annoying about his post is that it got modded up to +4 interesting and none of the rebuttals got modded up at all. This means that most people cruising at +3 or above won't see the replies.
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
"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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
...and claiming that strong encryption is mostly "security through obscurity" is?..
2nd, if someone really wants my data, he'll get it, but maybe by using a keylogger to sniff my passphrase, via some legal procedure or what-not, certainly not by breaking strong crypto directly.
I agree with the original poster, encryption doesn't necessarily imply security; it can be used in very stupid ways indeed (remember MS' proprietary VPN, where each end was using the same RC4 keystream? yuk!), not to mention programming errors potentially openning holes bigger than what encryption was supposed to protect...
One point I haven't seen raised yet is that this is very useful where you send your app out to customers with MSDE (cut-down SQL Server) and a ready-to-use database in the bundle.
Having the whole thing encrypted stops competitors taking your 'business logic' (in your stored procedures) home for bedtime reading. If you keep some stuff unavailable until they buy licenses for it, you can stop them seeing how to 'switch it on' , too.
Rik