I've been looking for finding the best solution to store highly sensitive information like an Amount or a balance in a banking application. Can I store that just as a numeric field or Do I need any encryption to encrypt that data? Am a bit worried about encryptions since these fields are frequently being accessed by the users. So when ever it gets accessed there needs to be some decryption mecahnism and to store back the new balance amount that again needs some encryption.
Or is there is a better solution for that.
Database is SQL Server 2008 R2 and the platform is .NET 4.0
This is an important topic to think about, there are lots of ways to do it.
However encryption in the best possible way when we have confidential data and to save things from Hackers you should surely encrypt it.
Take a look at this
http://msdn.microsoft.com/en-us/library/ms179331.aspx
and this
http://msdn.microsoft.com/en-us/library/ms174361.aspx
You should not need to store the data in an encrypted manner.
When it comes to security of data you should always work on preventing access via firewalls and correct login protocols.
Also only allows users to access data for which they have clearance.
When it comes to encryption - you could encrypt the disk but encrypting columns is not really worth the access time it will take in decrypting the data and if someone has access to the database invariably they will have access to the decryption routines.
Related
We have a process where data is sent from one database to another for distribution. The process chosen at the time was to encrypt the data because of all the people that could access the database. However, de-crypting the data is a slow process.
What are the alternatives to securing the data on the servers to prevent access?
It all depends on your requirements.
If you really need to keep the data private from people whom have access to the database then you pretty much have no option but to encrypt.
If you are sending the data to other locations and it is the transfer itself that needs to be secure you can use encyption for just the communication, ie webservices over https or custom encryption over tcp/ip, or saving to flat files and encrypting it as a whole..
If the data itself needs to be hidden from the people whom have access to it then there is a question of how secure the data needs to be.. If you are just wanting to avoid clear text there are some pretty fast encryption algorithms that can be used, here is a List of different encryption algorithms.
But if you are storing things like medical history or banking information then you have no option but to either upgrade your hardware to improve performance or take the processing time like a man ;).
If we are talking about passwords, where you only need to know if the user entered the correct password or not, then you could hash the passwords with a salt, and compare with the database hash, read more about that here: Link.
Easy answer: none. The only way to prevent people with physical access to the database table (note: the database TABLE - most DBMS can set access rights for indivifual tables) from reading it, is encrypting the data. It really is that simple.
Couple of recommendations
Work with DBA to create roles and restrict access to sensitive columns. In this case you don't have to encrypt.
Few columns you have to encrypt due to regulatory requirements. Selectively encrypt only the columns having sensitive data.
Also use relatively faster algorithms like AES. You can also cache the crypto object if not already done.
Just started looking into encryption using keys and certificates in sql server 2005/08 and although it looks very good I'm not too sure why I should use it over sql server security permissioning.
For example, I have a table with sensitive data in, such as user-name/passwords.
I can either encrypt the data using say ENCRYPTBYCERT, or simply leave as plain text and just apply permissions to the table for authorised users.
I won't be transferring this data over the internet, just accessing internally over the network.
Are there any other reasons to use encryption?
Well it provides more security if you encrypt at the DB level. It's tied to the machine for a start, so you can't (for example) backup the database, restore it somewhere else, and have at it. If you also encrypt the keys (in a web.config encrypted section for example), then you have just defended against several different potential attacks.
So if you were storing customer data (protected by privacy law), or CC data (obviously with due regard to PCI DSS), then encrypting it like this protects it, for example, from your own support staff.
And then... if you're assuming that your other security is rock solid, bad people will never be able to get access to the data, but if they did, and if it was encrypted, they're still getting nowhere.
i devoleped windows application with c# and i use local sql database i want to secure it
from admins -
can i put password for sql database like (test.mdf) to secure it if no what is he best way to secure my database
(in other words)
can i keep my database not authenticated with windows and only be seen for auser i define
I'm afraid there's no 100% secure method to achieve what you want. You could protect Stored Procedure using WITH ENCRYPTION, but if somebody really wants to find out what your code does, he can find a way (e.g. with SQL Profiler).
If the issue is data sensitivity, you could encrypt the values before saving them in the database, but this will require you to modify your application and possibly add significant overhead. Also, unless you use some kind of obfuscation, your code can be reverse-engineered (actually, it can be even if you obfuscate it, it just takes longer).
In my experience, the most effective way to protect the data is via License Agreements. If customer tries to "play around" where he should not, then you have the rights to suspend support, charge extra fees to fix issues and, eventually, you have ground to sue them if you're afraid they "stole" your intellectual property.
This is one for all you security gurus out there.
I have a SQL Server 2005 database with a database master key, which is encrypted with a very strong password using the server key, which in turn is encrypted using the service account credentials in the Windows Data Protection layer.
I have a certificate which is encrypted using the database master key.
I have a symmetric key using AES256 which is encrypted using the certificate, and I am using the symmetric key to encrypt and decrypt confidential fields in the database.
What does someone need to crack the encrypted fields in the database? My only assumption is that brute force can't be employed due to the strength of the symmetric encryption algorithm, and the symmetric key itself is protected by 4 additional layers of encryption:
Windows DPAPI -> Server -> Database -> Certificate -> Symmetric Key
which seems pretty tight to me.
Let's not include the obvious answer of "get the system administrator's username and password by drugging and sleeping with him", which is definitely relevant but not what I'm after.
Here is a potential attack. It assumes you already have a way to run arbitrary code as the service account. For example, you might exercise a remote code execution bug to get. Having done so, it is relatively trivial to use DPAPI to get the server key. Having done that, you can get the master database key, although you'd need some brute force method to break the password.
It sounds like it would be pretty difficult to do, depending on the strength of the password maybe impossible. Is the service account low or high privileged? If it is an admin account, you could maybe use that (assuming it was broken) to install a keylogger to get the password.
K. Brian Kelley specializes in SQL Server security, and he's written several good articles about how encryption gets bypassed in SQL Server environments, like these:
http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/20/you-must-trust-someone.aspx
http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/27/a-security-control-inconsistently-applied-is-not-a-control.aspx
http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/20/you-must-trust-your-dbas.aspx
If you're really into security, I'd highly recommend subscribing to his blog. He's also available on Twitter at http://twitter.com/kbriankelley.
Somewhere in memory this un-encrypted key is stored to be able to encrypt against it, is there a way for an attacker to gain access to SYSTEM level to then be able to basically scan memory, or attach an extra thread to MSSQL.
Also, these encrypted fields, are they used in any front-end applications? Are they visible when you SELECT * FROM table? For example, you can have as much security on your database and fields as you want but if someone is able to use an SQL injection to write their own SQL queries and thus view the value of the fields you are still back at square one.
Assuming no human-engineering attacks are possible I would try to attach a debugger to the program reading it, obtain a snapshot of it's memory and try every set of bytes in a brute-force attack.
Even if I couldn't obtain the memory image I would try the same thing with the source file in case the key is in there.
Realistically, you have to ensure the key never appears intact anywhere to defeat such attacks.
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.