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."
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.
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
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.
The dangers of knowledge trigger emotional distress in human beings.
This reminds me a lot of the TruStore project which has been around for about 9 months. They have been working to implement seamless encryption into MS Sql server. I believe they even have betas available.
Natural Selection: self-destruction of the poor and lazy
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.
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.
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.
So let's look at the score. How are we doing? Not so well. The answer seems to be "encrypt at the application layer." I'm not impressed.
I'm sorry if this post sounds like a big troll, and I'm sure it will pick up some troll points here and there, but I'm trying to point out that there are some major gaps in Open Source's encryption picture. In some ways this goes back to the old days of PGP itself, with self-promoter Phil Zimmerman releasing his abysmally bad source code under a not-quite open source license, and then Werner Koch picks up the torch by releasing much better source code but still with naive limitations (no library) and the wrong license.
Someday when I have time I would like to help fix some of these problems.
----------
mobile porn
*gasp* new version includes better features. why is this on slashdot, let alone the front page.
.NET. I assume they are going to use the classes within System.Security to implement this.
To stay on topic, SQL Server 2005 is going to be largely based on
just what I needed is another resource-sucking feature added to SQL server so I can give even more money to server vendors!
But seriously, can anyone guess if on-the-fly encryption will seriously impact a MS SQL 2K box? Do people see an impact on their MySQL boxes? I know it's not a very valid comparsion but I'm just trying to get an idea for future server scaling.
so long as the option still exists to use third party security products, i think its a good move. other databases have it, why shouldnt they?
and i seriously doubt microsoft would be able to figure out how to make it so that no third party encryption works with their database, nor would they want to, as their primary agenda right now is clearly security.
01100111 01100101 01110100 00100000 01101111 01110101 01110100 00100000 01101101 01101111 01110010 01100101 00101110
Does this mean that the unix Sybase/FreeTDS ODBC drivers under Unix will no longer be able to connect to MS SQL? Will MS offer any unix/linux ODBC drivers?
-- Don't Tase me, bro!
They say "Common Criteria" - is the encryption also FIPS140-2 ????
Error 408 - Request Timeout
Your transaction was canceled waiting for the server operator to enter the database password. Please try again when the operator is back from lunch.
It does not really matter if the data is encrypted or not. Whatever agent is accessing the data has the password, and if it is compromised, the data is also compromised. Add to that, the encryption credentials must be stored somewhere, in which case it is vulnerable, or entered manually by an operator, in which case rebooting your webserver just got that much more entertaining.
-Hope
That is certainly a valid point. It would be nice if they could license something from RSA...
Come to think about it, how are they going to get around the law prohibiting the export of encryption out of the states? I suppose they'll need to ship a copy without encryption to overseas customers. In which case, international corporations may have compatibility issues...
01100111 01100101 01110100 00100000 01101111 01110101 01110100 00100000 01101101 01101111 01110010 01100101 00101110
because of US law prohibiting the export of encryption over 48-bit (48-bit, right?), how good will MS encryption be in SQL server? Anyone know any specs?
If its only 48-bit encryption with a crappy algorithm...well we've seen how easy WEP and WPA are to crack, for example.
Perhaps they are going to put out an international version with no encryption or inferior encryption?
im just crossing my fingers and hoping they dont dumb down the encryption for overseas export...then again, stupid people and security vulnerabilities keep me in business...microsoft rocks! no wait. sorry. freebsd it is.
01100111 01100101 01110100 00100000 01101111 01110101 01110100 00100000 01101101 01101111 01110010 01100101 00101110
I do believe this should be developed through an open standards body, though, at least if applications are to have any control over the process. If Microsoft implements it in the backend, so it's transparent to applications, then perhaps it's not a real issue, since there would be no application API.
Due to the demand for this, and the issues that need to be resolved, such as ways of managing performance and having plugable secrutiy options, I'd like to see an open standard developed that the database vendors could implement together.
Open Standards Portal
... doesn't mean we shouldn't.
"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..."
Kudos to Microsoft for working to secure their products at a lower level. Their "new" strategy is certainly better than their previous habit of releasing swiss cheese and then issuing corks (once a month) to plug the holes. However, their track record in the security arena gives one a reason to consider spending the extra $$ with a proven provider of security products when the situation depends upon it. Even if Microsoft's built-in functionality is stellar, the concept of Defense-in-Depth tells us that we may still need to "...procure security features from a third party..."
In the words of [my hero] Bruce Schneier: "Strong cryptography is very powerful when it is done right, but it is not a panacea. Focusing on the cryptographic algorithms while ignoring other aspects of security is like defending your house not by building a fence around it, but by putting an immense stake into the ground and hoping that the adversary runs right into it."
I am struggling to see the benefit of this level of encryption.
If you are going to deploy the encrypted data into an untrusted location then you have a huge problem. If the data needs to be there in the first place then it must be unencrypted in order to be acted upon and then it is vulnerable anyway.
If you are going to deploy the encrypted data to a trudted location via an untrusted channel then a better solution is to encrypt the channel.
If you are going to store data from third parties in a central location and encrypt it to prevent unauthorised access then just let the third party submit encrypted data, however the RDBMS cannot use its RDBness on the data since it is encrypted.
If you are going to store third party data and act upon it then you have to decrpyt it, therefor have the keys, therefore the database itself is trusted, therefore just use access control rather than encryption. Encryption is 100% overhead.
I think this kind of proposal is 100% buzword compliance with no benefit whatsoever. The occasion where we encrypted rows in a table, we found the performance of the system was slaughtered and we were completely memory resident and used caching to ensure that we minimised the encryptions during a given transaction. Secondly we found that in the circumstances where we had some sensitive data that was needed on the client side to do calculations that are expensive, we had to reveal some aspect of the data in order to make it work and I am sure this will be true in any case. If you need to use the data, you need to decrypt it. We even thought about building an API that would implement a bunch of accessors that would return results based on the hidden data, but it was then that we had to reveal the common attributes of individual instances of the data. So instead we had to do it in the trusted environment.
What do all these experiences show? That if the client isn't trusted then there is no point encrypting. Which perhaps reveals Microsofts motive... to provide another lockout for those who do not subscribe to their trusted computing initiative!
"The first thing to do when you find yourself in a hole is stop digging."
The concept of "abstraction layers" is associated with Windows, but don't forget, non-toy operating systems also have their own forms of abstraction layer, just as a result of their own modularity. For instance, in Linux, the entire file system is effectively abstracted. You can write a kernel module for a new file system type and drop it in seamlessly. The same probably holds true for other OSes, maybe even in Windows if you can get the sources; but I'll concentrate on Linux for now because it's what I know.
/var partition, then you would have encryption for your database -- independent of whatever kind of database you were using. And it's stuff-all use to anyone who steals the drive (unless the decryption key is on the same drive; but it's not, is it. You're smarter than that).
If you used such a kernel module to give you an encrypted file system, and used that fs type to mount your
If you want encryption between client and server, you can use OpenSSL. Of course, if you are accessing the database through a web-based app, then just use an SSL-aware version of Apache. It'll be unencrypted on the client-end PC, but presumably that's inside a locked office building.
Je fume. Tu fumes. Nous fûmes!