[tscs37]

If you want to get rid of a harddrive with sensitive data I would first suggest that one gets familiar with the thought of not being able to sell it as used.

Personally for my drives, I use Boot and Nuke to erase the drive three times, first with zeroes, then with random data, then with zeroes again. After that I disassemble the drive, put a strong magnet over each platter, shredder the drive into almost powder, burn the pieces in a fire and then throw away the leftovers. Probably overkill but I want to be certain.

[readams]

Normally you'd want to throw the remains into a volcano but I guess if you feel safe just throwing it away then you do you.

[Spooky23]

You jest, but jackass security people would probably be dissatisfied that your PII might be accessible to some alien race when after the earth explodes in 5 billion years and some remanent of data is somehow recoverable from an asteroid made of cooled lava.

I recall one datacenter consolidation project where the hard drives from decommissioned servers were zapped with a degaussing device, shredded, and then somebody signed off that they were dumped in a furnace somewhere. (At some ridiculous expense)

Meanwhile, the normal operation bins of drives that were in little blue bins for collection where just picked up and moved by the moving men, and are probably still in some closet in the new facility!

[PuffinBlue]

I failed an audit once because the inspection team managed to recover data from the information encoded on the event horizon of a nearby black hole.

Can't be too careful nowadays.

[QAPereo]

Another good worker screwed by the holographic principle.

Edit: wow... that joke went badly.

[ben-schaaf]

There's a great defcon talk exploring different methods to completely destroy a drive: https://www.youtube.com/watch?v=-bpX8YvNg6Y.

[qubex]

He forgot to mention he has purchased a steel foundry for the triennial purpose of zeroed-out drive disposal.

[js2]

Or nuke the entire site from orbit... it's the only way to be sure.

[visarga]

In India we use elephants for 100% certainty.

[Agathos]

Not a good idea. Elephants never forget.

[maxxxxx]

Don't forget to check that the volcano is active!

[keithpeter]

How about whole disk encryption?

When it is time to move on, one simply forgets the passphrase and reformats the drive.

Seriously: that is what I'm doing with ssd drives. Anyone know of any issues?

[forapurpose]

Self-encrypting drives (SEDs) have this function built in:

1. Everything stored on the drive is always encrypted when at rest.

2. The drive has some sort of firmware, memory and microprocessor that stores a key and en/de-crypts data in transit to/from storage.

3. To 'erase' the drive, the SED simply erases the key.

Of course there are many potential flaws in implementation, but conceptually it's simple. And as with most drive encryption solutions, the fatal flaw is that the data is available if the computer is on or asleep, which means that for most users the security is disabled 99% of the time (but that problem doesn't apply to drive wiping).

AFAIK: Many common drives have SED functionality. Until the user "locks" the drive, the data is en/decrypted invisibly to the user and system. Locking the drive creates a passphrase and a pre-boot environment for authentication. Locking the drive requires an OS-level utility. Opal by TCG (the same people who provide the TPM spec) is the common standard.

[rgbrenner]

a lot of ssds already encrypt the data using aes... and you can send a command to the drive telling it to erase the key.

better because it's harder to bruteforce an aes key than a passphrase.

[akvadrako]

Well your password could be brute-forced unless it's really long and random (about 20 chars). There might also be flaws in the encryption code. And changing it later won't work, because old sectors might still be recoverable, even if they are overwritten.

[derefr]

Usually with full-disk encryption, your supplied encryption passphrase is used to encrypt a single sector (or redundant set of sectors, spread across the disk) containing a much larger master key, which is in turn used to encrypt the rest of the sectors. When you change the disk password at the OS level, the master key remains the same (which is why you don't have to wait for the disk itself to re-encrypt); the single sector containing the key is just re-written to be encrypted with your new password.

Later, when you actually reformat the drive, you (or your OS) should spend some extra time writing over the sector(s) containing your encrypted FDE master key. But only those sector(s) need to be securely wiped. Even if someone can brute-force the password you used, they won't have that sector to use to turn it into a decryption key for the sectors; and they definitely won't be able to brute-force the FDE master key itself.

And, to make matters better, in systems with a TPM (most, these days), the TPM holds the FDE master key, and does the job of "shredding" it when it's no longer needed itself, as an async job kicked off by the OS along with the reformat. Also, in such systems, the FDE master key is never loaded into RAM, because the TPM itself does the sector-wise encryption/decryption as a DMA process.

[akvadrako]

You can overwrite a physical sector in modern drives, at least not in a standard way. That’s because they contain internal controllers that map physical to virtual sectors.

[keithpeter]

Yes, I'm assuming that if I 'write zeros' over the SSD when parting with the device that I have destroyed the keys.

[keithpeter]

I take the point, and my passphrase is a phrase so perhaps subject to dictionary attack of a sophisticated nature. At the end of the day, this is all about the level of risk one expects. Mine is 'don't want some random petty thief finding my credit card number' rather than 'don't want some government agency reading my old emails'.

[Turing_Machine]

A friend of mine who was a military secure comms guy back in the 80s told me that if their position was about to be overrun the procedure was:

1) Fire a twelve gauge shotgun slug into the drive (these would have been external drives).

2) Place a thermite grenade on drive, pull pin.

3) Bug out.

[tscs37]

I wouldn't bet on that being a 100% deletion. It'll probably trash most of the data but not all.

Thermite grenades aren't very good at melting a huge chunk of metal either, sure it'll go straight through a machine block but it won't melt the entire machine block.

To destroy all data on a harddrive all parts of the platter must be destroyed and heated to their Curie point.

[Turing_Machine]

A hard drive has orders of magnitude less mass than an engine block.

There's going to be nothing left of a drive but a puddle of molten metal after it's had a thermite grenade burn on it.

[tscs37]

If you check research related to this and the DEFCON talk where somebody actually put thermite into the drive, there won't be a puddle of molten metal.

You can put thermite on it once you burned the parts if you want.

[Turing_Machine]

The DEFCON guy used 15 grams of thermite. An AN-M14 TH3 incendiary grenade contains ~750 grams of thermite (technically thermate). Those are two different things. Entirely.

[Turing_Machine]

Here's what 1 kg of thermite does to a hard drive:

https://www.youtube.com/watch?v=3lnqeodIIUw

I'm comfortable that the Curie temperature has been exceeded for all of those platters. :-)

[tscs37]

Good luck getting that into a datacenter.

[Houshalter]

Terry Pratchett had all his unpublished works destroyed with an antique steam roller: http://mashable.com/2017/08/30/terry-pratchett-hard-drive-st...

Any chance that could be recovered?

[tscs37]

I would say the chance of recovering any data is bigger than 0, yes.

[QAPereo]

You throw away the leftovers instead of vitrification and firing the mass into space? /s

[qubex]

A tokamak or a stellerator are also fit for purpose. The advantage is that the toridial magnetic fields that contain the fusion plasma also give the surviving bits another good hammering before vaporisation.

[QAPereo]

That’s good thinking, but only until we find the nearest black hole!