According to the documentation for the "diskscrb" command for wiping conventional hard drives: http://www.forensics-intl.com/diskscrb.html

"Conforms to and exceeds the Government Standard set forth in DoD 5220.22-M. Can overwrite ambient data areas 9 times. (Each pass involves 3 separate writes followed by a verify pass.) This helps eliminate the potentials for the recovery of Shadow Data."

So it's ok to wipe the HDD's at least the mentioned 9 times, but how about SSD's, USB FLASH drives? Do I have to wipe the data from them 9 times, or it's only needed once?

Here is what I use to regularly delete the data from my memory cards, usb flashdrives, etc.: [I start it in the evening, and stop in the the morning, e.g.: it overwrites my usb flash drive 10 times]:

while [ 1 = 1 ]; 
do (( loopcountdd= $loopcountdd + 1 )); 
dd if=/dev/urandom bs=4096 | pv | dd bs=4096 of=/dev/XXX; 
echo "overwritten: $loopcountdd x"; 

This question was IT Security Question of the Week.
Read the Aug 3, 2011 blog entry for more details or submit your own Question of the Week.


Best stop doing that. Never overwrite an SSD/flash storage device completely in order to erase it, except as a last resort.

NVRAM has a limited amount of write cycles available. At some point, after enough writes to an NVRAM cell, it will completely stop working. For modern versions, we're in the ballpark of an estimated lifespan of 3,000 write cycles.

Furthermore, internally SSDs look nothing like traditional harddisks. SSDs have the following unique properties:

  • Spare area, often on the order of 8% - 20% of the total flash is set aside for wear leveling purposes. The end user cannot write to this spare area with usual tools, it is reserved for the SSDs controller. But the spare area can hold (smaller) amounts of old user data.

  • A "Flash Translation Layer", FTL. How your operating system 'sees' the SSD (LBA addresses) and the actual NVRAM address space layout has no correlation at all.

  • Very heavy writing to a consumer-grade SSD may bring the controller's garbage collection algorithm behind, and put the controller into a state of reduced performance. What happens then depends on the controller. In an extreme worst case scenario, it cannot recover performance. In a much more likely scenario it will slowly regain performance as the operating system sends "trim" commands.

Lastly, from the conclusion of the paper "Reliably Erasing Data From Flash-Based Solid State Drives": "For sanitizing entire disks, [...] software techniques work most, but not all, of the time."

So when you're completely overwriting flash storage, you may be performing an effective secure wipe -- but, you may also be missing some bits. And you're certainly consuming quite much of the drives expected life span. This isn't a good solution.

So, what should we be doing?

  • The 'best' modern drives support a vendor-specific secure erase functionality. Examples of this are Intels new 320 series, and some Sandforce 22xx based drives, and many SSDs which are advertised as having "Full Disk Encryption" or "Self Encrypting Drive". The method is generally something along the lines of:

    1. The SSD controller contains a full hardware crypto engine, for example using AES 128.
    2. Upon first initialization, the controller generates a random AES key, and stores this in a private location in NVRAM.
    3. All data ever written to the drive is encrypted with the above AES key.
    4. If/when an end user performs a secure wipe, the drive discards the AES key, generates a new one, and overwrites the old AES key position in the NVRAM. Assuming the old AES key cannot be recovered this effectively renders the old data un-recoverable.
  • Some drives don't have the above, but do support the ATA Secure Erase commands. This is were it gets more tricky -- essentially we're relying on the drive manufacturer to implement a 'strong' secure erase. But it's a black box, we don't know what they're actually doing. If you need high security, then you should not rely on this, or at least you should read the tech docs and/or contact the drive manufacturer to verify how secure their method is. A fair guess as to what they're doing / ought to be doing is that:

    1. While the drive isn't using a full cryptographic cipher such as AES, it is still using extensive data compression algorithms & checksumming & RAID-like striping of data across multiple banks of NVRAM. (All modern high-performance SSDs use variants of these techniques.) This obfuscates the user data on the drive.
    2. Upon receiving an ATA Secure Erase command, the drive erases its "Flash Translation Layer" table, and other internal data structures, and marks all NVRAM as free'd.

My personal recommendations:

  1. If you just need an in-secure wipe of an SSD, then use the manufacturer's end user tools, or use the ATA Secure Erase command via for example HDPARM on Linux.

  2. If you need secure wipe then either:

    • Only use drives which explicitly advertise secure wipe via strong (AES) encryption, and run the manufacturers secure wipe. and/or:
    • Ensure that all data you write to the drive is encrypted before hitting the drive. Typically via software full disk encryption such as PGP Whole Disk Encryption, Truecrypt, Microsoft BitLocker, Bitlocker-to-Go, OSX 10.7 FileVault or LUKS. or:
    • Physically destroy the drive.

SSD's and Flash drives are an interesting problem... As @Bell pointed out as a response to this question:

Yes, the effectiveness of the shredding operation is dependent on a fixed or physical mapping between a block number and piece of non-volatile storage. This works for spinning media but not for SSDs which virtaulise their blocks for performance and lifecycle reasons. So the shredding model is ineffective on SSDs (and many SANs for that matter). The more interesting thing is that the persistence of data in free space on an SSD is completely unpredictable. It may also get completely erased in the absence of a scrubbing operation through the drive's free space preparation process

Some better SSD's and flash drives provide security functionality to carry out a secure delete (usually by bypassing the lifecycle/performance addressing mechanism) so that would be recommended if you do have sensitive data which you need to delete, but be aware it will impact the lifespan of the device.

An ordinary overwrite will not be reliable.

  • 2
    As the paper JesperMortensen linked demonstrates, the majority of SSDs which advertise "secure delete" functions do nothing of the sort. If you have sensitive data to write to an SSD, write it to an encrypted volume. That includes temp files, caches, buffers, et. al. – user502 Jul 26 '11 at 12:14

First of all, a single overwrite is adequate for all current magnetic hard drives. It has never been as easy to recover information from drives as people have claimed.

Second of all, you can't erase flash drives simply by overwriting them. You'll wear them out with overwrites long before you actually overwrite all the data. The only way you can be absolutely sure is to encrypt the data on the flash drive in the first place, so that you don't care fragments are left around undeleted.

  • 1
    If no bad block reallocation occurs, a simple fill all space with junk data will overwrite all data on it. If a sector is reallocated, it happens because of a technical problem so it's not that likely that you will be able to read from it anyway. – Overmind Sep 17 '18 at 12:51
  • @Overmind This is incorrect due to the existence of over-provisioning space. – forest May 3 at 3:19

protected by Community Nov 4 '14 at 20:28

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.