View Full Version : Password-protect folders?
08-23-2006, 03:24 PM
I've been asked if it's possible without encryption or third-party applications to password-protect a folder in Tiger. I'll assume since the question was even raised that the folder is outside the User's folder. Anybody have any ideas?
08-23-2006, 04:24 PM
I think the only way to have a password protected folder (without using encryption) is to use a Folder Action, which is very very very very VERY unsafe to password protect something with, as it can easily be worked around.
Or you can just use an encrypted disk image. A disk image is built into Tiger, and mounts like a 'virtual CD'.
Without encryption, there really isn't a point to have password protection!
08-24-2006, 01:55 AM
You can make a new image with AES-128 encryption in Disk Utility.
You do need encryption. It doesn't take time.
08-25-2006, 09:23 AM
So, how do I creat the DI from the folder concerned please?
08-25-2006, 09:38 AM
As cocoanewbie said, use Disk Utility (in Applications:Utilities).
Just click on the New Image icon and choose where you want it, select the size you'd like, set encryption to AES-128, leave the format at read/write, click create, and enter the password. Then put your files/folders in the image. When your done, eject the image. From that point on, opening it will require the password.
Edit: There is NO back door, so don't lose the password.
10-05-2006, 07:07 AM
I've created a disk image (from a folder) because I want it pass-protected. Followed cwtnospam's instructions verbatim.
Unfortunately it seems like because I'm logged in with Keychain (which I dont want to change, because I don't want to re-enter the pass for every browser password requirement etc), it doesn't ask for a password when I try and mount it.. well, it doesn't because I'm 'currently' logged in with Keychain.
Is it possible to make the image password-protection seperate from Keychain, or change some other setting, so that it ALWAYS requires a password to mount it?
10-05-2006, 08:12 AM
Unfortunately it seems like because I'm logged in with Keychain (which I dont want to change, because I don't want to re-enter the pass for every browser password requirement etc), it doesn't ask for a password when I try and mount it
When you created the encrypted disk image, I think it asked you (via a checkbox) if you wanted to store the password in your keychain. You want to say no.
You should be able to remove the password from your keychain by using the Keychain Access utility.
10-05-2006, 08:13 AM
When disk image is being created, you should have been asked for the password setting. In the window, titile "Authenticate", you can type in any password you want.
Maybe you typed in your Keychain log-in password there, where you can type in anything. Did this help?
10-06-2006, 06:33 PM
Thank you! Yes, this worked! I just re-creating the disk image from my folder, this time making sure not to have it use Keychain for it (the checkbox).. now it asks for my password every time.
10-06-2006, 10:04 PM
does sudo chmod not effect encypted image folders? I only ask this, because I have never tried it.
10-07-2006, 09:01 AM
chmod changes permissions, so it might (I haven't tried it either) make an image read-only, but it won't affect the encryption.
Suppose one simply created a new user with a quixotic password and stored sensitive documents in the new user's documents folders. One could use fast-user switching to access the folder (and perhaps have a common shared folder for moving documents that you need for the other user's access). This would produce an essentially password-protected, non-encrypted folder, which was what was originally asked for, I think.
I don't offer this as a superior solution to the encrypted disk image, (although encryption always carries a greater level of risk of corruption than normal files); I just wonder if that would be a lazy-man's solution to the question raised.
10-07-2006, 11:52 AM
Well, then anyone with administrator or root access could get your files.
yes, but only if the administrator changes the password, in which case you'd know something had happened. If soemone has root access, that might be a different matter. But if the ADMINISTRATOR of the machine can't be trusted, maybe there are bigger issues.
10-07-2006, 01:43 PM
well thats the thing...
Every admin has root privlidges via /etc/sudoers
I do agree with JDV though, if you have a system's administrator you can't trust you have problems to begin with.
10-07-2006, 01:52 PM
(although encryption always carries a greater level of risk of corruption than normal files)
This implies that the contents of a file have some bearing on the risk of corruption. I don't think that's true.
I'd guess that the larger file the greater risk because it covers more sectors on your drive.
Perhaps you mean recovering the data from a corrupt encrypted file is harder (if not impossible) because of the nature of the encryption?
Assuming the disc image is not too big, there's no reason why multiple copies could not be made to protect against corruption.
I didn't mean to imply that the contents of a file, per se, increased the possibility of corruption. But an encrypted file has to be de-crypted in some way in order to be read and modified, and then re-encrypted. This seems to me to multiply the chances for an error to occur. Since a disk image will contain multiple files, that image will be being manipulated a lot. It certainly IS true that recovery from a corrupted encrypted file/directory/image is much harder, of course, which is one reason that some of us are less than enthusiastic about using File Vault for the user folder of a machine.
To amplify my point about an untrustworthy administrator, if that was an issue and he/she discovered an encrypted disk image that he/she could not inspect, they could simply (as tlarkin points out) -delete- the offending disk image from terminal using their root priveliges. I was making the initial assumption that the administrator was the main user who simply wanted some way of keeping some files from casual inspection of someone to whom he had granted (or who too) temporary physical connection to the computer, not necessarily with malicious intent.
I'm no crypto-expert (in fact, I don't seem to be an expert at anything, come to think of it), so my reasoning may well be wrong and bramley's point correct regarding the dangers of encryption; if so, my apologies for being an alarmist.
vBulletin® v3.8.7, Copyright ©2000-2014, vBulletin Solutions, Inc.