Database File and Application that reads the db. The application has a registration component added. If the user doesn't want to register they can simply download the open source application, copy the database to the new folder, run a batch file and the database opens in the application, completely eliminating the registration and whatever extra features were added.
I want to keep the database file inhouse, even if it means adding the db file into the resources of the main application. The file does require data to be written to that file.
I've gone as far as converting the batch file to an exe file and loading the database file or even renaming the database file to something obscure like abc.exe (Even though its a db file it can be renamed to anything)
Database file is renamed to an exe file for the time being, I would prefer to either have it encrypted somehow or somehow placed into the resources of my main application and accessed that way, I am just trying to limit the way the software can be pirated.
Encryption:
You can encrypt SQLite databases using extensions such as SQLite Encryption Extension. The usefulness of such encryption depends on what you are trying to do. If your application can read the keys to decrypt it, so can a hacker that can run your application. You can use Windows Data Protection API to manage the keys so that if someone copied the database from one windows machine to another, the database would be unreadable; but again, if the hacker can access the source machine, they can obtain the keys just like your application (but it would protect against a "dumb" user from just copying the files over).
Putting it in your "main application resources": If you mean embedding the database within the EXE, you are out of luck if you have a requirement to write the data. Generally speaking, an EXE cannot modify itself (though depending on OS/version/user permission/absense of antimalware agents, etc, you might theoretically accomplish a self-modifying EXE; but, if you want your app to work most of the time in the wild, this strategy won't succeed). Even if you did succeed in an EXE that read itself, loaded the embedded blob as a database, modified that database in memory, then rewrote the entire EXE with database exported as a new blob (of different size than the original, wreaking havoc on the assembly), it wouldn't help. The attacker can do what your app does and access the data. Do yourself a favor and follow the operating system's guidelines for writing user data. For Windows, this is generally reading and writing files to your Local App Data folder.
Renaming a SQLite database to have an EXE extension. What are you trying to accomplish? Obscurity? Renaming it to EXE might fool some users (certainly not the motivated user I've described above), but it also might accidentally fool anti-malware / anti-virus software running on your legitimate user's operating systems into thinking your application is writing malformed executables (which would be suspicious) and shut your application down, or at least prevent it from working correctly. This will cause your users to not use your application or a mountain of support for you. What does it gain? It stops a "dumb" user from trying to open it in a SQLite query tool?
All that said, if you want to limit your user's abilities to read the data stored on their own storage devices, you really can't stop a determined user. You can stop the less savvy users. The majority of users cannot run a reflector on a C# assembly and figure out what it is doing, but many can. If you want to stop the less savvy users, encryption of the data will stop most of them, and it will be the least likely approach you've discussed to prevent your application from working "in the wild".
Related
I'm creating a firmware update application (in C#, WPF, MVVM, .Net version still up in the air, but I hope to run it on Windows and Mac) that will allow the user to check for updates to both the application itself and for the latest firmware. I plan to use the common method of putting a file on a server that contains the latest version number and a URL to the files. The application will download the file, compare the versions in the file with the local versions, and download the latest files and/or update the application. Universally lacking in the 'how to's' of this method is the topic of security.
My initial thought was to put the "current version file" in a password protected secret folder, but then that seems overkill for a simple XML file. And since the user will be able to download the app from the website anyway, hiding/password protecting the URL to the application seems pointless. Even the firmware, being a binary file running on custom hardware, at first thought seems rather benign from a security perspective. But then again, I don't spend my days thinking of how to hack into systems.
So, in regards to just the process described above, what kinds of security measures should be taken to protect the server, data and user from attacks? And potentially as a bonus question, what security measures can be taken to protect the application update itself? With this, I can at least see the potential to trick the updater into installing malicious code, so a checksum to verify the updated file's integrity would be a minimum there.
I would like to create a c# application which will open when i open a folder automatically.
My c# application is intended to be like a password system, so that the contents in the folder can only viewed after logging in to my application. Everything is ready..........
but i am confused how to open my application directly while opening the folder with a c# script?
I have now created a application which will ask the user for name and password while opening the application and now i want to make it open through the folder to be locked , how to do it?
Ok, first of all if you want the folder to be secure you should encrypt it otherwise all the user has to do to gain access is kill the process.
What i would recommend you do instead is create a encrypted file. For example a zip file. Then all you have to do associate the file with the program and to unpack it with the password. Then when the user is done delete it and overwrite the temporary folder. It's really important that you overwrite it otherwise the encryption is useless.
If you want to avoid conflict with other programs that work with zip files you can make your own file type it does not affect the content of the file in any way.
I hope this helps.
To make sure I understand... you want to build an application that will, when someone tries to open it, will only open after they supply a password. Hmmm... okay. A specific folder, or any folder? Local folders or folders on network shares? I initially was thinking a file system watcher approach, but that will only work on change events, like copying, renaming, deleting, etc. So that won't work. The closest would be to check last accessed time, but that is an alert ex post facto, so this must be rejected. I'm not sure how you could do this in C#. What is wrong with the robust security options MS has already established, like global groups. That provides flexible restrictions on access. Especially over large amounts of folders. Are users going to have one password per folder? Too cumbersome. One password per user? Use Windows authentication to lock it down. How is this app storing the passwords?
I recommend trying to leverage existing technology to solve problems before trying to re-invent the wheel. You have omitted the scope of this, and what you have already attempted, so we may not understand completely.
I have a file called middle.config that is deployed in the same directory as an exe, but I need to update values in this file. That means that I have to go to C:\Program Files (x86)\ directory to access the file. Although it is named as a .config file it does not follow the usual schema of a .config file. It looks like this:
<configuationSettings>
<middleSettings
groupName="XYZ"
forkName="SomeDbName"
dbServerName="123.123.123.123"
cnnTimeoutSeconds="30"
cmdDefaultTimeoutSeconds="30"
cmdMediumTimeoutSeconds="60"
cmdLongTimeoutSeconds="480"
/>
<userKeys>
<Assemblies value="C:\assemblies\" />
</userKeys>
<friendlyDbName value="NiceData"/>
</configuationSettings>
I'm able to read and manipulate the content with Xml, but when I try to save the file back, a "No Permissions" error is thrown. I cannot relocate the file. I'm stuck with this legacy schema so I'm not able to treat it like a normal .config file using ConfigurationManager.OpenExeConfiguration. I cannot define sections or groups on this schema (I've not been able to anyway). All my users are Administrators on their local machines.
How do I overwrite or delete and replace this file while it is in a protected directory(my assumption about the permissions error)? Failing that, is there a way to access this schema somehow with ConfigurationManager.OpenExeConfiguration.
{edit starts here}
There are three applications in this scenario, A, B, and mine C. Application A does not know about any other applications. It can connect to many, many databases, and it drops a single file 'middle.config' that contains pointer info to the last database location that was used by the last Application A session. Application B, let's call it an import/export application, only operates on the last Application A database location. Application B reads the 'middle.config' file for database pointer info and then executes console commands against that database. It performs bulk dumps or bulk imports for selected portions of the database.
This was the situation when I come along to build application C that uses the import/export application B to fetch, blocks of data and return them to the database. So, in order for application C to use Application B
against any database, application C must modify the 'middle.config' file so that application B will find the correct database. Application C is new and the other two are legacy. I either find a way to make this work, or I force the user to start Application A and point to the database of interest, then close Application A. This is VERY unhandy.
{edit ends here}
It is not advisable to write data files to the program files directory, as this requires elevated permissions. Giving a program elevated permissions just to update a config file clashes with the Principal of Least Privilege, which states that
a particular abstraction layer of a computing environment, every
module (such as a process, a user or a program depending on the
subject) must be able to access only the information and resources
that are necessary for its legitimate purpose
It's not a "legitimate purpose" to give the process elevated permissions (that can allow it to do many harmful things) just to update a config file. MS recommended practice is to write that type of data elsewhere.
Instead, consider storing the config file in a subfolder of the ApplicationData folder.
Suggested that your app is creating its own location under the AppData location folder for the current user instead of writing to files under location where the the app is installed (especially if under Program Files which is very strict.) Not suggested to force the user to run as Administrator for your application either.
Your assumption about protected directories is correct. Program Files has an Access Control List which prevents modification by processes running as standard users and, on Vista upwards, even by administrator processes which are not running elevated. Accessing the file using the standard configuration classes would not get around this.
If you absolutely can't move the file (Eric J. is right when says that writing to Program Files after installation is a bad idea), then you could embed a manifest in your config file-editing program which will try to force elevation with a UAC prompt at launch. Of course, the best solution would involve a) using standard config schema and b) keeping user data in user-writeable locations, but sometimes that isn't possible for legacy reasons.
I'm not aware of any way to persuade ConfigurationManager to read a non-standard schema, unfortunately.
Move the logic to a separate process and launch it with admin privileges from your current application.
From a different angle, look at this: Writing custom sections into app.config
I found the linked article to be very useful. Not sure it is going to answer all your questions though.
I want to secure my external hard disk by writing sort of ShellExtension. But Shell extension is Workstation Specific.
Is there a way I can write an application that will show a authentication or an extension encrypt my drive data so user will get a failure message when double click on my drive.
You can't secure an external harddrive by the use of a shell extension, period.
If you want to keep your data safe, there's only one thing you can do: encrypt it. NTFS has built-in encryption, but I wouldn't recommend using that for an external drive, because of the way the encryption keys are handled.
There's a nice pre-cooked solution for you, though: TrueCrypt. It works, is available for multiple operating systems, has decent speed, and good security. Use it.
1) You should not write a shellextension in .net
This causes lots of trouble since then the .net runtime is injected into every application displaying a shell window (like the file open dialog) and if it already uses a different version of the runtime it will likely break.
2) I don't really understand what you are trying to do. But I encrypt my external harddisk with TrueCrypt. That's secure and easy to use.
This is only possible if you change the drive. Otherwise just using on a system without your software would bypass it.
Using NTFS with permissions for the drive's file system would be bypassed by anyone with applicable Window's privileges.
Using an encryption tool may be best: a single public file which contains a complete drive only accessible with the right software and authentication—there are a number around.
I currently store a serialized XML file in the application directory that contains all changes specific to the program operation (not typical system or user configuration). Weeks ago, we started running into problems where it would not save correctly (read my previous question about this).
Long story short, we finally discovered that Windows 7 (and sometimes Vista) has an issue with writing into the application directory (specifically anything under Program Files). Now, if this were a normal configuration file I would simply store it under the user's APPDATA folder, but it is not normal. We run this on our own instrumentation, and misconfigurations are 99% of the reason customers have issues running our software. So we need this file to be accessible such that they can easily find it and email it to us. Appdata is hard enough for experienced users to find, much less very non-technological people.
We've also tried running it as Administrator, and making folder permissions wide open (we have control over every computer it runs on; it will never run on some random person's machine). But, these sometimes work, and sometimes do not.
The worst part is that when I write the file back out, it doesn't even throw an error; it simply writes it to some temporary directory that expires at some unknown point in time. Weeks later, our user will have an issue, and the configuration file is all messed up.
So, my question is where should I be storing this file, if not in Program Files? Should I just put it in APPDATA anyway, and make a small utility that emails it to us automatically in case of a problem? Or can I leave it in Program Files, but change some specific permission or registry key to allow it to operate normally?
It depends on whether or not the user needs to edit the file directly. If not, you should put them in %APPDATA%, which you can access via:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Otherwise, you might put it in My Documents:
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)
Either way, putting it in Program Files is not a good idea. As you discovered, there are permission issues, even if running as Administrator.
For those users, you could build a button in that would open this directory. You could put it in an inconspicuous place that you could later direct them to.
For users that have an email client on their box, you could have a button that would create a new email with subject and automatically attach the file to the email.