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
will be 12345. Same as the one on Bill Gates' luggage.
SQL Server 2005 Adds Security Features.
..
What you mean that it doesnt have them already?
Man that frightening we have to wait till 2005 to get security features. Microsoft must be so out of date! Why not look at MySQL or postgres ?
nick
Electronic Music Made Using Linux http://soundcloud.com/polyp
Encryption is not security....
...
Encryption is not security....
Encryption is not security....
Encryption is not security....
Go ahead, slashdotters.. they mentioned MSFT!.. .Quick .. get your pitchforks and light the torches!
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 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.
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.
future ms sql internet worms will travel encrypted?
The Acme Safe Co. announced today that next year's model will feature a "lock" to prevent unauthorized persons from accessing the contents.
Unknown host pong.
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...
No doubt Microsoft have spunked a huge wad of cash and R&D time creating the next-generation soloution in Microsoft software data encryption algorithms.....
"Microsoft ROT26"! (c)
She's built like a steak house, but she handles like a bistro....
v'ir nyernql penpxrq vg!
vodka, straight up, thank you!
In a microsoft product? Blasphemy!
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.
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
Is there any alternative for a failover RDBMS?
Thanks, Captain Obvious! We really don't know what we would do without you.
Brian Seppanen
Minister of Information and Propaganda
Area 54 The Secret Government Disco Labs Provo
That Microsoft crack was quite innovative. Quick, patent it before I use it on the next story.
maybe they'll store the salts in a file hashed with ntlm v1 or something :P
01100111 01100101 01110100 00100000 01101111 01110101 01110100 00100000 01101101 01101111 01110010 01100101 00101110
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.
That's the patch cycle now right? once a month? Either the IIS plugin or some "bugfix" will contain a flaw that exposes the private key to anyone with a .net passport.
As seen on Wired: Get a free desktop PC
My initial reaction was to spit Bud Light all over my new 19" flat panel display!
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
...so customers don't have to procure security features from a third party
*yawn*
Microsoft is writing code that makes third party developers redundant.
Nothing to see here, move along.
HAHAHAHAHAHAHAHAHAHAHAHAHA Microsoft.....security..... HAHAHAHAHAHAHAHAHAHAHAHAHAHA ....pants.....wet......
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
Since a cut down version of this is supposed to be running WinFS right ?
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
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?
A completely baseless generalization!
Gentoo, Gnome, Debian, GNU, Savannah, and more have all been hacked in the past six months. But lets bash M$ because OSS is always superior!
It's a fucking religion with you guys.
'Exclusive code leaked.. from Micro$oft...
DECLARE FUNCTION Encrypt$ (Text$, PW$)
PW$ = "Bill Gates"
S$ = "This is the new SQL Server Encryption"
PRINT ">"; Encryption$(S$, PW$); "<"
PRINT ">"; Encryption$(Encryption$(S$, PW$)); "<"
' Fully Secured Encryption/Decryption Algorithm
FUNCTION Encryption$ (Text$, PW$)
PW$ = "Bill Gates Rules"
E$ = Text$
PWLen% = LEN(PW$) - 1
FOR i% = 1 TO LEN(Text$)
TextIndex$ = MID$(Text$, i%, 1)
PWIndex$ = MID$(PW$, (i% MOD PWLen%) + 1, 1)
T$ = CHR$(ASC(TextIndex$) XOR ASC(PWIndex$))
MID$(E$, i%, 1) = T$
NEXT i%
Encryption$ = E$
END FUNCTION
+1 Funny.
He's threatening our hegemony!
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
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 ????
Finally!
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
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.
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
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."
as I can't use third party air bags in my car.
.....
Well I suppose I could replace them with better ones that wouldn't burn me, but hell they came with the car and
On the other hand pro-drivers will replace there air bags.
thank God the internet isn't a human right.
After all, who needs foreign keys, views, triggers, procedures etc?
Uhm. Some people do and some people don't. It really depends on what you are trying to do with your DBMS.
Seriously though...
"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."
Does that really mean thay had no crypto? Hard to believe. Could someone please confirm it? I have never used MS SQL Server before.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
> 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.
The point I was making is that many companies will believe that the MS encryption is all they need, and that will likely leave many systems open for attack, when the next round of security holes are uncovered.
That, and the point that you can't apply the same logic for closed source and open source systems -- it's suicide.
The dangers of knowledge trigger emotional distress in human beings.
It's not a bug, it's a feature!
A much harder thing to demonstrate is showing that there isn't either a big gaping hole or a subtle nasty hole that lets somebody get in when they should have been rejected. There's also the problem of building a model for authorization that's featureful enough to be useful but not too complicated to use - a demo can easily hide either of those problems.
There has been lots of secure database research over the years - the NCSC's Lavender book, for instance, and lots of work Oracle's done. Hopefully they've taken advantage of the useful parts of it.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
"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.
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
These new features solve a whole range of problems relating to data security as per new legislation/regulation. I work in Health Care in Canada and we must comply with certain criteria for handling certain types of data. One of the things we need is row level encryption... These features are more about meeting legislative requirements than enhancing overall system security. There is a disconnect between those making the regulations and the reality of implementation...
SQLServer2005 will always enforce SSL connections and the en/decryption is going to follow the WS-Security spec. Why?
.NET way (and perhaps trying to remove the need for JDBC and similar dbc middleware).
Because it will be able to be accessed like a web service. XML request wraps SQL and an XML response with the resulting row set is returned. That response is what will be locked down. In a sense, they are relying on XML to/from object (de)serialisation for the O/R mapping particularly when using the
Microsoft are also trying to hammer into deployers not to put this in full view of the Internet for obvious reasons.
Is it really even conceivable that people outside of the US haven't gotten strong encryption by now? I mean, you can download implementations off the internet already, and even read papers about various algorithms. Really, what's the point of bothering to prohibit it?
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
How are we supposed to use this thing then? :)
Free as in mason.
Let's spell it "O$$" because all open source programmers are POOR and those comical dollar signs are the closest they'll ever get to a paycheck!
1. who has the flash plug-in installed?
2. who doesn't block ads?
this probably rules out most of the people (such as myself) that would not be persuaded by an add like this. for the rest, they probably aren't expecting them to see the light in an instant. it's like the car commercials you see every night if you watch tv. they know you don't buy cars every day, and that their commercials won't convince you to run out and buy the particular model they're selling. the important thing to them is to keep their image in the back of your mind somewhere. with the car commercials, you'll come to associate their image with unwinding in front of the tube. with the microsoft ads, you'll come to associate their image with wasting time at work reading slashdot.
i have another theory. maybe they're not trying to sell you microsoft stuff. maybe they hope to catch the eye of your boss as she walks by your desk to find out why you're wasting time at work reading slashdot.
nack...
I don't use Gentoo, Gnome, or Debian. I use as little GNU software as possible (that means I use the buildchain, but only because I don't have a good alternative right now). OpenBSD and NetBSD are superior. That's why I use them...
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?
Everyone will get hacked, be it MS or Debian.
BTW, Debian was hacked due to a local exploit and a sniffed password. MS was probably cracked remotely, unless you can actually log into their web servers remotely :)
So there. MS is insecure, Debian is insecure, OpenBSD is insecure (see CVS holes), OSX is insecure, etc...... Yeap, most software is crap. That's why Linux has things like grsecurity.net, second line of defence. I don't know such things even exist for MS OS.
"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
Anyway, at least the backdoor password will still be intact:
-- @rjamestaylor on Ello
PLEASE MOD PARENT DOWN
Come on, how is parent insightful?
If there is a discussion about some features mysql doesn't have and someone responds with 'it is useless' then parent does apply (but is not insightful either, just right).
In this case mysql has this feauture while msssql hasn't. That can be pointed out, what is the problem with that?
But this reversed psychology sucks big time. Should I reply in every discussion with something like: 'You bring up a good argument. But I suspect you will bring up this argument reversed as it does not apply, so your post is wrong??'.
Foreign keys are un-American.
So fucking what? HELLO MORON, countries outside American DO exist
Foreign keys are un-American
No they arent, they are just not British
Old COBOL programmers never die. They just code in C.
1. Uninstall
2. Stop
3. Disable Start on Boot
There must be a fine line between a troll and a comedian.
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
Personally Im a Postgres fan. No, my original post was not to bash MySQL because I prefer an alternative, but since you brought up the subject of alternatives... :)
:)
There are quite a number of FOSS databases which offer far more than MySQL (eg Postgres, and aparently Firebird), yet MySQL seems to be pushed by the community as its premier RDBMS. Why? Yes, it is fast. But that speed appears to come at the expense of functionality. It allows date inserts of values such as 2004-15-68!! No errors, nothing! Yes, its fast because it checks pretty much nothing. With no foreign keys, no data checking, it does pretty much nothing to ensure data integrity.
Thanks for the info, will be looking into it shortly
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?
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
You'll simply use your Microsoft Passport to access the database. All SQL Server will have to do is ask you if you are the SA or not.
For added security, it will also ask you if you really are the SA.
Its not whether you do or don't. Its about whether you might. Its about making sensible choices to allow a project to expand, evolve and develop as specifications change. Selecting limited and restricted development tools and platforms is just not good practice.
I need them, which is why I use PostGreSQL.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
sa/password, come on. The security stuff being bundled helps all of us out. Having used Oracle for the last 15 years and doing countless installs, if your careless enough to leave Scott/tiger or system/manager or sysdba/change_on_install, you deserve to be hacked.
If the enc/dec functionality is really "complex"
then it's burned already. Security features need
to be SIMPLE, otherwise they do no good...
So Microsoft makes the database encrypted. But you say that if a third-party app. that can access the database is compromised the database is wide-open. Enter trusted computing: You can't hijack the third-party app. since the hardware won't allow it so the database remains secure. Am I missing something?
Their previous attempts at encryption were usually bad. PPTP had a few major problems (related to the handling of passwords and inconsistent applications of a basic rule at Microsoft when using RC4: Don't encrypt the same thing with the same key more than once!).
Algorithms that do encryption are difficult to design properly. However, if you have a good algorithm and know the proper conditions under which you should use it, almost anyone's code will do. Most people understand the need to use code that's been tested by universities, and not just some untested and unverified garbage written over the weekend. Packaging and writing protocols for the encryption algorithms is often as difficult as writing the code that's encapsulated within. Microsoft database programs are very popular, and that's the kind of thing that they excel at.
The problem is more difficult than the credit card/SSL stuff, which is all about letting someone with a browser input some numbers on an unsecure Windows machine connected to the Internet, then packing them in an encrypted package, and shipping them to a well-publicized (but poorly protected) server. Validation is done optionally at either end, which amounts to having NetSol report back on whether or not they are who they say they are. That problem has been solved, but it was some time before all of the design issues and other bugs were worked out. Which is some indication of how the solutions to the remaining database security issues will be solved.
I guess BillG found out no one owns ROT-13.
This looks neat, but I'll need to know more about it before I can judge. At the minimum, I want the ability to substitute in new algorithms as old ones are broken and new ones are developed.
"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"
I'll tell you why. Because MySQL is the MS Acess of Open Source. That and MySQL is easier to say than Postgres for fanboys. Fanboys also prefer PHP and really love to team the two and call product myphp_shit. Perl is so much better than php it's not even funny.
"Complex" is exactly the wrong way to describe any security feature. If the feature is really "complex" how do they expect it to be used correctly?
(Answer to my own hypothetical question: They don't expect people to use it correctly. MS is not in the business of making correct software, they're in the business of making money. To make (more) money, they must (claim they) have security features.)
Ok, MS bashing aside, MSSQL is a fantastic product, light-years ahead of MYSQL, PostgreSQL and even Interbase (All of which I use and love). That being said, from a software developer's perspective, this is a good step forward. The cost to performance ratio of MSSQL is fantastic and the ease of use is unparalleled. Say what you want about Microsoft, but if it weren't for them Database programming would really suck. It really is their best product.
My mother never saw the irony in calling me a son-of-a-bitch.
Rizzo said. "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."
;)
For most databases it is easier to exploit a users badly formed SQL/PHP etc to get the data out as plain text. It's nice of Microsoft to admit that most MS SQL servers are running on windows, and that Windows is more insecure than some random guy's SQL/PHP code.
And most definitely do not forget SQL Server 2000 user-defined functions, which allows you to call stored procedures as inline functions in database queries. You really don't need those!
It does mean that if StupidWebForum.cgi is compromised, and the data it stores in the database is compromised, the data columns that SecurePayrollApp use are still encrypted.
In other words, yes, if you break an app, you get _it's_ data, but you don't get any data that other apps might have in the database. That's a significant win if you have a few applications, with only a small shared data set between them, as now sloppy code elsewhere _isn't_ your problem.
'Course, if you've got everything in one table, then your still screwed, but roll on thrid cannonical form, and fine grained encryption.
"I would also hope the default sa/password will no longer be there."
That was MSDE not SQL Server.
Can we mod the story submitter -5 troll?
... 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."
Having worked with perl and php for multiple years. I belive perl isn't the right tool for 90% of work most web application developers do. I tipically only get out perl for complex text manipulation. For everything else, I tend to stick with php.
Although I perfer to use Postgres, but a lot of my clients only want mysql.
They may exist but they don't matter.
Somehow, the inference from the title is that SQL hasn't been adding security features until now. As a long term MCDBA let me be the latest to pile-on and call bullshit - SQL has been adding and improving security with every version, every service pack, and every hotfix - and, generally speaking from a production standpoint, steadily and sanely. /. - never missing an opportunity (or the chance to manufacture an opportunity) to lampoon MS.
http://www.microsoft.com/technet/prodtechnol/winxp pro/default.mspx
Ohana means family. Family means nobody gets left behind or forgotten.
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!
... just not in the "stable" release
- Disclaimer: Information in this post deemed reliable but not guaranteed.
I would also hope the default sa/password will no longer be there.
I don't know what versions you're installing, but SQL server setup has always asked me for a sa password.
Not All Who Wander Are Lost
You know, the way the headline is written, it makes it sound like MS SQL Server never had security features before.
Oh, yeah. Waitaminute. Nevermind.
blog |
For some reason it's always "news" when Microsoft brings out something that other systems had a few years ago already. I don't know any other company that can consistently get that much press coverage for introducing features that in some cases are five to ten years old. Hell, it's even news when Microsoft just announces that in two years time they're going to introduce a feature that is already at least a few years old (e.g. months ago already we had the "news" that IE would get popup blocking when Longhorn is released in around 2006 or so). This is the way it's always been - "Windows gets 'skins'", "Windows gets 32-bit multitasking", "Windows gets memory protection", "Windows gets 32-bit icons", "Windows gets a firewall", "Windows gets recycle bin (Mac trash can)", "Windows gets Internet Connection Sharing (IPMasq)" - always made news. Yet it seems most people really don't mind sticking with MS and waiting a few years longer than others for stuff.
I fully agree with you, if there is free software available that already does X, why not bring it up? Now you bring it up and you get bashed for "Microsoft-bashing".
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.
'cause we're still bitter about having to change the name of our web browser.