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

Good Thing

[DarkHelmet]

In the case of encrypted connections:
Mysql has this already In the case of AES Encryption
Mysql has this already

But in the case of having something asymmetric, something like this would be *incredibly* nice. I'd looove for a free software package to integrate something like OpenSSL in, so that I could encode a column using a certificate variable.

Still, Microsoft is doing a good thing overall.

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.

Am I the only one this bothers?

[mfh]

I think it bothers me that MS SQL will have its own security, because I think that third party security, at least in the case of Microsoft products, dramatically increases the overall security. It never pays to have a false sense of security, and with all Microsoft products, we must beware of their security strategy. At least with getting more people involved with third party security, you get a new perspective on things. MySQL is open source so it has this added perspective by default.

I guess what I'm saying is that you can't compare closed source with Open Source. It would be dangerous to.

Re:MS is ahead of Open Source on encryption

[pc486]

I don't know much about databases, VPNs, encrypted filesytems and such, but this post is plain blither.

The Open Source movement loves to talk about encryption and security, but it's all talk. 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. Anyway, the author, Werner Koch, is so confused about security that he thinks that making it as a linkable library would somehow compromise security. D'ohh! 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. If you want encryption, it needs to be done at the application layer. 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? No (that gpg again). Can either Postgres or MySQL store data in encrypted formats? No again, unless it is implemented at the application layer.

1. Loopbacks can be "clunky" but they allow seperation of the encryption and the filesystem. I don't care about encrypting my discs, but that doesn't make it so encryption is unavailable for others to use. Plus, there is no way a new encrypted filesystem should get into the main Linux trunk any time soon. Why? Filesystems are critical to system stability. If the filesystem gets corrupted, the system is gone. Any new filesystem, encrypted or not, should have much testing done before it gets including in the main trunk.

2. MySQL support AES for table encryption and SSL for link encryption. This is far more than good enough for a database, considering that encryption isn't security (google for SQL insertion attacks). Besides, table data signing should belong at the application layer.

Ok, how about encryption on the network? Here we have some things to look up to. We have OpenSSL which is perfectly integrated into the Apache 2 server and a bunch of other places. That's good. 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! D'ohh! Mercifully, Linux does have good ipsec support for tunneling.

OpenSSL is BSD, so your previous GPL argument goes out the window. It serves us well. Also, SSH for tunneling should be used for just that. There are many ways to make this work (look at the -N option) and there are a few applications where it is stupid or overkill to use SSH for tunneling. Use Stunnel instead (a generic SSL wrapper for TCP applications). Use the right tool for the job, silly.

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! Did someone forget support for accessing encrypted files? Guess so.

Accessing encrypted files is at the filesystem layer (which we already visited). Encrypted executables make no sense. Signed ones do, though, and that seems like a cool feature. I do not know if Linux can do executable signing at runtime or not.

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.

Last I checked, Linux has support for many authentication models. I believe the authentication application is called Pluggable Authentication Modules (PAM).