Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Data Storage Security

MS SQL Server 2005 Adds Security Features 248

Posted by simoniker from the lock-things-up dept.
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."
This discussion has been archived. No new comments can be posted.

MS SQL Server 2005 Adds Security Features More

MS SQL Server 2005 Adds Security Features

Comments Filter:

  • Good Thing (Score:5, Interesting)

    by DarkHelmet ( 120004 ) * <mark AT seventhcycle DOT net> on Wednesday May 26, 2004 @08:05PM (#9263838) Homepage
    In the case of encrypted connections:
    Mysql has this already [mysql.com] In the case of AES Encryption
    Mysql has this already [mysql.com]

    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 (Score:5, Interesting)

      by Anonymous Coward on Wednesday May 26, 2004 @08:16PM (#9263911)
      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.

    • Re:Good Thing (Score:5, Informative)

      by bob_dinosaur ( 544930 ) on Wednesday May 26, 2004 @08:20PM (#9263933)
      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.

    • Re:Good Thing (Score:3, Informative)

      by TracerRX ( 775473 )
      Doesnt MySQL do this already? http://dev.mysql.com/doc/mysql/en/SSL_options.html
    • I believe the concept of building encryption in the database is a good thing. However, it needs to be done through an open standards body. Vendor specific extensions like this reduce the use of the technology for a majority of applications that demand portability, or rely on technology such as JDBC or ODBC to provide portability and open connectivity.

      Until it becomes an open standard, I believe the encryption should continue to be done at the application level where database vendor independence can cont

      • I believe the concept of building encryption in the database is a good thing. However, it needs to be done through an open standards body. Vendor specific extensions like this reduce the use of the technology for a majority of applications that demand portability, or rely on technology such as JDBC or ODBC to provide portability and open connectivity.

        There's also the basic problem that proprietary encryption. Either in concept or implimentation tends not to actually work very well.

  • Microsofts default encryption pass (Score:5, Funny)

    by NightWulf ( 672561 ) on Wednesday May 26, 2004 @08:06PM (#9263843)
    will be 12345. Same as the one on Bill Gates' luggage.
    • "One two three four five!?! That's the stupidest combination I've ever heard!! That's the kind of combination some idiot would have on his luggage!!"

      - President Skroob

      • 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 :)

        • Actually Dark Helmet said it to King of Droidia after hearing the combination to Droidia's Air Shield. Dark then told it to President Skroob later, and Skroob said that it's the same combination than in his luggage.

          So, Dark Helmet said the line before realizing that Skroob's an idiot. It was said in regard of King of Druidia, not President Skroob.

  • Repeat after me.. (Score:4, Insightful)

    by Anonymous Coward on Wednesday May 26, 2004 @08:08PM (#9263858)
    Encryption is not security....
    Encryption is not security....

    Encryption is not security....

    Encryption is not security.... ...
    • "Encryption is not security...."

      And why not? And by that definition, is a password not security either?

    • Re:Repeat after me.. (Score:5, Insightful)

      by John Hurliman ( 152784 ) on Wednesday May 26, 2004 @08:33PM (#9264023) Homepage
      But it does help when you store sensitive customer data on a box you don't own, hosting hundreds of other websites. Many websites have been cracked or user databases stolen from someone setting up an account with the same hosting provider as the target site and gleaning information from the shared database server.
      • 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
        • 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

    • Re:Repeat after ME.. (Score:3, Insightful)

      by Matey-O ( 518004 )
      The unavailability of the option isn't either.

    • thats a foolish statement (Score:5, Informative)

      by mgoodman ( 250332 ) on Wednesday May 26, 2004 @08:47PM (#9264097)
      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.
      • I think one of the worries is lulling you into a false sense of security, which can be worse then no security.

        If someone hacks in and has access to the machine, what stops them waiting around for a moment until someone uses the database, and grabs the password?

        Also I don't understand how this will quite work, but I don't think it will stop sql injection etc.

    • Insightful (Score:2, Insightful)

      by Pan T. Hose ( 707794 )

      Encryption is not security....
      Encryption is not security....

      Encryption is not security....

      Encryption is not security.... ...

      How true...

      (Note to self: remove encryption ASAP!)

  • Its MSFT bashing time... (Score:3, Funny)

    by Anonymous Coward on Wednesday May 26, 2004 @08:11PM (#9263874)
    Go ahead, slashdotters.. they mentioned MSFT!.. .Quick .. get your pitchforks and light the torches!

    • Re:Its MSFT bashing time... (Score:5, Insightful)

      by Canberra Bob ( 763479 ) on Wednesday May 26, 2004 @08:53PM (#9264123) Journal
      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?
      • Foreign keys are un-American.
      • And Firebird?

        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/FBFac
      • After all, who needs foreign keys, views, triggers, procedures etc?

        I need them, which is why I use PostGreSQL.

  • Nice, but... (Score:5, Insightful)

    by seanmcelroy ( 207852 ) on Wednesday May 26, 2004 @08:13PM (#9263886) Homepage Journal
    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.
    • Or an insecure operating system with "secure" middleware, but stray config files that can be read or reconstructed.

      It's that eternal "but I need the system to be able to restart automagically from a crash" versus the "I need to enter the passphrase to bring up our app" conflict. Often, convenience wins over security. Or as they used to say:

      secure, convenient, reliable, pick any two.

    • well i'm sure somethign will pop up and then all the sudden a virus will corect it..

      err I mean with microsofts history, err you know what I mean.. Just one more thing to update every week

  • Am I the only one this bothers? (Score:5, Interesting)

    by mfh ( 56 ) on Wednesday May 26, 2004 @08:14PM (#9263896) Homepage Journal
    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:Am I the only one this bothers? (Score:5, Insightful)

      by whiteranger99x ( 235024 ) on Wednesday May 26, 2004 @08:26PM (#9263979) Journal
      And this is stopping you from using third-party security, how...?
      • 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.

    • Re:Am I the only one this bothers? (Score:5, Insightful)

      by man_ls ( 248470 ) on Wednesday May 26, 2004 @08:28PM (#9263988)
      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.

      • The future's so bright, I avert my eyes (Score:5, Informative)

        by Zoop ( 59907 ) on Thursday May 27, 2004 @06:01AM (#9265231)
        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.
    • 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.

      • Explain (Score:2)

        by mfh ( 56 )
        > 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 ope

        • Re:Explain (Score:2, Interesting)

          by mgoodman ( 250332 )
          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...
    • you can't compare closed source with Open Source. It would be dangerous to.

      Conway's law: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

      Where does security fit within MS SQL's organization chart? How is security evaluated on performance reviews? Who determines the organization's structure?

      With a mix of skills and interests, people generally like to do what they are good at, and people generally are good at w
    • Well you have to understand business. Many don't like buying 3rd Party software for one reason or another. They like to know they have a tightly integrated software solution with 1 company of support. Is this I good thing? I don't think it is. But that is the way it is. So before they had no security now they have some. It is better then none. But you will also have to remember many System Administrators of Large Companies and Government Agencies Have been there a long time (And still are curing the

  • Should have known something was up (Score:3, Insightful)

    by strider3700 ( 109874 ) on Wednesday May 26, 2004 @08:14PM (#9263901)
    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.

  • So then... (Score:4, Funny)

    by gmuslera ( 3436 ) on Wednesday May 26, 2004 @08:15PM (#9263902) Homepage Journal
    future ms sql internet worms will travel encrypted?

  • In Related News... (Score:5, Funny)

    by k4_pacific ( 736911 ) <`moc.oohay' `ta' `cificap_4k'> on Wednesday May 26, 2004 @08:15PM (#9263903) Homepage Journal
    The Acme Safe Co. announced today that next year's model will feature a "lock" to prevent unauthorized persons from accessing the contents.

  • sa/password (Score:5, Informative)

    by djwavelength ( 398555 ) on Wednesday May 26, 2004 @08:17PM (#9263919)
    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...

  • onu! (Score:4, Funny)

    by Triumph The Insult C ( 586706 ) on Wednesday May 26, 2004 @08:18PM (#9263924) Homepage Journal
    v'ir nyernql penpxrq vg!

  • Misleading (Score:5, Informative)

    by pvera ( 250260 ) <pedro.vera@gmail.com> on Wednesday May 26, 2004 @08:20PM (#9263936) Homepage Journal
    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.

    • Re:Misleading (Score:5, Informative)

      by stratjakt ( 596332 ) on Wednesday May 26, 2004 @08:44PM (#9264087) Journal
      Who cares if it sets a default password. Any DBA with a brain changes it, and it's the first thing they do.

      The ones who didnt lost their jobs to india and have nothing to do but post on slashdot about how great mysql's security and encryption model is (actually, does it even have one?)

      A DBA at one of my sites proudly called to tell me I can access the server over the internet. I thought he finally set up a VPN. Nope, a fixed internet IP on the database server. No sa password. Sheesh. He's unemployed, and deservedly so.

      An SSL tunnel on port 1423 (maybe the wrong port I'm tired) has served me well when people dont want plain data being sniffed on the wire.

      Authentication in a 2k+ domain is already more than solid enough for my liking (Kerberos + LDAP = better than any out of the box PAM setup I've ever seen). But oh yeah, microsoft sucks only open source is secure! Mod me up doubleplus groupthink.

    • The encryption method they used to encrypt the password over the network is absolutely laughable. Using a packet sniffer on our network, I managed to grab the password TeleVantage uses to get to its DB. Secure it ain't.

  • sa account (Score:5, Informative)

    by enkafan ( 604078 ) on Wednesday May 26, 2004 @08:21PM (#9263948)
    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.

  • Hope they do a better job (Score:5, Insightful)

    by billstewart ( 78916 ) on Wednesday May 26, 2004 @08:21PM (#9263951) Journal
    Microsoft's past experience with encryption was consistently dreadful - things like PPTP having seven obvious bugs, some of which were password handling and some of which were violations of the one basic rule for RC4 (never encrypt the same stuff twice with the same key.) Hopefully they've gotten better.

    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.

    • Re:Hope they do a better job (Score:4, Informative)

      by Nintendork ( 411169 ) on Wednesday May 26, 2004 @09:04PM (#9264178) Homepage
      Microsoft addressed the major concerns of PPTP in 1998 with a post NT4 SP3 hotfix and DUN 1.3 for Windows 9x. The RC4 key blunder was one of the problems fixed. Check out this informative article [winnetmag.com].

      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

    • 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.

      Dangerously close to spaf:

      "Using encryption on the Internet is the equivalent of arranging an a
    • Why are people still beating a drum over the problems of PPTP? It was superceded *years* ago by L2TP. Are you just trolling, or are your regurgitating the only thing you know/remember?

    • Read The Free Manual

      It's "Read The Fucking Manual". I know you probably know that and are just trying to be politically correct, but I (and I suspect quite a few other people around here as well) actually find it more offensive if you patronize me like that. If you don't like the acronym, just don't use it...

  • This reminds me a lot of the TruStore project [trustore.org] 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.

  • Oh great..... (Score:2, Interesting)

    by eddiegee ( 236525 )
    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.

  • I give it four weeks... (Score:3, Funny)

    by drdreff ( 715277 ) on Wednesday May 26, 2004 @08:40PM (#9264063) Homepage Journal
    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.

  • db encryption == pointless (usually) (Score:5, Insightful)

    by cheezit ( 133765 ) on Wednesday May 26, 2004 @08:58PM (#9264142) Homepage
    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.
    • "...if your biggest threat is an attacker reading the binary db image from disk..."

      Where are your offsite backups stored? Who has access to them? How are they transferred? I know of several companies whose database backups are physically taken to the bank by junior sysadmin staff - what if they were mugged, or their car was stolen while the backups were in transit? If you use an electronic solution to transfer your backups to a datawarehouse facility, who has access to your backup images on disk?

      If someon
    • "Having your db engine do encryption is great...if your biggest threat is an attacker reading the binary db image from disk." Actually, you have a point over there. Previous poster already pointed out, binary db images may also be read from backup tape.

      Then there's Lotus Notes, where binary images of a subset of each database are replicated to the user, allowing for offline database use, for example on a laptop. Of course the local user has admin access to all local data (Which makes sense, I guess; physic

  • ODBC (Score:4, Interesting)

    by Col. Klink (retired) ( 11632 ) on Wednesday May 26, 2004 @08:59PM (#9264147)
    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?

  • How about FIPS ?? (Score:2, Interesting)

    by tuomoks ( 246421 )
    They say "Common Criteria" - is the encryption also FIPS140-2 ????

  • pgp on top of sql server (Score:4, Informative)

    by jdkane ( 588293 ) on Wednesday May 26, 2004 @09:03PM (#9264170)
    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.

  • What's the threat model, and other questions (Score:5, Insightful)

    by BritGeek ( 736361 ) <biz&madzoga,com> on Wednesday May 26, 2004 @09:06PM (#9264184)
    I hate to sound like a harpy about this, but basically we have no idea if this will add any real security at all. "The Devil's in the details"TM.

    The obvious questions are:

    1. 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?
    2. 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".
    3. 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!

  • Embrace.. extend.. (Score:4, Informative)

    by RenHoek ( 101570 ) on Thursday May 27, 2004 @03:02AM (#9264747) Homepage
    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?

  • CPU and scalability (Score:3, Informative)

    by Openstandards.net ( 614258 ) <`ten.sdradnatsnepo' `ta' `todhsals'> on Thursday May 27, 2004 @06:15AM (#9265261) Homepage
    The CPU usage is a major issue here. The database tier is the least scalable tier. CPU bloat in the database can be a become a very difficult problem to solve if your database manages to use up 100% of its CPU usage.

    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.

  • No need for SQL to be exposed to the web (Score:3, Informative)

    by JazzXP ( 770338 ) on Thursday May 27, 2004 @06:31AM (#9265286) Homepage
    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?

  • Customers (Score:3, Insightful)

    by rikkus-x ( 526844 ) <rik@rikkus.info> on Thursday May 27, 2004 @06:33AM (#9265292) Homepage
    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
  • "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?

  • In my experience... (Score:3, Interesting)

    by awol ( 98751 ) on Thursday May 27, 2004 @10:24AM (#9266323) Journal
    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!

  • Open Source has this already (Score:3, Interesting)

    by ajs318 ( 655362 ) <sd_resp2@earthsh ... .co.uk minus bsd> on Thursday May 27, 2004 @11:18AM (#9266873)
    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.

    If you used such a kernel module to give you an encrypted file system, and used that fs type to mount your /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 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.

Slashdot Top Deals

"Experience has proved that some people indeed know everything." -- Russell Baker

Close