7

I just came across this thread about securely deleting files:

If, by stroke of misfortune, you're on a magnetic medium, have journalling disabled and, for some reason, can't encrypt the disk, you're options are:

* Use rm -P which overwrites files with 0xff, then 0x00, and then 0xff again

And this contradictory superuser thread. Apparently it's not easy to securely delete files using Apple's older HFS+/Journaled file system.

Without the use of third-party software, is it possible to natively wipe a file in a Mac that's using APFS (macOS Mojave and newer) and FileVault encryption?

I understand macOS makes it difficult with all of its journaling and backup functionalities. But I'm looking for a shred or srm type of solution that's built into macOS already.

Improve this question
3
  • What kind of drive are you using? - Apple SSD? External old-fashioned hard drive or?
    – jksoegaard
    Sep 3, 2019 at 17:54
  • Don't bet that any of this shredding works. You need to decide how important this data is to you. Don't think people want to see you baby pictures. How much will it cost you if the data gets in the wrong hands. Spend that your dollars that way.
    – historystamp
    Sep 3, 2019 at 22:13
  • HD's, I take the drive apart, and save the magnets, they come off with a wood chisel, then stack up the platters in a pile. A good pair of tin snips will take care of any SSD. Depending on any company's security algorithms seems fraught, when you really want security.
    – Wayfaring Stranger
    Sep 3, 2019 at 23:23

2 Answers 2

Reset to default
4

The answer Apple implies:

You don't have to worry about that, since each file's data is not stored contiguously in the drive, but spread out across several physical and logical blocks. Removing a file from the file table makes it nearly impossible to read with forensic software/hardware.

Sources: About Apple File System | Apple File System Reference

The answer that may or may not work:

brew install coreutils
shred Secrets.txt

The documentation for shred doesn't explicitly call out APFS, but from what it says, it might be the case that the data is not necessarily overwritten.

If you wish to engage in determining this, there are contacts and other related links here: http://www.gnu.org/software/coreutils/

Improve this answer
5
  • Wil shred actualkly overwite the same cells in a SSD or just be like any other update to a file and use a new memory cell?
    – mmmmmm
    Sep 3, 2019 at 18:22
  • 1
    @historystamp OP never said several drives are being used, and neither did I. In an SSD, logical blocks aren't necessarily physical blocks; the drive's controller might split them up to reduce wear. It does not depend on the file type; as far as the file system cares, it's all just binary data blobs. The importance of the data is irrelevant to this question.
    – Ky -
    Sep 3, 2019 at 23:50
  • @Mark The full documentation for shred, including exceptions, is here: gnu.org/software/coreutils/manual/html_node/… - They don't explicitly call out APFS, but from what they say, it might be the case that the data is not necessarily overwritten. There are contacts and other related links here: gnu.org/software/coreutils
    – Ky -
    Sep 3, 2019 at 23:55
  • 2
    With APFS being copy-on-write, shred trying to overwrite the file might just write those bytes in unpredictable places on the physical disk, particularly since it doesn't explicitly work with APFS to overwrite the right location. It's also not helpful to claim it's impossible to recover files from APFS anyway: besides that not being the question, plenty of files (think of private ssh keys or a password you temporarily stored in a .txt) would easily fit in one physical/logical block.
    – Luc
    May 24 at 11:19
  • @Luc Agreed wholeheartedly
    – Ky -
    May 26 at 21:06
0

This is not necessary

This is not related to APFS, or any file system for that matter, but to the actual hardware itself of the storage device. When a “delete” command is issued, the device immediately marks the blocks as “unused and ready for data”. Additionally depending on the firmware of the device, any read instruction will return random data, ones or zeros.

Now, add that to the way APFS stores and manages files, something that was next to impossible in APFS is now made even more so just by the nature of the hardware. The only way to make this more secure is to enable FileVault encryption.

If you happen to be using TSM (Traditional Spinning Media; aka a hard drive), the native commands (detailed in the links above) are still available.

Further Reading…

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .