April 20, 2010 at 6:15 pm
Paul White NZ (4/19/2010)
Matt Miller (#4) (4/19/2010)
3rd party. Built-in means SQL knows how to decrypt it, so it ain't much of an encryption.Not sure what you mean here, Matt. Are you suggesting that some component of SQL Server is always able to decrypt anything encrypted using one of the built-in functions? :unsure:
Besides - you get better access to stronger algorithms.
SQL Server provides a range of algorithms that are suitable for most purposes, AES-256 for example. Private keys can be up to 2048 bits. An external provider can be used via EKM.
Not necessarily, but it can be rather easy to essentially make your encryption worthless using the built-in components. In most cases, things like TDE get confused for actual encryption. In addition, unless implemented exactly correctly, you end up with service-types accounts which get to encrypt/decrypt at will, making the data essentially unencrypted to anyone with elevated permissions within SQL Server.
I wouldn't secure credit card info with something as short as 256. Most clearinghouses for financial data are starting to say that 1024 isn't long enough any more.
3rd party however can easily be implemented to essentially require 2 functions/2 separate people to be able to decrypt data (since SQL Server itself will never be able to decrypt the data, and the app itself doing the decryption need not have any form of access to the data after it's been encrypted.. Also - third party apps can easily be extended or can natively use asymmetric keys in excess of 4K (PGP is my personal favorite, but there are several professional-grade RSA solutions from the open Source community that would work well (such as truCrypt, GnuPG, OpenPGP).
You may be better off subscribing to having your payment service hold onto them for you. A lot of those service actually have a service who do that, and frankly if you're using a reputable service, they should be better at securing these things than you are (they have more service).
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
April 20, 2010 at 6:21 pm
Matt Miller (#4) (4/20/2010)
Not necessarily, but it can be rather easy to essentially make your encryption worthless using the built-in components. In most cases, things like TDE get confused for actual encryption. In addition, unless implemented exactly correctly, you end up with service-types accounts which get to encrypt/decrypt at will, making the data essentially unencrypted to anyone with elevated permissions within SQL Server.
Right, I see - you were talking about TDE or poor implementations. I get it.
I have used SQL Server (2005)'s built-in encryption to pass PCI-DSS. 2008 adds lots of extra capability, and I have nothing against using external encryption either - just sticking up for SQL a bit.
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply