How many times do you have to write zeros or random data to a drive to securely delete data?

Conventional wisdom says that you need to do many passes of zeros, ones, combination of zeros/ones, and then random numbers in order to securely erase a drive so that its data cannot be recovered. But is this true?

The folks at HowToGeek make a good case for one pass of zeros being enough:
HTG Explains: Why You Only Have to Wipe a Disk Once to Erase It

From StackExchange, here is a shorter sum-up of the situation, though:
StackExchange answer to "Why is writing zeros (or random data) over a hard drive multiple times better than just doing it once?"

And an even shorter tl;dr version:
Summary: it was marginally better on older drives, but doesn't matter now. Multiple passes erase a tree with overkill but miss the rest of the forest. Use encryption.

The bottom line seems to be that there are some misinterpretations or misapplications of the Gutmann method, but more importantly that it's all about what can be done in theory. When it comes to practice, a single wipe of zeros is pretty much enough to take care of any basic data recovery methods.

If you're dealing with highly sensitive data, it probably still won't be recovered in any meaningful way after a single wipe of zeros, but you may not want to chance it, and end up doing several passes of zeros, ones, and then randoms, in addition to physically incinerating the drive.

DBAN's "autonuke" setting does three passes, and the nice thing about DBAN is that you can use it on pretty much any computer (it's a live CD or USB—so good for Windows, Mac, or Linux).

Mac OS X's Disk Utility has several built-in options.

securityoptions01
If you launch up Disk Utility, select the drive you want to delete, and then click Erase, and then Security Options..., you'll see a pop-up window with a slider.

securityoptions02
The first option doesn't do a secure wipe at all. It just "deletes" the data by marking it available for use.

securityoptions03
The next option will be secure enough in 99% of use cases (e.g., you have a personal computer with family photos and other personal documents that will not financially benefit any criminals or politically benefit any governments).

securityoptions04
This third option is about the same as the "autonuke" setting for DBAN.

securityoptions05
And this last option—according to Gutmann himself, to HowToGeek, and to a bunch of other folks who've examined the issue closely lately—is just overkill.

A lot of the discussion you'll read in the links I posted above have to do with theory (could someone with limitless time and really expensive equipment possibly recover some tiny scrap of data from your hard drive) and a lot less to do with practicality. More importantly, it's difficult to track down actually successful (and verifiable) experiments of the theory [that traces of previous data exist even when you zero out everything or write random data over the previously existing data].

Practical security focuses a lot more on how badly criminal elements want your data and how difficult you make it for them to get to the data. If all a criminal gets is unusable scraps of what might have been a text file, and all that's really on the drive to begin with is some music, family photos, and Word documents, who is really going to spend hours trying to get that stuff back?

If, however, I have a computer with millions of people's financial data or with highly classified military documents... I'm probably going to do at least three passes before totally incinerating (Terminator 2–style) the drive. And that drive would have been fully encrypted to begin with.

As a simple, practical test, though, I did the second Disk Utility setting (one pass of zeros over the entire disk) on a 500 GB drive. Then I did data recovery on it using both Photorec and Recuva.

Here are the results...

photorec01
Photorec took about 10 hours to scan the 500 GB drive, and it came up with 3 files—three .plist files and one .xml. I'm not 100% certain, but I believe those might be created by OS X itself when formatting the drive to HFS+

recuva01
Recuva took a little over 2 hours to scan the 500 GB drive, and it came up with 3 files. Again, not 100% certain on this, but I believe those may be hidden files created by Windows when formatting the drive to NTFS (Recuva wouldn't recognize an HFS+ drive, so I had to use Windows' disk management to reformat the drive as NTFS before scanning).

If you're inclined to say 3 passes isn't enough...

  1. Make sure you know what you're disagreeing with. I am not (nor is the StackExchange response or the HowToGeek post) saying that a drive with highly sensitive documents should be disposed of after a single pass of zeros. Those should have been encrypted to begin with, have three passes, and then be incinerated. But doing the full 35 is overkill and, worse yet, doesn't offer any additional security over the three passes. So if you're going to disagree, disagree with the correct assertion. Don't engage in any of this business.
  2. I am, however, saying that for a basic home user with no extremely sensitive information (maybe some family photos and a handful of documents with no financial information), you can safely dispose of a drive after doing a three-pass on it (and, most likely, even a one-pass).
  3. Don't say "I have software that can easily recover one-pass deletions" without saying what software you use. I used Photorec and Recuva. If you believe another piece of software can actually recover data that's been wiped, say what software it is, and then prove that using it you were able to recover usable data after a one-pass or a three-pass.
  4. If you can recover fragments of data that are totally useless, who cares? If it's a text file, it has to have readable text. If it's an image file, it has to be a viewable image. You can't just prove that there used to be "in theory" data there previously, but it's data you can't recover.

I'd love to hear that I (and the wise StackExchange user, and Gutmann, and HowToGeek) are all wrong, but if that's the case... prove it.

Further reading:
Securely disposing data on hard drives and other storage media
The urban legend of multipass hard disk overwrite and DoD 5220-22-M
Overwriting Hard Drive Data: The Great Wiping Controversy

Fix for disk erase failed couldn’t unmount disk

If you're trying on a Mac using Disk Utility to erase a hard drive and it won't unmount, giving you an error similar to Disk erase failed. Couldn't unmount disk, then you may have to force an unmount through the terminal.

Launch up Terminal.app (through /Applications/Utilities or through a Spotlight search).

Then paste in the command:

diskutil list
to list out the different disks. You should see some disks appear like /dev/disk0, /dev/disk1, /dev/disk2.

Find the one you want to force unmount. For this example, let's say it's /dev/disk2.

Run a command similar to this one

sudo diskutil unmountDisk force /dev/disk2
If you're prompted for a password, enter it (yes, your account does need to have administrative privileges). You should not physically unplug the drive.

You should now be able to erase the drive.

Running sudo commands in Automator

If you're wondering how to run sudo (for privilege escalation) commands in Automator, this is one way to do it.

Launch up Automator (of course).

sudoautomator01
Find Run AppleScript in the library of actions.

sudoautomator02
Then, drag it over to the workflow area on the right. By default, Automator will put in some script structure for you to work with. Feel free to just delete that all completely.

sudoautomator03
In place of the predefined script, put in

do shell script "sudo whatevercommandyouwanttorun" with administrator privileges

if it's one command you want to run.

If you would rather run a script, it's a similar syntax of

do shell script "sudo /path/to/youractualscript.sh" with administrator privileges

sudoautomator04
You can save your workflow as an application.

sudoautomator05
When you double-click your .app file, it should then prompt you for an administrator username and password and then run your bash command or shell script in a sudo-like way.

Fix ownership of copied folders for Active Directory Macs

Warning

This script does some serious system modifications. If you don't know what you're doing, ask questions in the comments. Don't just run this script if you don't understand what it does or how it's doing it.

This also assumes short usernames match up with user folder names, which they usually do.

What issue this addresses

I'm not sure how often other people will encounter this situation, but if you have an old Mac joined to Active Directory, and you want to transfer the user folders (assuming they are local user folders) to a new Mac also joined to Active Directory, the copied folders may not have the right folder ownership. For example, if you use an admin account to copy the folders over, the copied folders may belong to root.

So when users log in, they may have folders they can't get access to, or you may get the OS X needs to repair your Library to run applications. Type an administrator's name and password to allow this error message when you log into the new Mac as a domain user who'd already logged in on the old Mac.

How you should modify this script before running it

The script is written in such a way that it will not try to change ownership of certain system accounts (e.g., root, Shared, Guest). You can add in others as you see fit.

It also assumes, since you're on a domain, that the proper group for domain users is YOURDOMAIN/Domain Users. Modify to your actual domain, accordingly.

Creating the script

As an admin user, launch up Terminal.app (you can use a text editor, but if you don't have a favorite text editor like TextWrangler or Sublime Text, the built-in text editor in Mac OS X may default to rich text format instead of plain text). You can find Terminal.app in /Applications/Utilities or through a Spotlight search.

Paste in the follow command:

nano ~/Desktop/fix\ folder\ ownership.sh

This will open up in a terminal-based text editor a file in which you can paste the script.

In nano (or your favorite text editor, if you opted for a graphical text editor instead of a terminal-based one), paste in the following script:

#!/bin/bash

# Announce what this does
echo 'This script will make sure users own their own user folders. This will not modify the Shared user folder, the root user folder, or any of the admin/admin2 folders.'

# Change directory to the Users directory.
cd /Users

# Loop through the existing users
for p in *; do

# Don't do this for the Shared user, root, or any local admin account...
if [ "$p" != "Shared" ] && [ "$p" != "root" ] && [ "$p" != ".localized" ] && [ "$p" != "Guest" ]; then

# Announce changing folder ownership
echo -e "Changing folder ownership for $p"

# Change ownership to the current user with the group being the domain users group
#sudo chown -R "$p":"YOURDOMAIN\Domain Users" /Users/"$p"/

# End checking it's not a user not to be modified
fi

# End looping through existing users.
done

Modify the script before you save

Before you save the file, make the modifications you need. You'll see that there's a line excluding modifications for Shared, for root, for .localized, and for Guest. If there are any other user accounts you don't want to modify ownership on, add those into that line as well, using the same format (copy everything from the ampersands through the closing bracket, and then paste it before the semi-colon and then modify the username).

Also, change YOURDOMAIN to your school or company's actual domain name.

Save the file and get it ready to run

Save the file (if you're using nano, press Control-X to save).

Then, to make the file executable, paste in the following command:

chmod +x ~/Desktop/fix\ folder\ ownership.sh

Testing the script

Before using the script to actually modify anything, run it once with the change ownership line commented out (that's how it defaults to above).

cd ~/Desktop
./fix\ folder\ ownership.sh

Verify that the users that are listed are the actual ones you want to modify. Look very carefully at the list!!!

Running the script for real

If you feel confident about the list, modify the script so it will actually make the ownership changes. (By the way, you may need network connectivity to connect to Active Directory, or you may get warnings about illegal user names or illegal groups.)

Edit it again:

nano ~/Desktop/fix\ folder\ ownership.sh

Change the commented-out line:

#sudo chown -R "$p":"SIPREP\Domain Users" /Users/"$p"/

So it will now be uncommented out:

sudo chown -R "$p":"SIPREP\Domain Users" /Users/"$p"/

Then save (Control-X)

Then run the script again, and it should actually change the folder ownership:

cd ~/Desktop
./fix\ folder\ ownership.sh




For internal use

How to find the IP address of a printer on a Mac

If you have a printer already installed on your Mac, but you just want to find the IP address, this is one quick way to do it without printing out a test page and wasting paper / ink.

findprinterip01
Click on the Apple logo and then select About This Mac.

findprinterip02
Click on System Report....

findprinterip03
In the left-hand column, under Hardware, select Printers.

Find the printer you want more information about, and then click on that printer. You should see the IP address next to URI.

Authentication failed on changing admin accounts for ARD machine

I encountered an odd thing. I had ARD set to remote into a few workstations. I was doing some account cleanup on them and changed the admin accounts. In System Preferences Sharing, I still had it that all admins could remote in, but after deleting an admin account and adding a new one, I couldn't remote in with the new one.

There is a way to refresh it, however, which I found here. You ssh into the remote machine, and ten paste in these two commands:

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -deactivate -configure -access -off
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -restart -agent -privs -all

You should then be able to use ARD to remote in again.

Reset Printing System on Mac

If you're having printing issues with multiple printers (not just one or two), you may want to reset the printing system (Warning: this will remove your installed printers, and you'll have to install them again).

resetprintingsystem01
Go to System Preferences.

resetprintingsystem02
Select Printers & Scanners.

resetprintingsystem03
Right-click on a printer and then select Reset printing system....

Re-add the printers.

Get back the old Numbers default Print View

One of our users likes to see a print preview by default in Numbers. This was available in the older version of Numbers, but it's gone from the newer version of Numbers.

Unfortunately, the most viable solution for this is just to keep using the old version of Numbers.

numbersprintview01
If you're complaining about this issue, you likely already have the older version of Numbers. It will appear in the /Applications/iWork '09. If you don't have it, you also likely don't have this issue (because you're used to using only the new version of Numbers).

numbersprintview02
If you have an already-saved document that you want to open in Print View by default, go to File > Export To > Numbers '09

numbersprintview03
Just click Next.....

numbersprintview04
Name your exported document. Click Export.

numbersprintview05
Right-click on the exported file and select Get Info (for you keyboard shortcut–wedded folks, that's Cmd-I).

numbersprintview06
Find the Open with: section and then select Numbers.app (2.0).

numbersprintview07
Click Change All... and then click Continue.

numbersprintview08
Click View > Show Print View.

/System/Library/Keychains empty… and repercussions

The issue

We ran into a weird situation once, in which a user could not update anything. Trying to update Adobe Flash ended in an immediate error (Application Initialization Error), launching the Mac App Store led to the App Store saying it couldn't be contacted, and Chrome saying it was updated when it was several versions behind. Pretty much anything that had to contact a server for updates... couldn't.

The solution

After rebooting, checking for malware, failed proxy connections, and a bunch of other potential issues, we found out that the /System/Library/Keychains folder was empty.

So we copied the contents of that folder from another Mac, and then, magically, everything worked!

Very obscure issue and obscurer solution. Thanks to J. Pruden for finding it!

Exporting GarageBand to Google Drive on the iPad

When you try to share a GarageBand project out from the iPad, the immediately apparent options may include only Facebook, SoundCloud, and YouTube (yes, even if you select the More option).

If you want to export your project to Google Drive, you may have to take a few extra steps.

export garageband to google drive 01
Select your project by either tapping Select or long-pressing on the project icon itself.

export garageband to google drive 02
Once it's selected, click the share button (looks like an up arrow pointing out of a rectangle).

export garageband to google drive 03
Select Open in...

export garageband to google drive 04
Before you can select what to open the project in, you'll have to fill in some details about the song. Fill those in.

export garageband to google drive 05
Then you should see a lot more applications appear to share it in, including Open in Drive. You may have to do a bit of horizontal scrolling to get it to appear, depending on how many shareable-to apps you have installed.

export garageband to google drive 06
Once Google Drive opens, you'll then be prompted to upload the song. Select Upload.