I have a program where a User can put data in a listBox, and this listBox can be saved by button click encrypted to an .txt file.
With any program start, the program loads and decode the Save-data back to the listBox.
So if anyone opens the save.txt, nobody can read it because its encrypted, but the users are still able to manipulate the encrypted textfile, so its not possible to load it back in my listBox.
Is the a way that my Form App, saves this .txt in a password protected folder or make something like invisible .txt files, only the Program can see?
You may make your file, Hidden, or even give it a System attribute that can be a precaution, but still, it is not very safe.
You can use SqlServer database to save your list, that handles encryption for you. (of course, if the user has admin privileges) he can still open and manipulate its data.
You may use Properties.Settings (AppSettings) too, but as I already said each option can have its advantages but not 100% safe, for a user with privilege.
First thing you need to work out is if you are over thinking this, is not hiding it and encrypting enough, why are people going to track down your file and mess with it?
However you do have a plethora of options, though you can hide it as much as you like yet the only way to stop dirty little fingers touching your data is put behind a remote web server.
However failing that,
You can stuff it in a database with restricted permissions
Put it in App Settings where its less obvious to find
and/or Create an account and impersonate that user in your application and programmatically restrict permissions to your file
Hide it in the registry (meh)
You could do something weird like append it to the end of a dll
Even change the extension to your file, and sociologically impersonate another file type like an exe or dll, make it less obvious
Though really if you want to restrict it, just create a web sever, give the user a login and password, and save it there, no dirty little fingers.
Related
I wrote a custom control for output file name selection with the typical: text box for the filename, a "browse" button, and some other functionality specific to my application.
The text box changes color depending on the filename. If the file location cannot be written to, it turns red. If the file already exist, it turns yellow. Otherwise, it remains the system-assigned color.
To see if a file exists, I use IO.File.Exists; simple enough.
I implemented the "if the file can be written to" as a simple try-catch block where a file is actually opened, something written in it, closed, then deleted. If at any point an exception is thrown, I know the user can't use that filename and I turn the text box red.
This is a catch-all; since I'm doing the actual operation I intend to do, it is fool-proof. However, it seems irresponsible to have software creating and deleting files like crazy just to see if it can.
So my question is, how do I replicate this functionality without creating files? I can see I have to:
Check the path for legality (e.g., 'z:' is not a valid filename). This entails parsing the path and making sure all directories exist.
If the location exists, I have to check for write permissions. (Several answered questions exist to this end.)
Is there anything else?
EDIT
Within minutes I see people are already voting up an answer that criticizes that I'm checking at all that the file is accessible before actual writing to it occurs. While I appreciate experts "standing back" from my question to see whether or not there is a completely different way to achieve it, telling me I shouldn't be doing it is not an answer to my question.
So let me elaborate on my application (I am not expecting hundreds of users at the same time).
I use this file chooser control in data acquisition applications. In many situations the test that you are about to run is "expensive" in one way or another. Therefore it is critical to set things up very carefully. Overwriting data can be very expensive (and for the fearful user I have a checkbox that will append the date and time down to the millisecond to the filename).
So the purpose of my indicator colors is not to provide a surefire way for the software to know the file can be written to (that check is still done at the instant it actually has to), it's to serve as an indicator to the user that at least he has set up the file name correctly so if he goes forward he is guaranteed not to overwrite old data and he's almost sure a last-minute IO error (filename typo) won't let the experiment run unrecorded.
I suggest this - don't check anything before user commits the action. With your current approach, even if you verified the file is okay, it may be locked 5 seconds later when the user actually commits to write to a file. Doing preliminary checks may only give user a false impression of estimated success. Especially consider this point on a terminal server with 100+ simultaneous users.
There is nothing wrong with showing a prompt with Retry/Cancel/etc. if no access, and let user decide.
EDIT:
No offense, but there are standards on how such collisions are handled. Windows standard is to show a prompt to the user. Also consider this - if you suddenly have a deny in write access to the folder, which you are not expected to have, you probably need to hire another system/network administrator.
If the operation is costly, make sure this guy is paid well. C'mon, what if your network goes down during writing? Hard drive? Router? There are many reasons why writing to a file can be interrupted, and you should be prepared for that. If you cannot afford it, make sure you have invested in good infrastructure and good people to support it.
Down on earth, you can increase chances of acquiring a successful lock on the file:
Pick a unique file name, using datetime-based hash as a suffix/prefix.
Write to user's home directory, also known as %UserProfile%, it is likely that you will succeed.
I can understand your problem with not wanting to risk losing "expensive" data because the file couldn't be written and a responsible program will do it's best to avoid the situation.
I would do this by cacheing the results. Before the test is run write a mock result to a file somewhere in the user data space, then leave the file open and write the real result to the file. After this is done write it to the user-specified file. Provide a recovery option that will read the cache file and write it out to the user's file.
Your approach could fail because just because the file was writable at the start doesn't mean it's still writable. The network could have gone down. Someone could have removed the flash drive. Someone else could be doing a large data transfer through a buggy router. (Real world case--it took me a long time to prove it was a network problem and not my program. finally accepted it was their fault when I showed that dir :*.* /s on multiple machines at once would almost certainly cause one or more to fail.)
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 know this isn't a strait up code question, but I'm trying make a program that could possible be running in the background of my computer, and allow me to leave my files/folders where they are, and upon double clicking on a file/folder a dialog box comes up asking for a password. All these programs that are on the market require you to move files around, create new volumes; I don't want that, I want simplicity. One dialog box with password promt, then file/folder opens. My question is what do I need to look into coding wise to make this possible? Thanks for any advice/tips. :)
FileSecurity()
Also Is this something that can only be done with NTFS and not FAT?
You can not detect when someone click or double click a folder, so no, it is not possible.
you can use FileSystemWatcher to detect when a file is opened and handle the open event, but unfortunately you cannot prevent its execution
I can think of only three ways how to SECURELY protect file:
write filesystem driver (similar used by antivirus software for example), but isn't not possible in C#
encrypt all files when user locks folder and decrypt them back when user unlocks folder.
for non-admin accounts, you can set privileges (and on NTFS also built-in file encryption) in such a way, that without admin password user can't access them
Method used in article you mentioned is not secure at all (any user can just rename the folder back to get access to protected files). Though you can use the same trick to run you program automatically when user double-clicks protected folder and unlock files if user enter correct password.
I am trying to write to a file which has the following attributes - Hidden and ReadOnly. My process should be able to write to it but other processes have ReadOnly Access.
The procedure that I am following is:
Check if file exists
Remove the existing attributes on the file, i.e. hidden and readonly
Finish writing to the file
Apply the attributes (hidden and readonly) back to the file
I know that this is not the recommended way to use the File Attributes and write to a hidden file. Is there a nicer way to accomplish my task?
Thanks in advance.
Yes, make your application impersonate a special account. Give file write permissions to that account on that file and read access to all other accounts.
The simplest way to run in the context of another user is to press shift and right click the exe-file, pick "Run as different user".
With a windows service you change the running account from the service properties. The same goes with Windows Scheduled tasks.
To change the running account "in the middle of the process" you need to do some more work, find a good article on the subject, like http://www.codeproject.com/Articles/4051/Windows-Impersonation-using-C .
As #Albin notes, the correct way to address the access issue is with file permissions, not attributes.
If the file is hidden because you don't want users to be able to view its contents, I'd suggest a simple (relatively lightweight) encryption mechanism would be a better solution than the hidden attribute.
Note, both the hidden and read-only attributes can be turned off by a user with sufficient privilege. And typically anyone can turn on the "show hidden files and folders" feature in Explorer.
There's no need to remove the hidden attribute. I know of no other solution with the readonly one, though.
I'm writing a program that deals with the logs generated by the clients server. How can I detect where the user is storing them? It feels invasive to search all files, but what if they're being stored outside of the root. Is this acceptable, what if I make the user click "detect" first? Regardless, what if they've been renamed and reformatted? Is it possible to read the server settings themselves from my external program? I want this to work on linux and windows servers. I need WC3 Extended format w/ several fields enabled that are not naturally. I also don't want it to return null if it's enabled but no log has been yet created. I don't want to force the user (assumed dumb) to play with settings.
Any ideas?
Hardcode where you expect them to be in the common case, and if they're not there, ask the user about it. Doing more "magic" than that seems like a recipe for over-complexity and mistakes.
If the user is specifying the location of the log file, then either you should have the user locate the file(s) themselves or keep track of these locations somewhere else when they are saved. You don't need to be doing a full (or large partial) drive search.