i want to encrypt the database file before deattach it to move it to another sql server and decrypt the database file on the other sql server
Try protecting your archive instead of DB cypher mechanics. File-protectors are much more mature today. Usually, simple 7z-archive with a password on it is a quite fine precaution to sleep well in the middle of your DB migration.
You can encapsulate 7zip LZMA into your code like here for C#.
I advice you a highly available solution concerning that we discuss a small businees solution. For Enterprise business, it's all different completely.
The other option is using native SQL Server Encryption. Then you should follow the genuine manual here
CREATE MASTER KEY ENCRYPTION and etc...
Related
I'm looking for a SQL database engine that I can distribute with a C# Winforms application. The requirements are:
Will store about 1GB of text (measured before any compression).
Database must be encrypted, the encryption key will be supplied by the application at runtime.
Compression (prior to encryption) would be nice, so that corrupt databases can be replaced remotely over a low-bandwidth network
connection.
Reliability, replacing a corrupt database can involve an expensive site visit.
Low licencing costs and support costs.
Users will only access the data via the application, so no fancy UI required.
Options I've considered:
Sybase SQL Anywhere - OK, but not "free".
MS SQL Server Express - no whole-database encryption!
SQLite - encryption requires a licence payment?
VistaDB - not "free".
What other products fit the bill?
Get the Visual Studio "SQLite/SQL Server Compact Toolbox" Extension. Using this:
Microsoft.SqlServer.Compact from Nuget will create encrypted databases provided you manually run the command
Create Database "something.sdf" databasepassword 'somepassword'
in the extension's query window.
System.Data.SQLite.Core from Nuget will use encrypted databases provided you use the above extension to create the database and key in a password at database create time.
The mediapassword option that was available when backing up a SQL Server database was discontinued in SQL Server 2012.
Is there a suggested replacement procedure to follow now? I want to protect a database backup so that it can only be reattached to a SQL instance if one knows a secret (like a password). This secret can be generated at the time of the back or restore.
The only people who should be reattaching the database are the clients who own it, or support staff if they need to examine data within it. Because of this, server or SQL instance specific encryption is not an option. The backup and restore is done programmatically so the complexity of the process is not an issue.
What are the available options? Will I have to implement a secondary operation after the backup (like creating a passworded zip of the backup file, or manually encrypt the backup)?
Personally I think that things have improved significantly with SQL Server 2014, in that true encryption of backups is now supported.
I'd recommend taking a look at http://msdn.microsoft.com/en-us/library/dn449489(v=sql.120).aspx for details of how to encrypt a backup using a certificate.
You can do database encryption http://msdn.microsoft.com/en-us/library/dn449489.aspx to ensure it is secure
Thanks
Sunil
I have a vb.net windows form application with a database on SQL Server 2008 on the ./SQLEXPRESS instance.
I have created a setup of my project using the link below..
http://msdn.microsoft.com/en-US/library/49b92ztk(v=vs.80).aspx
When a user installs my application, the database will be available for him, and user can just export the SQL Server database.
How can I secure my database so that user shouldn't have a easily available copy of my database?
I thought of creating a new password protected server (as I have created the database in above walkthrough)... while installation of my application on user's pc, other than ./sqlexpress. And a complete copy of database used by my application will not be simply available for user to just export and get a copy of my database.
So could anyone please guide me...
The question is; how far do you want to go to protect your data?
Better protection of your data usually comes at the cost of more development time and likely less user friendliness, for example due to lower performance (encryption is not free). More complex code usually results in more support requests too.
Where the best balance is depends on your business model (if any) and on your user requirements.
Keep in mind that anything you deploy to an end-users machine is in the end vulnerable. If something is valuable enough there will be people trying to steal it.
So, you could argue that the best protection is not to deploy the data at all. You could back your end-user application with a web service and keep the data on your own server, for example in the cloud.
I've found however that you sometimes just need to trust your users. If you build a good product that makes them happy, they have no reason to steal from you. In fact, they are probably glad to pay you.
If you decide that you need to deploy the data and that you need to encrypt it, you should think about why you chose SQL Server.
What database features do you need exactly? Do you need a fullblown database server for that?
Any local admin can gain control over any SQL Server database in seconds so the built-in SQL server authentication will not bring you a lot of benefits.
You could switch to SQLServer CE and keep the database within your application. That would make the database a lot harder to access for a regular user.
If all you're doing is looking up words, you may be better off with a different storage engine like Lucene.
Lucene is actually a search engine, so it's highly optimized for matching words or parts of words.
You can run Lucene inside your .NET application so you don't even need the end-user to install SQL Server. There is a .NET version of Lucene here.
Lucene however doesn't protect your data. There's tooling available that will allow anybody to view and extract the data from the stored index files.
Since Lucene is open source though, you could extend it to support encrypted data storage (see this related question).
We've started using SQL Server 2005 Express for a project and I noticed that every database has it's own MDF/LDF files. Whenever we need to duplicate our database (to another SQL Server) we simply copy these files and then attach them to the database.
However, this has me wondering about the security of these files. If somebody from the outside gets a copy of them are they encrypted or can they simply attach to them like I'm doing? I'm not prompted for any passwords when I copy/attach them myself so I'm a bit nervous.
Thanks,
John
They are not encrypted and can be loaded/attached by any person with read access to the MDF/LDF files.
There are a couple of approaches you can take if the actual MDF files need to be protected. (This assumes that merely using file permissions to lock down access isn't feasible, for example if you need to protect against users with Administrative rights to the machine or direct HDD access.)
Use EFS or BitLocker or similar to encrypt the files themselves. This won't protect against other applications in the same session/context accessing the files, but it will protect against other accounts accessing the files (EFS) or someone stealing a laptop/hard drive (EFS/BitLocker).
Encrypt the sensitive data within the database itself. You will obviously want to store the encryption key separately (possibly using DPAPI to protect it, for example). SQL Server 2008 Enterprise Edition introduces a feature called Transparent Database Encryption (TDE) to make this process easier, which obviously doesn't help much for 2005 or Express Edition, unfortunately. Your best option in this case might be to do custom encryption of sensitive data in your app. (Unfortunately in 2005 this will require either using varbinary fields or Base64-encoding encrypted values etc.)
Don't store the data locally in the first place (i.e. use a remote SQL Server rather than a local Express instance). That doesn't truly solve the problem, but it reduces it (you only need to protect the remote instance rather than N local/express copies).
I need to develop an application which stores data in a SQL Server 2005 database (the app itself will be either a WCF Service or an Asp.Net Web Service).
Now, this data is supremely confidential, and I need to have it stored in an encrypted form in the database.
So, I am wondering what the best practices are around this. I know that there is some encryption capabilities that SQL Server has in-built. Is there a 'for dummies' type of resource for this so that I can quickly get going.
Alternatively I was thinking that I could encrypt/decrypt in my C# code and not in the database - maybe have a layer which handles this just above the data access layer (is that a good idea)?
Look at this link for a good introduction with samples.
I think doing the data encryption in the application is better, because in that case the transferred data is already encrypted. Otherwise you have to use a secure channel between your app and the database server.
It depends on your needs, i would say.
Have you considered encrypting your data at the file-system level?
It's Windows 2008/Vista only, but it should give you what you need and it's what it's designed for.
Before you decide on an encryption method, you need to access what parts of the system are vulnerable. If the potential for unauthorized access to the database exists, does the same threat exist for your application? Someone could run your code through Reflector and determine what methods were being used to encrypt and decrypt. You can mitigate that exposure to some extent with the code obsfucators. If that concern is not a risk, then you may find it easier to encrypt your data at the application level.
Encryption needs to happen in a few different places depending on the application. For example a consumer site using credit card info needs to encrypt the connection over the network to prevent man in the middle attacks or snooping. when the data is stored in the database you need to encrypt the data so that a low level sales rep cant read and access the customers credit card info , in which you might want to implement column level encryption as appropriate permission in addition to this if your worried that one day the janitor at your data centre might steal one of your backups then you need TDE implement to encrypt data at the disk level.
Encryption has a performance overhead esp with regard to CPU usage more importantly the overhead depends on the alogrithim being used for exncryption.