Encrypted disk image access privileges

Hi,
I use an encrypted disk image to store my important documents.
It remains mounted most of the time because I keep accessing or modifying files there (but at least, I know they're not accessible to anyone stealing my machine, plus if feel more secure uploading the whole image disk for backup purposes and in some contexts, I am careful to unmount the disk image).
It is stored on a Mac that I occasionally share with other people.
I have noticed that when these other people log into their account, they have access to the content of the mounted image disk.
Does anyone know a way to prevent that access? I have already tried removing all access privileges to any users, both on the disk image file and on the mounted volume but that did not change anything at all (only I and the special user "staff" have any privileges to the file and the mounted volume).
Does anyone have any idea how I can get MacOS X to hide the volume to any other users than me?
Thanks!

Where is it stored – in your home folder?
Select your_image.sparsebundle (may have a different file extension)
press command + i
set permissions
     me r+w, staff r (is fine), everyone no
mount the volume (doubleclick)
press command + i
set permissions
     me r+w, everyone else no
uncheck
     ignore ownership

Similar Messages

  • Various disk actions ask for the PW to my encrypted disk image, even though I'm not accessing this.  Help

    I have a small portion of hy hard drive set aside as an encrypted disk image.  Since installing OSX Lion, various actions that dont require access to that disk image (printing to PDF, opening Aperture) ask for the password, and wont do anything til I provide that password.  Has anyone else run into this, or more importantly, found a solution?
    Thanks
    Ted

    See Here for Troubleshooting
    Free Disc Space
    http://www.thexlab.com/faqs/freeingspace.html
    See Here for Resolving Startup Issues
    http://support.apple.com/kb/ts1417

  • Encrypted disk image on external drive prevents that drive from ejecting

    I've tested this a few different ways, and it seems to be a rather consistent problem.
    I have an external USB hard drive (seagate) and on that drive I use encrypted disk images to store my data.
    (because it's a portable drive, I'm nervous I'll lose it and then someone will have access to my stuff).
    So anyway, whenever I mount the sparse bundle disk image, when it comes time to eject the drive (after ejecting the disk image of course), it hangs for a while and then the Finder says it can't eject, but that I can Force Eject the drive.  When I chose to Force Eject, it works, but I don't like having to force it every time.
    Anyone know what's up?
    Thanks,
    Brian.,

    Open Disk Utility > File > New >Blank Disk Image...
    or use the "Option-⌘-N" Key combo (with Disk Utlity open).
    Kj

  • Encrypted Disk Image

    Is there any way to have an encrypted disk image warn other users, upon mounting, that it has already been opened or is currently open by someone else? If not, then anything comparable?
    This whole situation arose based upon the need of having a password protected folder on the network. Someone then chose as a solution to have an encrypted disk image.
    Wouldn't several people mounting and writing to such an image simultaneously cause corruption?
    Any workarounds?

    Hi flimps,
    A couple of things...
    1. How did you create the disk image? Did you do it through Disk Utility or a 3rd party program?
    2. Are you checking the box "remember this password in my keychain" when you're creating the password or authenticating? If so, your keychain will automatically store that information and "auto fill" each time you want to access the image.

  • Lost password for encrypted disk image

    i created a encrypted disk image to store some personal files and now i can not remember my password and its not in my key chain is there a way to reset the password or at least recover the files.

    If you could access the files on an encrypted disk image without knowing the password, there wouldn't be much point in encrypting it.
    Do you remember anything at all about the password? Was it a name, or a dictionary word? If so, there might be hope of cracking it before the Earth passes away. You'd need the help of a consultant to do that.

  • Encrypted disk image no longer demands password

    Some time ago I created an encrypted disk image for storing sensitive data. It has been working fine for months, everytime I clicked on it it demanded that I enter the password before it mounted. But suddenly yesterday it stopped demanding he password and would just mount upon clicking. Tried restart, no change. Tried repairing the disk permisssions, no change. In the meantime, I have created a new encrypted disk, moved all the info to that, and secure-trashed the old one. But this gives me pause for thought. Not terribly secure! Anybody know what might have happened? How can an encrypted disk suddenly become unencrypted?

    No, there's no other explanation, unless someone tampered with your account. Launch the Keychain Access application and look for a password item in your login keychain with the name of the image file.

  • Encrypted disk image sometimes mounts without password

    I have an encrypted sparsebundle disk image containing sensitive information.  On occasion (maybe one time out of ten), I'm able to mount it without being prompted for the password.
    The password for the image is not stored in my keychain.  Can anyone offer advice on this issue?

    I was having exactly this same problem!
    I keep a small encrypted disk image storing sensitive banking information. I do NOT have the option to store passwords in Keychain checked, and I verified that the password is not being stored in Keychain.
    Yet, when I double-clicked the supposedly encrypted sparsebundle disk image, it opened right up and mounted - no password required! Unbelievable, right? So I started to investigate.
    I first noticed this behaviour in Mountain Lion, I'm running 10.8.4 on a 2.7 GHz 15" MBPr.
    In past versions of OS X I would mount the volume to work on it by double-clicking on the disk image, enter my passowrd, and then Eject the volume either by dragging to the trash or clicking the Eject button on the Sidebar. The next time I would try to access the disk image by double-clicking it, it would again prompt for a password. All good.
    What seems to be happening in ML is, using the same workflow, even though the volume is disappearing from Finder, the disk image is not actually being unmounted!
    When I go to Disk Utility, the disk image is still mounted, but the volume is grayed out. When I Eject the disk image in Disk Utility, it then reverts to the expected bahaviour, and double-clicking on the disk prompts for a password.
    So the workaround seems to be when finished working on the volume, go to Disk Utility and manually Eject the disk image (as opposed to just the volume it mounts) to ensure it has unmounted and is thus again encrypted. The reason for it sometimes requiring a password, sometimes not is probably because after a restart of the computer it would unmount all disks, and then be unable to re-mount it until the password is entered. But in between, unless you were aware of this behaviour anyone with access to the disk image can view its contents.
    What a terrible security flaw IMO, as there is no visual indication in Finder that the disk image is still unprotected after you unmount its volume and that icon disappears! I'm surprised this hasn't gotten more attention.
    Incidentally brian_c, I tried to look at your linked videos but it returns the message that the videos violated the TOS of the site...?

  • Encrypted Disk Image mounts without Password

    I've created a new encrypted disk image so that I can store sensitive documents and did it carefully, step by step,(per instructions from www.macworld.com/2425) but after I unmounted, then remount, it doesn't ask me for a password. It just mounts as if it were a regular file. Am I suppose to unmount the volume and drag the disk image to the trash? I don't know what else to try.

    The Mac uses and encrypted database of keys called the "Keychain". When you login, it opens the "login" keychain using your login password. That keychain can be used to provide passwords for applications and services, and form data for web sites. In this particular case, the password for your encrypted disk image is being stored in the keychain and automatically provided.
    If another user attempted to open the disk image, the disk image mounter would first look in his keychain and then the system keychain for a key to open it with. Finding none, it would prompt the user to specify the key (password). If the user supplies the correct password, the system would put it in his keychain for safe keeping, and the user would then be able to open the image again without supplying the password.
    You can remove the key from your keychain by opening up /Applications/Utilities/Keychain Access, selecting the "login" keychain, and then looking for an entry with a name that matches the .dmg file in question. Highlight it, and then press the delete key to delete it. The next time you attempt to open it, it will prompt you for a password.

  • Password fails in encrypted disk image

    I created a 300 mb encrypted disk image using 10.4.x, about 9 months ago, now I am running 10.5.2 and everytime I try to open the image and type in the password (the correct password I have been using for years) iI get an authentification error. I know Im using the correct password, any ideas what happened here. Could the image be corupted but still want me to authenticate?
    I have not tried to open the file since Dec. 17th (via last modified date) I have check all the permissions on the eternal drive where the file is stored... also ran Techtool on the drive and found no errors... I am out of ideas...

    I have encountered the same problem on two protected disk image files as well. Once in January and then again a few days ago.
    I first thought that the first lockout was a fluke. Now after the second image lockout I'm very vary of opening another encrypted backup. I'm losing data. Even copies of the .dmg on different drives fail to authenticate. Searching for answers I found this thread.
    Is it possible that a kernel panic / forced shutdown can corrupt an encrypted file? I wonder, but my encrypted home directory (FileVault sparsebundle) is fine.
    Any insights would be appreciated.
    This is my log:
    Last login: Sun May 11 07:35:13 on ttys000
    kevin:~ kevin$ hdiutil attach -debug /Volumes/kevin/busted.dmg calling DIHLDiskImageAttach with
    agent: hdiutil
    drive-options:
    debug: true
    image-options:
    verbose: false
    quiet: false
    main-url: /Volumes/kevin/busted.dmg
    2008-05-12 18:11:17.015 hdiutil[1745:1c03] using helper tool at "/System/Library/PrivateFrameworks/DiskImages.framework/Resources/diskimages-he lper".
    2008-05-12 18:11:17.040 hdiutil[1745:1c03] connectToFramework
    2008-05-12 18:11:17.141 hdiutil[1745:1c03] sendOperationToHelper: about to ask proxy to start operation
    status proc called: initialize
    2008-05-12 18:11:17.173 diskimages-helper[1747:1603] _imageOptions: {
    "enable-keychain" = 1;
    2008-05-12 18:11:17.176 diskimages-helper[1747:1603] _driveOptions: {
    autodiskmount = 1;
    "unmount-timeout" = 0;
    2008-05-12 18:11:17.178 diskimages-helper[1747:1603] DIHelperAttach: initializing framework
    DILoadDriver: checking for disk image driver...DILoadDriver: DI_kextExists() returned 0x00000000 (0)...DIIsInitialized: returning NO2008-05-12 18:11:17.188 diskimages-helper[1747:1603] -checkForPreviouslyAttachedImage: entry
    2008-05-12 18:11:17.189 diskimages-helper[1747:1603]
    file://localhost/Volumes/kevin/busted.dmg - (null) ((null), (null)). perm=0
    DIIsInitialized: returning YESDIBackingStoreNewWithCFURL: entry with
    file://localhost/Volumes/kevin/busted.dmg
    skip-permissions-check: true
    DIBackingStoreInstantiatorProbe: entry
    file://localhost/Volumes/kevin/busted.dmg
    skip-permissions-check: true
    DIBackingStoreInstantiatorProbe: probing interface 0 CBSDBackingStore
    CBSDBackingStore::newProbe score 100 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: probing interface 1 CBundleBackingStore
    CBundleBackingStore::newProbe score -1000 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: probing interface 2 CRAMBackingStore
    CRAMBackingStore::probe: scheme "file": not ram: or ramdisk: scheme.
    CRAMBackingStore::probe: score -1000 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: probing interface 3 CCarbonBackingStore
    CCarbonBackingStore::newProbe: setting initial rval to +100
    CCarbonBackingStore::newProbe: has resource fork, +100
    CCarbonBackingStore::newProbe score 200 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: probing interface 4 CDevBackingStore
    CDevBackingStore::newProbe: not /dev/disk or /dev/rdisk (/Volumes/kevin/busted.dmg).CDevBackingStore::newProbe score -1000 for
    DIBackingStoreInstantiatorProbe: probing interface 5 CCURLBackingStore
    CCURLBackingStore::probe: scheme is
    file
    CCURLBackingStore::probe: not recognized URL scheme.
    CCURLBackingStore::probe: score -1000 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: probing interface 6 CVectoredBackingStore
    CVectoredBackingStore::newProbe not "vectored" scheme.
    CVectoredBackingStore::newProbe score -1000 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreNewWithCFURL: CCarbonBackingStore
    DIBackingStoreNewWithCFURL: instantiator returned 0
    DIBackingStoreNewWithCFURL: returning 0x00000000
    2008-05-12 18:11:17.190 diskimages-helper[1747:1603] -checkForPreviouslyAttachedImage: resolving file://localhost/Volumes/kevin/busted.dmg returned 0
    2008-05-12 18:11:17.191 diskimages-helper[1747:1603] -checkForPreviouslyAttachedImage: imageUID (
    "d234881039:i8914"
    ) shadowUID (null)
    *** testing:
    0: d234881039:i9111
    (null)
    (null)
    *** testing:
    0: d234881039:i9111
    (null)
    (null)
    *** testing:
    0: d234881039:i9111
    (null)
    (null)
    2008-05-12 18:11:17.194 diskimages-helper[1747:1603] DIHelperAttach: resolving disk image
    DIIsInitialized: returning YESDIIsInitialized: returning YESDIBackingStoreNewWithCFURL: entry with
    file://localhost/Volumes/kevin/busted.dmg
    enable-keychain: true
    image-path: /Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: entry
    file://localhost/Volumes/kevin/busted.dmg
    enable-keychain: true
    image-path: /Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: probing interface 0 CBSDBackingStore
    CBSDBackingStore::newProbe score 100 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: probing interface 1 CBundleBackingStore
    CBundleBackingStore::newProbe score -1000 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: probing interface 2 CRAMBackingStore
    CRAMBackingStore::probe: scheme "file": not ram: or ramdisk: scheme.
    CRAMBackingStore::probe: score -1000 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: probing interface 3 CCarbonBackingStore
    CCarbonBackingStore::newProbe: setting initial rval to +100
    CCarbonBackingStore::newProbe: has resource fork, +100
    CCarbonBackingStore::newProbe score 200 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: probing interface 4 CDevBackingStore
    CDevBackingStore::newProbe: not /dev/disk or /dev/rdisk (/Volumes/kevin/busted.dmg).CDevBackingStore::newProbe score -1000 for
    DIBackingStoreInstantiatorProbe: probing interface 5 CCURLBackingStore
    CCURLBackingStore::probe: scheme is
    file
    CCURLBackingStore::probe: not recognized URL scheme.
    CCURLBackingStore::probe: score -1000 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreInstantiatorProbe: probing interface 6 CVectoredBackingStore
    CVectoredBackingStore::newProbe not "vectored" scheme.
    CVectoredBackingStore::newProbe score -1000 for file://localhost/Volumes/kevin/busted.dmg
    DIBackingStoreNewWithCFURL: CCarbonBackingStore
    opening /Volumes/kevin/busted.dmg setPermission 1723
    CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
    (RW lock acquired)
    closing /Volumes/kevin/busted.dmg setPermission 1731
    DIBackingStoreNewWithCFURL: instantiator returned 0
    DIBackingStoreNewWithCFURL: returning 0x00000000
    DIResolveURLToBackingStore: processing level 1 encodings.
    DIFileEncodingNewWithBackingStore: entry for encoding level 1
    DIFileEncodingInstantiatorProbe: entry for level 1
    enable-keychain: true
    image-path: /Volumes/kevin/busted.dmg
    DIFileEncodingInstantiatorProbe: probing level 1 interface 0 CMacBinaryEncoding
    CBSDBackingStore::openDataFork: about to open /Volumes/kevin/busted.dmg
    opening /Volumes/kevin/busted.dmg openDataFork 1904
    CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
    (RW lock acquired)
    closing 3 /Volumes/kevin/busted.dmg closeDataFork 1984
    00000000: 656e 6372 6364 7361 0000 0002 0000 0010 | encrcdsa........ |
    00000010: 0000 0005 8000 0001 0000 0100 0000 005b | ...............[ |
    00000020: 0000 00a0 548a 2877 86c1 4f17 877b cf66 | ....T.(w..O..{.f |
    00000030: beea 6066 0000 1000 0000 0002 780e 1734 | ..`f........x..4 |
    00000040: 0000 0000 0001 e000 0000 0001 0000 0001 | ................ |
    00000050: 0000 0000 0000 0060 0000 0000 0000 0268 | .......`.......h |
    00000060: 0000 0067 0000 0000 0000 03e8 0000 0014 | ...g............ |
    00000070: d369 cd83 75e8 bb7c 72e5 020d fdd3 68a9 | .i..u..|r.....h. |
    diskimages-helper: fileNameLength $0000006E
    diskimages-helper: resourceForkLength $60000000
    diskimages-helper: dataForkLength $00000000
    diskimages-helper: commentLength $00006700
    diskimages-helper: MacBinary III signature (0x00000000)
    diskimages-helper: header CRC $0000FDD3
    diskimages-helper: minimum decoder version $0000000D
    diskimages-helper: encoder version $00000002
    no MacBinary III signature - checking for MacBinary I or IIDIFileEncodingInstantiatorProbe: probing level 1 interface 1 CAppleSingleEncoding
    CBSDBackingStore::openDataFork: about to open /Volumes/kevin/busted.dmg
    opening /Volumes/kevin/busted.dmg openDataFork 1904
    CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
    (RW lock acquired)
    00000000: 7263 6e65 6173 6463 0000 0002 0000 0010 | rcneasdc........ |
    00000010: 0000 0005 8000 0001 0000 0100 0000 005b | ...............[ |
    00000020: 0000 00a0 548a .... .... .... .... .... | ....T........... |
    closing 3 /Volumes/kevin/busted.dmg closeDataFork 1984
    CAppleSingleEncoding::isAppleSingleFile loadAppleSingleHeader failed with error 22
    DIFileEncodingInstantiatorProbe: probing level 1 interface 2 CEncryptedEncoding
    CBSDBackingStore::openDataFork: about to open /Volumes/kevin/busted.dmg
    opening /Volumes/kevin/busted.dmg openDataFork 1904
    CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
    (RW lock acquired)
    CEncryptedEncoding::copyHeaderInformation: inBackingStore->openDataFork returned 0
    CEncryptedEncoding::copyHeaderInformation: inBackingStore->getDataForkLength (stub header) returned 0
    CEncryptedEncoding::copyHeaderInformation: backingStore data fork length is 0x0000000278100000 (10604249088)
    CEncryptedEncoding::copyHeaderInformation: reading V1 header from offset 0x00000002780FFB04 (10604247812)
    CEncryptedEncoding::copyHeaderInformation: inBackingStore->readDataFork (stub header) returned 0
    CEncryptedEncoding::copyHeaderInformation: not recognized as v1 header
    CEncryptedEncoding::copyHeaderInformation: reading V2 header from offset 0x0000000000000000 (0)
    CEncryptedEncoding::copyHeaderInformation: inBackingStore->readDataFork (stub header) returned 0
    CEncryptedEncoding::copyHeaderInformation: reading auth-entry count from offset 0x0000000000000048 (72)
    CEncryptedEncoding::copyHeaderInformation: inBackingStore->readDataFork (auth entry count) returned 0
    CEncryptedEncoding::copyHeaderInformation: reading auth table from offset 0x0000000000000048 (72)
    CEncryptedEncoding::copyHeaderInformation: inBackingStore->readDataFork (auth entry count) returned 0
    closing 3 /Volumes/kevin/busted.dmg closeDataFork 1984
    max-key-count: 1
    blocksize: 4096
    uuid: 548A2877-86C1-4F17-877B-CF66BEEA6066
    version: 2
    passphrase-count: 1
    private-key-count: 0
    CBSDBackingStore::openDataFork: about to open /Volumes/kevin/busted.dmg
    opening /Volumes/kevin/busted.dmg openDataFork 1904
    CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
    (RW lock acquired)
    closing 3 /Volumes/kevin/busted.dmg closeDataFork 1984
    CBSDBackingStore::openDataFork: about to open /Volumes/kevin/busted.dmg
    opening /Volumes/kevin/busted.dmg openDataFork 1904
    CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000002 -> 0x00000026 (locks are MANDATORY)
    (RW lock acquired)
    closing 3 /Volumes/kevin/busted.dmg closeDataFork 1984
    diskimages-helper: DiskImages secure mode enabled
    CEncryptedEncoding:unclockCANTHROW: trying to unlock with normal keychain
    UNLOCK: cannot find passphrase in keychain search list.
    UNLOCK: SessionGetInfo returned 0
    UNLOCK: sessionHasGraphicAccess
    UNLOCK: sessionHasTTY
    UNLOCK: sessionWasInitialized
    UNLOCK: using TTY to prompt for passphrase
    Enter password to access "busted.dmg":
    unlockCoreFromTTY: passphrase is wrong
    DIFileEncodingNewWithBackingStore: returning 0x00000050
    DIResolveURLToBackingStore: level 1 encoding match failed. 80.
    DIResolveURLToDiskImage: resolving backing store/file encoding failed. 80.
    status proc called: attach
    error code: 80
    status proc called: cleanup
    2008-05-12 18:11:41.081 diskimages-helper[1747:1603] DIHelperAttach performOperation: returning 80
    2008-05-12 18:11:41.082 diskimages-helper[1747:1603] -decrementBackgroundThreadCount: _backgroundThreadCount is now 0.
    2008-05-12 18:11:41.082 diskimages-helper[1747:10b] DIHelper reportresults: reporting {
    payload = {
    "result-code" = 80;
    2008-05-12 18:11:41.083 hdiutil[1745:1c03] reportResultsToFramework: proxy has finished operation
    2008-05-12 18:11:41.084 hdiutil[1745:1c03] reportResultsToFramework: results are: {
    payload = {
    "result-code" = 80;
    2008-05-12 18:11:41.084 hdiutil[1745:1c03] reportResultsToFramework: _threadResultsError is 80
    2008-05-12 18:11:41.085 hdiutil[1745:1c03] reportResultsToFramework: disconnecting from helper.
    2008-05-12 18:11:41.186 hdiutil[1745:1c03] disconnectFromHelper: removing observers
    2008-05-12 18:11:41.187 hdiutil[1745:1c03] disconnectFromHelper: terminating proxy
    2008-05-12 18:11:41.189 diskimages-helper[1747:10b] DIHelper: terminateHelper: entry.
    2008-05-12 18:11:41.190 hdiutil[1745:1c03] disconnectFromHelper: terminated proxy
    2008-05-12 18:11:41.290 diskimages-helper[1747:10b] -DIHelperAgentMaster terminateUIAgentConnection.
    DIHLDiskImageAttach() returned 80
    2008-05-12 18:11:41.293 diskimages-helper[1747:10b] DIHelper dealloc.
    2008-05-12 18:11:41.294 diskimages-helper[1747:10b] -DIHelperAgentMaster terminateUIAgentConnection.
    hdiutil: attach failed - Authentication error
    kevin:~ kevin$

  • Any gotchas for encrypted disk images?

    I am about to set up e-bills and e-statements at various banks and credit cards and wanted to check a couple of things before doing something that may end up being bad
    The assumption I am going with, is I will create an encrypted disk image to store all the PDF's.
    1. Is that the right thing to do? Or is there a better way to keep the data secure?
    2. If I do so, what is the backup impact? Can I simply set up a task to copy and paste the entire disk image to my external drive?
    3. If I want to open the disk image on another computer, can I? How will it authenticate the user/pass on a different computer?
    4. I can backup an encrypted disk image to a FAT-formatted external drive?
    5. And finally, I have read disclaimers that if I forget the password the data is lost irretrievably. But also, that the password is stored in keychain. So if the password is stored in keychain, the worst-case scenario can only happen if I forget the master password, right? I don't need to truly remember the password to the disk image necessarily, right?

    baltwo wrote:
    Your profile info indicates that you're running Tiger. If so, post to those forums. If you're running Leopard, update your profile info. What are you trying to protect and from who? Is your computer secure?
    IIRC, encrypted disk image passwords are independent from Keychain Access. So if you forget it, then you're hosed. BTW, that's the major failing with encrypted anything. If you forget the password, you're hosed. If the disk image gets corrupted, it's useless with or without the password. Anything stored in an encrypted disk image needs to be backed up in an unencrypted state and stored in some kind of physical thing like a safe. Methinks your a bit paranoid. Disable auto-login, use high-level passwords (that you remember), don't enable the root user account or activate a master password, and you should be secured enough.
    I updated the profile. I am running Leopard. So this is the correct forum.
    What am I trying to protect? I thought I put it in the first line - statements from banks and credit cards.
    From whom? From unwanted entities who may get access to my computer, in any way.
    I didn't get the part about the safe. Can I or can I not back up an encrypted disk image to an external drive "as is"? What about possibly opening it up on another computer? And how about putting it on a FAT-formatted disk? I repeat my original questions, but for a reason - they seem to have not been answered.
    I do not have auto-login, and I remember my strong login password. I don't have my root account enabled. Under this scenario you think my data is going to be secure? What about if someone were to get control of my computer? Forgive me on this one, I am a switcher so there is a general paranoia about such things which I would like to clarify before reorganizing my life.

  • Can't paste password for new encrypted disk image.

    Howdy all!
    I have been trying to create an encrypted disk image with the Disk Utility, but I'm having trouble with putting in the password.
    Using the password assistant, it only fills one of the two password fields, and I cannot copy/paste the password to the other field. If I generate a password elsewhere I cannot paste it into either box as well.
    If I switch applications from Disk Utility and come back to the password dialog the menubar says I am still in whatever application I was last (in this case it says Firefox at the very left) and the Edit menu is completely grayed out.
    Any idea how to get a non-typeable password into this dialog?
    Thanks for your help.
    Mike

    You can paste it in if you use hdiutil to create or mount the disk image (In Terminal.app). That's the
    only way to go if you use a "bullet proof monster" password like I do.
    To create an encrypted, sparse disk image, open a Terminal window and cd to the directory in which
    you want to create the image file. For example:
    cd ~/Desktop
    Then type the command:
    hdiutil create -size thesize -encryption -type SPARSE -fs HFS+ thename
    live command example:
    hdiutil create -size 1g -encryption -type SPARSE -fs HFS+ myimage
    (this will create a 1gigabyte sparse image with the hfs format with the name "myimage.sparseimage"
    #note: I love sparseimages and sparsebundles because they mount so quickly#
    Above, the size is the maximum size that the volume will ever be able to contain, for example,
    660m for 660 megabytes or 1g for one gigabyte. Note that if you want the image file to remain
    below a certain size (such as the size of a CD) you must allow for approximately 10% overhead.
    Also above, thename is the name of the image file you want to create, not the volume name.
    The volume name will be "untitled". Rename as you would any other mounted volume (after it is
    mounted).
    You will be asked for a password or phase to secure your file. In terminal you may copy and paste
    or use command + V keyboard combo. It will mount normally after that.
    I don't use the "Remember password (add to Keychain)" function because my passphrase will be
    visible in the Keychain to anyone with physical access to your computer.
    Instead I use Terminal to open my new image.
    Open terminal.app, simply type:
    hdiutil attach /path/to/imagefile
    example:
    hdiutil attach /Users/kj/Desktop/myimage.sparseimage
    (remember, you can drag and drop the file path into the terminal from Finder)
    Terminal will ask for your password, simply cut and paste from your favorite password program
    (such as "1Password").
    There is a manual page available; type man hdiutil in the Terminal.
    Enjoy,
    Kj

  • Encrypting Disk Images

    Hi,
    I've followed several guides to create an encrypted disk image so i can hide some private files on my Mac - All the guides said the same way and one was the one here on Apples site and still i have no luck.
    I create the disk image and when i put the files in it, eject the disk and try to mount the disk again from the DMG file it doesn't ask for a password. The only solution i can see is that it is because this does not work as i am admin and trying to password a file in my on account? Does this only work for shared folders with other users or is there another explanation as to why this won't work?
    Thanks

    Well Keychain is really there for your convenience. It remembers your passwords so that you don't have to enter them when they are needed but it is sort of a security risk of you just leave your mac sitting there and your keychain unlocked. However, these passwords can only be used while the keychain is unlocked. An admin password is needed to actually view the password.
    You can lock an unlock the keychain manually or have it lock automatically after a certain amount of time (in keychain access go to Edit -> Change settings for keychain "login") or when your mac sleeps. But you might want to consider the security of your mac as a whole instead of just the keychain. For example: is it easier to keep the keychain locked or is it easier to prevent access to your computer as a whole (like disabling automatic login and requiring a password from waking from sleep?).
    Steve

  • Encrypted disk image with recovery key

    I am trying to create an encrypted disk image that can also be recovered with the use of a key. It is basically trying to do what FileVault does where you have a password to get in, but there is a Master password that can recover the image if you forget/lose your password. I have pieced the basic concepts together, but it isn't working. First I create the certificates that I believe I need with a keychain using the certtool command.
    certtool y c k=SecureKey.keychain
    certtool c k=~/Library/Keychains/SecureKey.keychain o= SecureKey.cer
    I went with the RSA 1024 bit and SHA-1 stuff (that is the technically term for it).
    After that, I tried creating the image. I am in the same directory that the SecureKey.cer file is in, so that shouldn't be an issue. Also if it can't find the certificate, it tells you that. Here is the command I used.
    hdiutil create -encryption -certificate SecureKey.cer -stdinpass -type SPARSE -fs "HFS+" -volname TestVolName -size 20g TestImage
    and that returned
    hdiutil: create failed - error 0x8001184e
    Does anyone have any thoughts on what I did wrong? Thanks.

    Hi Robert,
    > Once you through a sudo in there, you lose the option
    to have a regular user
       That's not really true. Sudo is one of the most flexible commands around and not only can a regular user use it but they can use it without a password. Mind you I'm not suggesting that you make all users admins; you can specify both of these privileges for this command only. All you have to do is to put a line like the following in your /etc/sudoers file. (with sudo visudo of course)
    ALL ALL = NOPASSWD: /usr/bin/hdiutil create -encryption -certificate*-stdinpass -type SPARSE -fs "HFS+" -volname-size
    I've included wildcards so that the cert file, volume name, size and image are arbitrary but the others must be in the user's command to qualify. I realize that you'll want different options to use FileVault certs but I don't know how to do that so I used your original example as my example.
       Of course it wouldn't be that easy for your lusers to get all of those options correct so the next thing you do is to wrap the command, with it's sudo preface, in a shell script that parses the cert file, volume name, size and image from the options the user passes to the script and puts those into the command with the right syntax. If you want to get really fancy, the script could prompt the user for any arguments that were omitted. Your lusers will think that you created this really cool command and never know that sudo was involved.
    Gary
    ~~~~
       If you give a man enough rope, he'll claim he's tied up
       at the office.

  • Moving Address Book to encrypted disk image

    How can I protect the privacy of the content within Address Book and iCal? Would moving those applications to an encrypted disk image be sufficient or are there other related files located elsewhere that I need to be concerned with? Also, what would be the ramifications of not having those applications located within the Applications folder?

    If you put the files on an encrypted disc image, then you will need to decrypt them in order to make changes. Using an encrypted disc image is mostly a method for archival storage.
    You could enable File Vault which will create an encrypted version of your Home folder. This method allows you to access your data on the File Vault protected Home folder.
    If you are the only user it may be sufficient that you simply not allow anyone to know your admin password, and that you log out or shut down when the computer will be unattended. You can also create a new standard account, then log in only to the standard account. The admin account would then only be used to install software and perform other chores requiring admin access.

  • Moving iCal to encrypted disk image

    If I move iCal to an encrypted disk image, will that be sufficent to protect the privacy of the iCal content, or are there other files somewhere on the computer to be concerned about. Also, what would be the ramifications of not having iCal located within the Applications folder. Same question for Address Book.

    If you put the files on an encrypted disc image, then you will need to decrypt them in order to make changes. Using an encrypted disc image is mostly a method for archival storage.
    You could enable File Vault which will create an encrypted version of your Home folder. This method allows you to access your data on the File Vault protected Home folder.
    If you are the only user it may be sufficient that you simply not allow anyone to know your admin password, and that you log out or shut down when the computer will be unattended. You can also create a new standard account, then log in only to the standard account. The admin account would then only be used to install software and perform other chores requiring admin access.

Maybe you are looking for