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."
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...
SQL Server 2000 SP3 supports SSL connections.
This announcment refers to the encryption of columns (which, yes, mySQL has).
That said, Microsoft are correct in stating that the hard part is key management. It's a pain in the arse to make sure everything is kept where it needs to be, and is available for recoveries etc.
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.
Pedro
----
The Insomniac Coder
even now, the sa account is disabled by default and books online states it is there for backwards compatability only.
While it was long over due, SQL Server 2000 already complains quite heavily if you try to set a blank password for sa. It allows it, but there are (unfortunately) applications that have been written with a hard coded connectionstring of sa with a blank password.
No no no, if you're going to quote Spaceballs, at least cite the correct character! :P
:)
Dark Helmet actually said that line in regard to President Skroob. In fact, after hearing the combination, Skroob exclaims that it's the same combination as his luggage. You can tell I've watched it for the umpteenth time
Join the TWIT army now!
Doesnt MySQL do this already? http://dev.mysql.com/doc/mysql/en/SSL_options.html
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.
01100111 01100101 01110100 00100000 01101111 01110101 01110100 00100000 01101101 01101111 01110010 01100101 00101110
Mostly, because Bruce Schneier says it isn't.
sarchasm: The gulf between the author of sarcastic wit and the person who doesn't get it.
I've been involved with using PGP to encrypt data before storing it to a Sql Server db. PGP allows us to ensur the data is secure, even if the database password is compromised. We don't keep the PGP private key on the server, but only the public key used to encrypt the data before storing it (the data is also protected by SSL while in transit and never touches the disk until after it's been encrypted). The customer unlocks the data with the private key after downloading it from the server. It's very secure, but also very hard to work with. For example, we have to leave the db Primary Key (and various other miscellaneous fields) unencrypted to be able to target individual records later (e.g. after a payment gateway returns a transaction status to the server). So it's equally a pain in the butt and lengthens development time. I would like to see some sort of public/private key scheme be integrated into Sql Server. How that would look exactly, I'm unsure.
There's still some minor issues, but unless you're protecting something that multiple, highly technical government spies with uber elite access are trying to get at, PPTP is good enough. Hell, if someone were that determined, I doubt they would choose PPTP as their point of attack. The odds that everything else is more secure are pretty freaking slim.
I disagree that Microsoft can't implement encryption techniques these days. I'm confident that since Microsoft first coded their implementation of PPTP, they've learned to pay more attention to security related features. Back then, vulnerabilities weren't nearly as big of an issue as they are today. Windows Server 2003 is proof that they're making a sincere effort now that the desire for "Secure out of the box" is high on the average customer's list of features. And what about L2TP (Another VPN protocol introduced with Windows 2000)? Know of any weaknesses in it? I can't find any articles with complaints about it and it's been around for several years.
How would you like it if you made a mistake 9 years ago, fixed it, and people still referenced it when arguing why you suck today?
-Lucas
Wow, you certainly haven't kept up with the times. First off, insulting the guys at GPG because they want fair use of THEIR work isn't much of a point; after all, it's not like Microsoft lets anybody in the world use their code under any terms. Second, GPG does provide a highly secure way of encrypting email and documents which is compatible, by and large, with traditional PGP. It's a good system.
Linux has supported encrypted filesystems for some time now; I've been using them for about a year. You can even encrypt your swapspace if you like.
Both MySQL and PostgreSQL can support encryption; it takes extra work, but so does any secure system.
Linux doesn't yet support encrypted binaries, true, but this is probably due to an overall lack-of-need rather than a lack-of-capability; Windows needs signed binaries because it tends to let anybody run software on a system, thanks to security holes. But then again, the source is there, so if you don't like the situation, write a patch. Or pay someone to write a patch. I'll wager that it'd be cheaper than a SQL server license.
Linux does support encrypted authentication; ever heard of 'Kerberos'? It's the same system that Windows 2000 started using a few years back, and Unix has had it for decades. IPsec on linux is a bit of a pain to set up with FreeS/WAN, yes, but 2.6 uses Kame, which is easier, and the Linux implementations have much better debugging features.
Linux does have its faults, don't get me wrong; the FS encryption could be better, and I wouldn't mind seeing encrypted binaries myself. But it's still far better than anything Microsoft has to offer.
Linux
--
I Hit the Karma Cap, and All I Got Was This Lousy
http://www.microsoft.com/technet/prodtechnol/winxp pro/sp2preview.mspx
Enjoy.
Is there an open source email encryption protocol, which is implemented under a license which allows it to be linked in to all kinds of software? No, there's gpg, which is under GPL, which means it can only be used in other GPL software.
You don't have to link to GPG to use it in a mail client. It can operate just fine when you pipe the data to be signed/encrypted to it. As I recall, there's even an Outlook extension that uses GPG.
Do any of the standard Linux filesystems (ext2, ext3, ReiserFS) support encryption? No. There are clunky loopback kludges you can wrap over them, but they have the drawback of being clunky kludge wrappers.
Huh? The idea of encrypting what bits get written to disk is irrelevent to the filesystem, so it makes perfect sense to have encryption at a layer underneath the filesystem.
If you want encryption, it needs to be done at the application layer.
That's clearly untrue as you have just mentioned the loopback method (you may want to update your trolling material; the new method uses LVM and not the loopback device, I believe).
Given that this thread is about databases, how do Postgres and MySQL fare in that department? Can either of them produce PGP-signed database results?
That makes no sense. Under what circumstances would a database have to prove its identity to an application? On the other hand, if we are talking about encryption, which is the topic at hand, PostgreSQL is accessible through OpenSSL.
Can either Postgres or MySQL store data in encrypted formats? No again, unless it is implemented at the application layer.
Once more, you've already mentioned a counterexample to your own claims.
We have OpenSSH which is effective, but somewhat brain-dead in that it provides a tunnel mechanism, but only so long as you keep a console open!
This is completely and utterly untrue. RTFM.
Now let's look at other features in the Linux kernel. It has modes for running signed or encrypted ELF files, right? Wrong! Plain old plain-text should be good enough!
You think ELF is a plaintext format? I find it difficult to imagine somebody more clueless.
Did someone forget support for accessing encrypted files?
The Reiser4 filesystem. The MISC binaries kernel option. The LUFS filesystem. You have at least three ways of accomplishing this.
Ok, but we must be doing better at the authentication level, right? Wrong! You get your choice of plain old passwords, s/key or RSA keys, and that's it. Tokens? We don't need no stinking tokens apparently.
Ever heard of Kerberos?
So let's look at the score.
Hopefully -1, Troll before too long.
BTW, here's a good LDAPv3+SASL+KerberosV HowTo
My god you are a troll. Oh, and as others have pointed out, encryption does not instantly make something secure.
Am I the only one that thinks this is just a method to lock out open source software? Is anybody keeping an eye open at the pattent office site for any new trivial encryption patents?
And Firebird?
e et.html
;)
I must admit it doesn't look like it has encryption (yet?), but it has everything else you mentioned, and it has SPEED.
And, Slashdotters, it's Open Source. So run up the flags for it! Why is everybody, but everybody, talking about MySQL when Firebird is just as free, has a LOT more funtions (the transaction handling is great), and it's FAST.
We use Firebird in a rather serious business environment, and have been very happy with it.
Have a look at http://www.firebirdsql.org/ff/foundation/FBFactsh
Although, I'll admit, encryption? Aaaah, bah, that's just bloat
Free PC version of ChipWits at http://www.breueronline.de/klaus/chipwits/
XPSP2 assuming it ever comes out
MSSQL 2005 security will probably be very good
I think you can understand why longtime Microsoft watchers will be kind of unimpressed by this sort of thing. We've heard it before. Sure, this may be the time (pretty much the first) that MS actually does what it says to the level that reasonable people expect, but positive statements about Microsoft products have historically been in the future tense.
"Windows 3.0 will make the Mac look hard to use."
"Windows 94 will be modern and stable and make the Mac look hard to use."
"Windows 97 will be modern and stable and integrate the Internet, and it will be as easy to use as a Mac."
"NT will be stable and crashless."
"NT 3 will be stable and crashless."
"NT 5 will be stable, secure, and crashless, and will be as easy to use as a Mac."
"XP will be stable, secure, and as easy to use as a Mac."
Every time I hear "but this time, Microsoft will get X right," the consensus after it comes out that Microsoft got X about 50% or not at all, and there are really serious drawbacks.
It's not like Linux ("KDE/Gnome/Eazel's new release will be as easy to use as Windows" or "the new Debian/Red Hat/Mandrake will be as easy to install as Windows") or Apple ("Mac OS X will be a gamer's dream platform" or "Copland will be modern, stable, and crashless, and will actually ship" or "Security update 05-24-2004 fixes the URL vulnerability") are immune, but they do get to point out areas where they excel currently rather than continually point at the next release.
It may be that this time, Microsoft will Get It about security. But you'll forgive the rest of us if we don't get too excited until we actually see the things in operation.
The application tier, in contrast, is much more scalable. Clustering application components is tantamount to creating lots of digital workers. You can punch out a theoretical unlimitted number of workers, but your bottleneck are the resources used as inputs and outputs in your process... the data. You need one computer to hold the "master copy", or authority, of any piece of data.
It's very likely that since SQL Server doesn't run on the mainframe, and isn't easily scaled in most production environments today, that businesses will use this only for very essential requirements, such as social security, credit card numbers and passwords. In its logical progression, some sort of hardware acceleration option will be required to ensure this can be used on a larger scale without impacting the performance of the database server to do its basic tasks.
Open Standards Portal
I'm sorry, but you're an idiot if you expose your SQL server to the web, there's no need that I can think of to do it. Your webserver should be on a seperate box that is exposed to the web, whereas the SQL server should only be visable to internal networks... is this new encryption really necessary?