I need to store sensitive data in SQL server and need this encrypting. This ideally needs encryping and descrypting within SQL server and not in the code of the application(s). The reason being, the application to add the data to the database will be written by someone else in ASP and I will be pulling out this data and using this within my application which is written in PHP and will therefore need this decryping.
MySQL has a nice little function AES_ENCRYPT but I cannot find anythign similar for MSSQL and I am very unfamiliar with MSSQL, so any help would be much appreciated.
Summary: With the introduction of transparent data encryption (TDE) in
SQL Server 2008, users now have the choice between cell-level
encryption as in SQL Server 2005, full database-level encryption by
using TDE, or the file-level encryption options provided by Windows.
TDE is the optimal choice for bulk encryption to meet regulatory
compliance or corporate data security standards. TDE works at the file
level, which is similar to two Windows® features: the Encrypting File
System (EFS) and BitLocker™ Drive Encryption, the new volume-level
encryption introduced in Windows Vista®, both of which also encrypt
data on the hard drive. TDE does not replace cell-level encryption,
EFS, or BitLocker. This white paper compares TDE with these other
encryption methods for application developers and database
administrators. While this is not a technical, in-depth review of TDE,
technical implementations are explored and a familiarity with concepts
such as virtual log files and the buffer pool are assumed. The user is
assumed to be familiar with cell-level encryption and cryptography in
general. Implementing database encryption is covered, but not the
rationale for encrypting a database.
Reference
Security has become extremely important in today’s fiercely completive
business environment. Industry standards require you to implement firm
techniques to secure your data. In SQL Server 2005, security has
improved for authentication, authorization, and encryption. Encryption
is so much improved that it is almost a new feature in SQL Server
2005.
Encryption is the last barrier against a hacker. Technically,
authentication and authorization methods should be strong enough to
stop hackers before they can view data. But if they do get through,
the last trump card for system designers is data encryption. You will
not encrypt you all of your data, only very important data like
passwords, credit card number, etc.
In the days of SQL Server 2000, you had two options: find third party
tools to handle data encryption, if available, or use the built-in
encryption, which was very limited. and this might help
Reference
I've stumbled upon a great read on SQL Server Cryptographic features. It describes utilizing Transparent Data Encryption (TDE), Encrypted backup feature (introduced in SQL Server 2014), Symmetric and Asymmetric encryption, and Hashing.
All these features differ in implementation, and I strongly suggest reading this article to find out what solution is the best for your needs: http://www.sqlshack.com/sql-server-confidential-part-ii-sql-server-cryptographic-features/
Related
How can I create an encrypted SQLite database that actually stays encrypted or that I can open afterwards.
I used SQLite2009 Pro Enterprise Manager that "can" create encrypted databases, but after typing in the encryption key they are no longer openable.
I used SQLiteManager from SQLabs to create an encrypted database and while this one can be opened afterwards, this can be done from any SQLite management tool or code without requiring the key I entered.
So, how the heck can you create an encrypted SQLite database please?
I plan to use the database in an Adobe Flex aplication.
Thank you.
SQLite supports integrating encryption but the default open-source SQLite distribution does not support encryption. Encrypted versions of SQLite are only going to be portable across different clients or tools if they all use the same encryption extension.
The SQLite developers themselves distribute a commercial version of SQLite that supports encryption transparently. When this module is used for encryption, the encryption works across platforms and every byte written to the file is encrypted. There is nothing in an encrypted SQLite file stored on disk to even indicate it's a SQLite database. Many tools support this implementation by allowing you to drop in the commercial sqlite.dll file in place of the open-source one.
There are also third party extensions that support encryption. For example, System.Data.SQLite supports encryption but utilizes .NET libraries to do so and thus an encrypted System.Data.SQLite can only be read by another client that also uses System.Data.SQLite (this is on purpose, out of deference to the core SQLite developers and their commercial product).
Adobe AIR 1.5 support encryption. I don't know for sure which mechanism is used though, I searched and couldn't find the answer. It's possible that an AIR encrypted database can only be read with AIR. I don't know definitively either way. However, here is a good starting point for learning about working with encrypted databases is AIR:
http://probertson.com/articles/2008/11/18/air-1_5-encrypted-sqlite-database-how-to/
Re: encrypting an existing database
"Out of curiosity, can a database that was created not encrypted be made so afterwards, when it has all sorts of data in it already?"
You can't encrypt an unencrypted database directly. You can change a database's encryption key using the SQLConnection.reencrypt() method, but it only works on already-encrypted databases:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/data/SQLConnection.html#reencrypt()
However, as a workaround you can open multiple databases within a single SQLConnection and you can copy data and structure from one to the other. I've actually written a utility class that uses that technique to allow you to encrypt an unencrypted db:
https://github.com/probertson/air-sqlite/blob/DB-copy-dev/src/com/probertson/data/DBCopier.as
Have a look :http://elromdesign.com/blog/2009/04/16/adobe-air-sqlite-manager-api-for-adobe-air-15-with-password-encryption/
It may help.
I have a program written in Delphi 7, which uses a MS Access 2000 database as the backend.
I have password protected my MS ACCESS 2000 Database file (*.mdb) with a 16 character password consisting of a misture of Numeral, control, UpperCase, and LowerCase characters.
However, it looks like there are a number of programs on the market that claim that the password can be retrieved. What is the purpose of this database password if that is the case? Is there anyway to make it so it is not retrievable? Tighten the encryption so to speak?
thanks
MS Access 2010 uses better encryption and has some other features. SQL Server Compact edition gives you a lot more security but is still appropriate for a desktop app.
Otherwise, go with a server database: mysql, sql server, oracle. Most have free versions.
Is there anyway to make it so it is
not retrievable? Tighten the
encryption so to speak?
It depends; you can either change your database and look for a more secure one (e.g. MS SQL Server Compact Edition), or if you want to stay on MS Access and security of the data is important to you, go for encrypting important fields using a good encryption algorithm (e.g. AES).
If you are going to encrypt your fields, you can do it transparently in Delphi; each DB field in Delphi is derived from TField class, and has two events called OnGetText and OnSetText. OnGetText is fired every time you try to read the field's data, and OnSetText is fired every time you try to write to the field. You can encrypt a field data whenever OnSetText is fired, that way, the encrypted data will be saved in the database. On the other hand, you can decrypt a field data whenever OnGetText is fired, that way, user will always see and work with the decrypted data. The whole process would be transparent to the users.
Of course you should take note that encrypting/ decrypting fields every time they are being read or write has performance drawback depending on number of fields to be encrypted, their size, frequency of reading or writing them, and the encryption algorithm which is used. It's better you just encrypt the important fields.
Another option could be to encrypt the whole MS Access database file, and decrypt it whenever your application is connecting to it, but that way, the file is secure as long as your application is not running; once your application is running and the file is decrypted; the file is exposed to others.
What is the purpose of this database password if that is the case?
It makes people who think Access is a real database feel good about it.
Is there anyway to make it so it is not retrievable?
Stop using Access.
Tighten the encryption so to speak?
Not in Access. However, if you stop using Access and use a real database, you'll find that you can also have real security.
If security is a requirement then you should not be using a Jet database or any other file-sharing database architecture. It's as simple as that.
What is the purpose of this database
password if that is the case?
The purpose is to get people to upgrade to MS SQL Server and buy licenses for that as well. There are things MS will never fix.
On the other hand they have a free version of MS SQL Server which is not so crippled so you don't have to start paying through your nose unless your system will actually grow to need a full MS SQL Server.
However, if you develop systems like that (with no plan and not understanding limitations of the technologies you choose), you are most likely to lock yourself into proprietary features, for better or worse.
EDIT:
Here is quote directly from MS
Note Although the model and
techniques discussed in this article
enhance security, the most secure way
to help protect your Access data is to
store your tables on a server, such as
a computer running Windows SharePoint
Services 3.0 or Microsoft Office
SharePoint Server 2010.
Use crypt aes instead of standard mechanism.
I posted this question on Experts-Exchange as well. This is the kind of answer i was looking for (not critisism). Although this person eventually tells me to switch datbabases, he clearly explains why, without critisism:
DatabaseMX:
As you've discovered, there is essentially no security in an Access db password, prior to A2007. The are 1000's of tools (some free) that can immediately hack an Access password. A2007/10 is using an improved password paradigm ... it's security level is not clear yet.
"Is there anyway to make it so it is not retrievable"
No. It's only slightly better than nothing, depending on your specific environment where the mdb will be used.
"What is the purpose of this database password if that is the case? "
It was just a bad implementation. Period.
With A2003 and prior, the best you can do are a combination of the following:
1) db password
2) Add User Level Security
3) Create an MDE to protect code. But event an MDE can be hacked.
So, IF ... you really need better security, you will need to look at SQL Server or equivalent platform.
mx
What are advantages of SQL Server2008+ TDE ( Transparent Data Encryption) over encrypting just database backup file (with a password)?
Update:
I am sorry - removed Oracle from this question (SQL Server TDE is for the whole database and encrypted data is stored in database).
Encrypting is not difficult to organize using C# without 3d-party tools, though there are plenty of 3d party tools.
I've never used either feature, but a cursory review of the 2008 Books Online documentation makes it clear that the PASSWORD option for the BACKUP DATABASE command (I'm guessing that's what you meant?) doesn't encrypt anything:
The protection provided by this
password is weak ... [it] does not
prevent the reading of the backup data
by other means or the replacement of
the password
And apparently you shouldn't use it at all anyway:
This feature will be removed in the
next version of Microsoft SQL Server
So whatever your security requirements, PASSWORD is unlikely to be useful. Whether or not TDE is useful depends on the risk you're trying to mitigate, e.g. it encrypts data on disk but not during transmission over the network. If you do implement some form of encryption, make sure you have extremely well planned and tested backup/restore procedures for a range of scenarios.
There is no feature in SQL Server to encrypt just the backups without encrypting the database. You need to use third party software to do that. TDE encrypts both database and backups.
Advantages of TDE:
Encrypting the backup file only obviously protects only the backup files, not the actual datafiles. If you miss encrypting a backup, it's unprotected.
TDE encrypts/protects only the table/columns you need. Encrypting the entire backup can be very slow for large backup sets.
Disadvantages of TDE:
Inserts/updates of encrypted data are slower.
There are certain features that cannot be used in conjunction with TDE.
Here is a nice overview of TDE.
I have a desktop application that needs to read data from a database, both installed on client computer.
That data in database must be encrypted, to deny client access, and protect data.
I need to know what kind of database to use that can supports encryption, because the amount of data in some tables will be very huge, I will need efficiency too.
I read some about this on web and perhaps SQL Server Compact Edition will be a good choice.
Can someone help me with this point?
Thanks
SQL Server 2008 includes a feature called Transparent Data Encryption which may do what you need. I don't know if Compact Edition contains this feature. A little googling with those keywords should get you started. I don't normally advocate using SQL Server, but in this case I'm not aware of any similar features from other DB vendors (but they must exist...).
That said, what do you hope to gain by encrypting the data? If this is entirely client-side, then the client is going to have the key to decrypt the data. At best, you're making a slight hurdle for people to get at your database contents. It won't be secure by any meaningful definition.
You cannot prevent a determined attacker from accessing the decryption key and accessing the database. This is effectively a copy-protection scheme, and they are all broken.
Update: The question states, "That data in database must be encrypted, to deny client access, and protect data." If the client has access to any application that can access the database, he has access to the key used by the application, and can bypass the application to access the database directly.
If the inescapable logic has no appeal, consider the anecdotal evidence of failed copy-protection schemes attempted to protect music, games, and other digital assets.
SQLite has an Encryption Extension (SEE) that allows an application to read and write encrypted database files: http://www.hwaci.com/sw/sqlite/see.html
This DB may be a good fit for a desktop application, and is widely used. For example, I believe FireFox uses it internally.
SQL Server CE has no support for encryption whatsoever. You can at best encrypt the database file using the host OS encryption facilities. The file level encryption does not work for databases because to read page X in the file one has to decrypt all pages 1...X-1 to get the encryption key in the appropriate state (reach the proper CBC block state). BitLocker on the other hand works fine as it can decrypt/encrypt pages in the file individually. But BitLocker is a partition level option, not file level. These general considerations apply to any plan to encrypt the entire database file, irrelevant of the product involved (SQL CE, SQL Express, MySQL, Access, anything).
SQL Server has database level encryption. The easiest to use is TDE, Transparent Data Encryption but this requires Enterprise Edition. The other option is to use the cryptographic functions and manage the encryption yourself. Hardly easy to use, but is available in the free Express edition.
Might I recommend SQLCipher? It's a free and open-source implementation of SQLite that supports transparent, page-level encryption. It's similar to SEE, it's under active development, and has experimental support for a number of different ciphers, as it uses OpenSSL for some of its implementation. Full disclosure: I'm one of the developers! We've got a tutorial on using it in iPhone applications that will give you a basic idea of how it works, and there's a comment thread that expands on some related topics. Obviously, using it in Visual Studio will be a tad different than XCode, but you should be able to hook up the linking and get it going in a Windows environment.
I don't want customers to be able to make backups of my sql server database and access the tables data etc.
I know there are some products that will encrypt the data in the tables, and their product will decrypt it when displaying in my application.
What products do you guys know of? What options do I have?
(This is a business requirement, however silly it might seem to some hehe).
Update
This is for sql server 2008 express
The problem with encrypting data inside the database is that as long as the database lives on the client's machine (as you indicated, they're running SQL 2008 Express, so I'm betting it lives on the client's desktops or laptops) then they can get into the data. They can set up security on the instance so that they have SA privileges, and from there, they can get the data, period. There's no way around that.
What you have to do is encrypt the data before it hits the database: encrypt it in your application. Inside the app, encrypt the data that you want to store in each sensitive field. As another poster indicated, you don't want to encrypt ID fields because those are used for indexing.
There is the 3rd party xp_crypt. It's been around for years.
It's an extended stored proc (that is, DLL)
SQL Server 2008 supports database encryption natively. Check the documentation for Transparent Data Encryption (TDE).
You can encrypt stored procedures, which can protect your logic.
TDE is available only Enterprise edition.
I can't find if it supports native sql encryption - but you could find this out with a little searching. But if it did you could probably set the database master key with your application and keep all of the decryption/encryption code in your application.
If it doesn't support native encryption, you might want to creat/find your own encryption functions in your application language and lock away the keys in your code.
Transparent Data Encryption will encrypt the database on disk, but is unencrypted in memory, so appropriate security would also be necessary to ensure unauthorised users cannot access the table. As it's an Enterprise-only feature, you can safely move away from it.
SQL Server 2005 and above have built-in encryption features - have a look at Books Online, and especially Chapter 5 - Encryption of Adam Machanic's Expert SQL Server 2005 Development book (technically, Lara Rubbelke wrote chapter 5 though).
Note that you'll only want to encrypt some columns - those that you'll never try to look up, as encrypted columns are pretty much useless for indexing. Adam Machanic's book suggests ways to solve this problem.
Another solution for transparent SQL Server encryption is DbDefence
Free for databases less than 77 MBs.