Has anyone used IObit Protected Folder?

[FocusWiz]

I have a software product I use which stores its ID and PassWord in an unencrypted file and am trying to remedy this situation without disabling the software. While this lack of security is generally enough to make me stop using a program, I still need to use this software.

Recently I found this product:
http://www.iobit.com/en/password-protected-folder.php

which allows me to leave the filename visible and allow the software to update it, but keeps the file unviewable (interestingly it has a way to allow write access without read or copy or print access).

The product says it has a one year subscription. I am concerned that this will render my files hostage if I don't renew for eternity (even though it is just a handful of files).

Has anyone had any experience with this product or its reliability or features or does anyone know of another product which can protect a file from prying eyes?

I am planning to encrypt the drive on which this file resides, but the fact that this is an unencrypted text file means it is easily copied while I am logged on to the drive. I don't mind the software having access to it, but I don't want it to be easily viewed.

Thanks for any thoughts on this.

[wilderness]

Has anyone had any experience with this product or its reliability or features or does anyone know of another product which can protect a file from prying eyes?

the DOS 'attrib" command has been around since the beginning of time.

[headhawg]

The attrib command doesn't encrypt. If you are suggesting FW use the +h argument to hide the file, that will be overridden if "Show all files..." is enabled in Windows Explorer. (You can change file attributes without using attrib anyway.)

My concern is this statement: "...but the fact that this is an unencrypted text file means it is easily copied while I am logged on to the drive." If someone can access your encrypted drive(s) while you're logged in, that seems like a much bigger issue to me than a plain text file.

[FocusWiz]

the DOS 'attrib" command has been around since the beginning of time.I've used the DOS ATTRIB command to make a file "Read Only" or "Hidden."

Unfortunately, the attribute I am looking for is for the file to be unhidden and able to be written to but not able to be read.

Are you familiar enough with these commands to give me the syntax I would use? I believe I've done this in Unix, but never in a DOS or Windows environment.

[FocusWiz]

The attrib command doesn't encrypt. If you are suggesting FW use the +h argument to hide the file, that will be overridden if "Show all files..." is enabled in Windows Explorer. (You can change file attributes without using attrib anyway.)

My concern is this statement: "...but the fact that this is an unencrypted text file means it is easily copied while I am logged on to the drive." If someone can access your encrypted drive(s) while you're logged in, that seems like a much bigger issue to me than a plain text file.There was a situation last year where another user had her password stolen from her. Since the password is stored unencrypted, it is believed that one of her employees who was using the application copied the data from this file and then used it to "assume" the user's identity and set up another shop with stolen information.

There is currently no way to hide this information when someone is using the application since the application and the data files must be accessible. Thus, even if the application and the associated data files are on an encrypted drive, the drive needs to be unencrypted for the application to run. I see no reason why the password needs to be visible, though, and in my testing, as long as the file can be written to, the application performs normally, the application never attempts to read from it.

I agree this is a hokey application with a hole this huge.

[wilderness]

Unfortunately, the attribute I am looking for is for the file to be unhidden and able to be written to but not able to be read.

as headhawg pointed out, no such capability exists in 'attrib'


Are you familiar enough with these commands to give me the syntax I would use? I believe I've done this in Unix, but never in a DOS or Windows environment.

attrib commands are rather simple (http://www.google.com/search?hl=en&source=hp&biw=&bih=&q=dos+attrib&btnG=Google+Search&gbv=1)

The attrib command doesn't encrypt. If you are suggesting FW use the +h argument to hide the file, that will be overridden if "Show all files..." is enabled in Windows Explorer. (You can change file attributes without using attrib anyway.)

It may seem presumptuous, however since the advent of Windows OS, the majority of users are NOT even aware of Windows Explorer. Just ask a few! Most don't even know how to open it, or that it may be opened with a simple keyboard command.

There are multiple other ways to mask files so that general users would simple refuse (security) to open.

[FocusWiz]

There are multiple other ways to mask files so that general users would simple refuse (security) to open.If I had written the application, I would have likely simply converted it to an encrypted archive file or somehow converted it to a hex version of the same information (and then unconverted it when reading it). However, I am neither the application developer nor the vendor, I am merely a user who wants to have this less viewable than it currently is when the application is running.

I have the drive it is on encrypted, so without that password, the entire drive is inaccessible. However, the issue is that the drive must be decrypted and available in order for the application to run. The application does not need this password to run in general and in fact the vendor has it masked in the entry screen where it is stored. However, this vendor is a bit stupid and then writes this masked data to a text file when accessing their online database.

I admit their design is garbage, but I am trying to protect my password from prying eyes and am wondering if anyone has used the one product I have thus far found which might provide this feature.

If you know of another way, I am all ears.

[headhawg]

It may seem presumptuous, however since the advent of Windows OS, the majority of users are NOT even aware of Windows Explorer. Just ask a few! Most don't even know how to open it, or that it may be opened with a simple keyboard command.Huh? Are you suggesting that they are using a command prompt? If you're saying that they don't know that it's called Windows Explorer...ok...I'll buy that. And the majority of users may click on the Start button, but I also know a lot of users who are not computer-savvy that double-click on (My) Computer to open their drives. That action, of course, opens Windows Explorer.

[wilderness]

I've no idea how sensitive the data is that your attempting to secure?
Whether its personal or business!
Why not just place the data on website, and within a directory that denies access to all except your IP and browser footprint (i. e., multiple conditions via htaccess)?

[headhawg]

FW,

So you need to protect the text file created after accessing the db? Can you delete it after the app is closed? I guess I'm not following when someone can see the file if you're not using the app and/or logged off.

[wilderness]

Huh? Are you suggesting that they are using a command prompt? If you're saying that they don't know that it's called Windows Explorer...ok...I'll buy that. And the majority of users may click on the Start button, but I also know a lot of users who are not computer-savvy that double-click on (My) Computer to open their drives. That action, of course, opens Windows Explorer.

No not command prompt.
The majority of general users are without clue as how to navigate directory structures (explorer or prompt).

Although Explorer and My Computer function the same, they are different creatures. (I detest My Computer and never use it.)
Most users don't even know where (directory) they have saved a downloaded file to.
A few users actually learn the default for saving files is 'My Documents', and dump everything there, which is absurd. Rather, than creating their own structured directories.

[FocusWiz]

I've no idea how sensitive the data is that your attempting to secure?
Whether its personal or business!
Why not just place the data on website, and within a directory that denies access to all except your IP and browser footprint (i. e., multiple conditions via htaccess)?The vendor places their file in a directory under their main directory. I have no control over this vendor and have tried to talk sense to them before. I would love to implement any of a dozen solutions that I can think of but I am forced to look for ways to fix their terrible design. This is a business application and in their line they are the fifth or sixth largest vendor of that application.

In Unix, I could probably grant read and write access by application and limit it to the program that writes to it (if I could figure out which module actually does the writing). In a pure DOS environment, I might be able to use batch files to decrypt the file before running the program that writes to it and then encrypts it again after the program is done. Unfortunately, I am unable to use such approaches since I have no such control over this application nor the environment in which it was designed to run.

[FocusWiz]

FW,

So you need to protect the text file created after accessing the db? Can you delete it after the app is closed? I guess I'm not following when someone can see the file if you're not using the app and/or logged off.Thanks, HeadHawg,

What I have is an application that I might be using for several hours at a time during the work day (which could be a dozen hours long). I am not sure if this file is required to be there at all times, but I suspect it is only required when this local application "talks" to the vendor's servers (to transmit data to them or to retrieve data or updates from them). I have some suspicions as to which dlls are used for some of these activities, but I am not entirely sure when this file is created and when it might be otherwise used. Hence, the text file is there from the time I log in until I actually use some operating system command to delete it.

The file is a pure text file (actually, there are two in this year's software) that seems to track when and how I've communicated with their servers. It contains date and time information, but it also contains my UserID and Password. From my inspections, it seems to "talk" when I start the application and any time I interact with their servers. I am not sure, but I think if I were to delete the file, they would recreate it at their whim with this information. Interestingly, they do store the UserID and Password in an encrypted file within the application (and when entering the password it is replaced on the screen with asterisks), but then they stupidly copy it to a text file when it is used.

I could conceivably compress/encrypt the directory itself and modify the startup commands to decrypt/expand them when I start and re-encrypt/compress them when the application ends, but there are times when this application may abend and I would need to be careful to track that so as not to overwrite something. However, even with this solution, this file would be sitting on my hard drive unprotected and unencrypted while I am using the application.

If I had another employee using the application, they would never need to actually use nor even see the UserID nor the Password to use the application (each employee could be given their own login access to the application), but they would need these if they wanted to install and use this application (illegally) on their own machine. Hence, I do not want these secure pieces to be available for copying (either by machine or by hand), since that usage would then be traced to me possibly violating my license agreement.

I imagine I could run a batch file that continuously deletes the file and see if there is any impact on the application. As I think of it, since I have not seen evidence that the application actually "reads" the file, this alternative may work.

Not sure I want to have a batch file continuously looping in the background, but that would be a cheaper way to handle this if it works. If I did that, I would probably rename it with a date and time and add it to a compressed archive to find out how often it is created, too.

[headhawg]

Although Explorer and My Computer function the same, they are different creatures. (I detest My Computer and never use it.)
Um...no they're not. Windows Explorer opens when the user double-clicks (My) computer. The only difference what is shown in the window. By default, Computer will show drives/devices when opened, and Windows 7 for example opens Libraries. Same app, though -- Windows Explorer.

[headhawg]

I could conceivably compress/encrypt the directory itself and modify the startup commands to decrypt/expand them when I start and re-encrypt/compress them when the application ends, but there are times when this application may abend and I would need to be careful to track that so as not to overwrite something. However, even with this solution, this file would be sitting on my hard drive unprotected and unencrypted while I am using the application. Sounds like encryption really doesn't help. The solution might be a password-protected folder. However, the application won't know the password so if it needs access to the file that's going to be a problem. Seems like you would need to delete the file on a regular basis. You could use a batch file with a timer to delete (or even just hide) the file. Or just do it manually. Your options seem very limited if the app always creates the plain text file and needs to read/write to it.

[GameTheory]

Encrypt the entire program, i.e. create an encrypted virtual drive, put the program and its unsecure files on it, and only access the virtual drive when using the program and when you're not, unmount the drive and nobody can get to it...

[FocusWiz]

Encrypt the entire program, i.e. create an encrypted virtual drive, put the program and its unsecure files on it, and only access the virtual drive when using the program and when you're not, unmount the drive and nobody can get to it...I am sorry to be long-winded, but the problem is that this secure information would be accessible while someone is using the program (although it is not useful to them for any reason except to steal my identity). I am trying to keep the password secure while the program is being run; it is very easy to keep it secure when the program is not being run, as you noted.

[FocusWiz]

Sounds like encryption really doesn't help. The solution might be a password-protected folder. However, the application won't know the password so if it needs access to the file that's going to be a problem. Seems like you would need to delete the file on a regular basis. You could use a batch file with a timer to delete (or even just hide) the file. Or just do it manually. Your options seem very limited if the app always creates the plain text file and needs to read/write to it.Thanks.

The application has the password stored rather securely in one of its encrypted data files. I do not think it actually reads it from the text file, but writes it there for reasons unbeknownst to me whenever it communicates with the company's servers.

I think I may need to just constantly delete this file with a set of scripts but I suspect that the IObit utility I referred to above will be the "lazier" alternative. In my tests, it adequately prevented any attempts I made at opening/viewing the file in any normal tool (NotePad, NotePad++, Word, Quick View, Excel) and I could not copy it with Explorer, Directory Opus, Power Desk, or a command prompt. However, the test was somewhat limited and I am not sure I want to pay for an annual subscription just to be able to run it.

I have some questions in to IObit to find out what happens if they go out of business and my subscription runs out, but was wondering if anyone had any experience with their products or anything else that provides write access but restricts read/copy access. From my tests, uninstalling it removes any restrictions I may have placed on the files since it apparently adds hooks into the operating system that are removed when it is uninstalled.

[headhawg]

Why don't you try another program that doesn't require a subscription? I found this one: Folder Guard (http://www.winability.com/folderguard/)

I'm sure there are others.

[FocusWiz]

Thanks, Headhawg, I have an email in to them to ask them if they can achieve this with their tool.

However, there may be an easier (or at least cheaper) alternative than I thought. I apologize for overcomplicating this.

I was perusing documentation of the Icacls functionality and I realized that this tool is affecting the advanced permissions of users. While this may not be totally foolproof, if I were to set the permissions of a user to write only, the data could be written but not read.

In my simple tests, I was able to set the permissions so that the file is viewable in a directory list, but could not be opened in notepad or wordpad and could not be TYPEd from a command prompt. However, an ECHO command could be piped into the file to update it. Here are the permissions set up for a test file and I think this may be what I need:

Basic:
Full Control: NO
Modify: NO
Read & execute: NO
Read: NO
Write: YES
Special permissions: YES

Advanced:
Full Control: NO
Traverse folder / execute file: NO
List folder / read data: NO
Read attributes: YES
Read extended attributes: YES
Create files / write data: YES
Create folders / append data: YES

Write attributes: YES
Write extended attributes: YES
Delete: NO
Read permissions: YES
Change permissions: NO
Take ownership: NO

I was able to pipe data to this file using a batch file with an ECHO command but was not able to open it in any of the applications I tried to use (which is the behavior I believe I need). It appears on directory lists and in Windows File Explorer (but not in the preview window). I am hopeful that I do not need to allow the file to be deleted.

The Icacls command would be better to automate this so that I have the same permissions built for each such file on each computer, but realistically it may not be necessary. I just need to figure out the correct combination and manually clone that to each machine for each of these files.

Of course, if the file needs to be deleted and re-created by the application, I would need to allow deleting, but then I would likely lose the security. I guess I need to keep testing.

[GameTheory]

Are the people that are going to be stealing this file (hypothetically) sitting at your machine using the program? If so, yeah, only so much you can do with something fundamentally insecure. And of course if they have physical access they can do much nastier things than that such as infecting it with malware, keyloggers, etc. Is this file literally the only thing on your machine that you don't want seen/manipulated by others? Seems to me in that situation you either have to trust the people around or they shouldn't have access at all.

[headhawg]

Yes, I believe that you could do this with permissions. If you're the only admin, then give System and Administrators Full Control. Do users need to even Write to this file? If not, just take them out of the ACL and they will get an implicit deny. You can set the ACL at the file level so it won't affect the rest of the folder if you want.

[FocusWiz]

Are the people that are going to be stealing this file (hypothetically) sitting at your machine using the program? If so, yeah, only so much you can do with something fundamentally insecure. And of course if they have physical access they can do much nastier things than that such as infecting it with malware, keyloggers, etc. Is this file literally the only thing on your machine that you don't want seen/manipulated by others? Seems to me in that situation you either have to trust the people around or they shouldn't have access at all.In the one situation I have learned about, the identity of the owner was stolen by use of this file which allowed the crook to steal other information. I agree that a more sophisticated individual could do much worse, but it does not appear that this person knew much more than how to use windows file explorer. I have a friend who is a security consultant and his motto is "security is achieved when all work stops" so I realize I cannot protect myself from everything, but I do not want it said that I did not take reasonable steps to protect this information. Having an ID and a Password in a text file is usually the second or third things on the lists of security "no-nos."

[FocusWiz]

Yes, I believe that you could do this with permissions. If you're the only admin, then give System and Administrators Full Control. Do users need to even Write to this file? If not, just take them out of the ACL and they will get an implicit deny. You can set the ACL at the file level so it won't affect the rest of the folder if you want.I believe that the application will use the encrypted and stored password to access the server periodically and then write to the file for logging purposes. Whether denying write would adversely affect the application is something I would need to test.

I will likely only set this up for the dozen or so text files that have this password information exposed.

Thank you for the lively and helpful dialogue. I really appreciate your thoughts and the ideas that others have expressed to help me crystallize my thoughts on this.