Is there a way to have a signature on a SQL DB so only a specific application with a specific version could access that DB?
I'm using sql server 2008. I have a DB that I wish to protect in several ways. The important columns are encrypted and the application itself is signed and obfuscated (holding the key).
I'm looking for a way to block an application, even an earlier version from accessing the DB even if holding the key. I would like to prevent a case where someone hacked the exe, hacking the exe will break the app signature and will prevent him from accessing the DB.
thanks
Avi
To answer your question, you'd have to store the signature on the database, probably in it's own table.
The signature would be the version number of the software, salted, and encrypted.
What kind of app is this?
On .NET strong naming was invented for this purpose. Also google for SignTool.exe (MSDN)
Otherwise you'd need to self-verify
Nothing like that is unreversible (e.g. self-packing and self-modifying code is routinely reversed using tools like IDA-Pro). So if you can, try to rely on OS functions to verify the exe
It sounds like you want to sign the application, not the database. There's no way for SQL Server to really know what version of the app it's talking to, since the application itself is responsible for telling SQL Server what version it is. You effectively are placing your app outside the "trust boundary", yet you want it to behave in a trusted fashion.
For stuff like this, I recommend going with a three-tier solution instead. Create a trusted middle tier which talks WCF or Web Services to the application. This middle tier is hopefully something you can control and trust. The middle tier could then use certificate-based authentication (or any number of other types of) to clients in order to authenticate their identities, and then pass back the appropriate data based on the user's authorization to it.
Related
Background:
Our team is building an inhouse Intranet web application. We are using a standard three layer approach. Presentation layer (mvc web app), Business layer and data access layer.
Sql database is used for persistence.
Web app / iis handles user authentication (windows authentication). Logging is done in business and data access layer.
Question service account vs user specific Sql accounts:
Use service / app account:
Dev team is proposing to set up service account (set up for application only). This service account needs write & read access to db.
Vs
Pass on user credentials to SQL
IT ops is saying that using a service account (specifically created for app only) for db access is not deemed best practice. Set up Kerberos delegation configured from the web server to the SQL server so that you can pass on the Windows credentials of the end users & create a database role that grants the appropriate data access levels for end users
What is the best practice for setting up accounts in sql where all request to db will come through the front end client (ie via bus layer and then data layer)
The Best Practice here is to let the person/team responsible for the database make the decision. It sounds like the dev team wants to forward (or impersonate) some credentials to the DB which I know that some small teams like doing, but yes that can leave things a bit too open. The app can do whatever it likes to the database, which is not much of a separation if you're into that kind of thing.
Personally, if I understand what you're saying above, I do more of what the IT team is thinking about (I use Postgres). In other words my app deploys over SSH using a given account (let's say it's the AppName account). That means I need to have my SSH keys lined up for secure deployment (using a PEM or known_keys or whatever).
In the home root for AppName I have a file called .pgpass which has pretty specific security on it (0600). This means that my AppName account will use local security to get in rather than a username/password.
I do this because otherwise I'd need to store that information in a file somewhere - and those things get treated poorly pushed to github, for instance.
Ultimately, think 5 years from now and what your project and team will look like. Be optimistic - maybe it will be a smashing success! What will maintenance look like? What kinds of mistakes will your team make? Flexibility now is nice, but make sure that whomever will get in trouble if your database has a security problem is the one who gets to make the decision.
The best practice is to have individual accounts. This allows you to use database facilities for identifying who is accessing the database.
This is particularly important if the data is being modified. You can log who is modifying what data -- generally a hard-core requirement in any system where users have this ability.
You may find that, for some reason, you do not want to use your database's built-in authentication mechanisms. In that case, you are probably going to build a layer on top of the database, replicating much of the built-in functionality. There are situations where this might be necessary. In general, this would be a dangerous approach (the database security mechanisms probably undergo much more testing than bespoke code).
Finally, if you are building an in-house application with just a handful of users who have read-only access to the database, it might be simpler to have only a single login account. Normally, you would still like to know who is doing what, but for simplicity, you might forego that functionality. However, knowing who is doing what is usually very useful knowledge for maintaining and enhancing the application.
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).
I am planning to make a VB.Net application that is hard coded to access an MS SQL database hosted remotely on a web server. Is there a way for someone using some packet sniffing (I think it is called) program on the client PC to somehow know what password was used to access the database? I don't need to know how it is done, I just need to know if it can be done so that I know if my approach is safe enough.
Thanks!
If you only care about protecting the login to the database, then you're OK, according to this MSDN article:
Credentials (in the login packet) that are transmitted when a client application connects to SQL Server are always encrypted.
But if you also care about protecting the data, then you should read the rest of the above MSDN link to learn about enabling SSL to protect the rest of the data stream.
Note also this older article which gives a caution on using ODBC connection (rather than the native tyep). I doubt you would be doing that, but just thought I'd mention it.
From a client machine, it is unlikely that your database information can be sniffed. However, if your application "leaks" information, it is possible for an outsider to get sensitive information about your database. For example, if you have the CustomErrors parameter set to "Off", and your database is inaccessible for any reason, users may see your database's address and can then proceed to attack it using brute force or known exploits. There are other ways you can leak sensitive information this is just one example.
In general, it is not ideal to have your database open to the internet -- it is generally advised that your database be behind one (or two in case of a DMZ) firewalls. If you can control this, you should move it somewhere more secure. Or else even without your application leaking its address, a port scanning "war dialer" will eventually find it and alert the "bad guys" to its existence.
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.
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.