4 ms·

hdparm --secure-erase-enhanced run from any Linux install .iso is faster than DBAN or dd. https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase https://ata.wik

hdparm --secure-erase-enhanced run from any Linux install .iso is faster than DBAN or dd. https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

DanBC 12y ago
Also, DBAN doesn't touch sectors marked as bad.
sp332 12y ago
That is the only NIST-approved method for erasing a drive securely. http://security.stackexchange.com/a/5784/3714 http://security.stackexchange.com/a/5784/3714 Trying to overwrite data yourself will miss data in areas of the drive reserved for various reasons by the firmware, and you don't have control over caches etc. ATA Secure Erase is your best bet for clearing all of those.
- schoen 12y ago
  I think there's a problem that at least one drive claimed at an ATA level to implement Secure Erase, and then didn't actually perform an erase of the drive medium. I'll try to find the reference to that.
  - schoen 12y ago
    Wei et al. (FAST '11), discussing solid-state drives: "Drive B’s behavior is the most disturbing: it reported that sanitization was successful, but all the data remained intact. In fact, the filesystem was still mountable. Two more drives suffered a bug that prevented the ERASE UNIT command from working unless the drive firmware was recently reset, otherwise the command would only erase the first LBA. However, they accurately reported that the command failed. The wide variance among the drives leads us to conclude that each implementation of the security commands must be individually tested before it can be trusted to properly sanitize the drive." https://www.usenix.org/legacy/events/fast11/tech/full_papers/Wei.pdf https://www.usenix.org/legacy/events/fast11/tech/full_papers...
    - dobbsbob 12y ago
      There's a good stack exchange post about ATA secure erase pitfalls too, how if you just do --secure-erase and not enhanced option then some SSDs will just compress the data and not actually wipe anything. Found it: http://security.stackexchange.com/a/64480 http://security.stackexchange.com/a/64480
- tedks 12y ago
  Who cares if it's NIST-approved? The NSA owns NIST entirely; if something is NIST approved it's probably a good reason to not use it.
  - sp332 12y ago
    This guidance has been around since 2006 and I don't remember anyone having a better idea since then.
    - tedks 12y ago
      I think knowing that the NSA has some influence on NIST means you have to treat all actions by NIST as possibly the result of NSA pressure, and thus treat everything NIST does as suspect.
  - eksith 12y ago
    The safe bet may be a line from authority itself: "Trust, but verify" as they say. Right now, the only antidote to systemic weakening (potential or actual, intentional or through incompetence) of security is an auditing of code along with these standards and practices. It's been mentioned before here and many places elsewhere, but the fork of OpenSSL by the OpenBSD folks and their complete scuttling of cruft, including FIPS 140-2 which required the backdoored Dual_EC_DRBG algo, is a good sign that at least some people are taking a proactive approach to security. In lieu of blindly following existing procedures, seeing what breaks in your work when subjected to extreme duress leads to better software and better practices.

hdparm --secure-erase-enhanced run from any Linux install .iso is faster than DBAN or dd. https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

DanBC 12y ago

Also, DBAN doesn't touch sectors marked as bad.

sp332 12y ago

That is the only NIST-approved method for erasing a drive securely. http://security.stackexchange.com/a/5784/3714 http://security.stackexchange.com/a/5784/3714 Trying to overwrite data yourself will miss data in areas of the drive reserved for various reasons by the firmware, and you don't have control over caches etc. ATA Secure Erase is your best bet for clearing all of those.

schoen 12y ago
I think there's a problem that at least one drive claimed at an ATA level to implement Secure Erase, and then didn't actually perform an erase of the drive medium. I'll try to find the reference to that.
- schoen 12y ago
  Wei et al. (FAST '11), discussing solid-state drives: "Drive B’s behavior is the most disturbing: it reported that sanitization was successful, but all the data remained intact. In fact, the filesystem was still mountable. Two more drives suffered a bug that prevented the ERASE UNIT command from working unless the drive firmware was recently reset, otherwise the command would only erase the first LBA. However, they accurately reported that the command failed. The wide variance among the drives leads us to conclude that each implementation of the security commands must be individually tested before it can be trusted to properly sanitize the drive." https://www.usenix.org/legacy/events/fast11/tech/full_papers/Wei.pdf https://www.usenix.org/legacy/events/fast11/tech/full_papers...
  - dobbsbob 12y ago
    There's a good stack exchange post about ATA secure erase pitfalls too, how if you just do --secure-erase and not enhanced option then some SSDs will just compress the data and not actually wipe anything. Found it: http://security.stackexchange.com/a/64480 http://security.stackexchange.com/a/64480
tedks 12y ago
Who cares if it's NIST-approved? The NSA owns NIST entirely; if something is NIST approved it's probably a good reason to not use it.
- sp332 12y ago
  This guidance has been around since 2006 and I don't remember anyone having a better idea since then.
  - tedks 12y ago
    I think knowing that the NSA has some influence on NIST means you have to treat all actions by NIST as possibly the result of NSA pressure, and thus treat everything NIST does as suspect.
- eksith 12y ago
  The safe bet may be a line from authority itself: "Trust, but verify" as they say. Right now, the only antidote to systemic weakening (potential or actual, intentional or through incompetence) of security is an auditing of code along with these standards and practices. It's been mentioned before here and many places elsewhere, but the fork of OpenSSL by the OpenBSD folks and their complete scuttling of cruft, including FIPS 140-2 which required the backdoored Dual_EC_DRBG algo, is a good sign that at least some people are taking a proactive approach to security. In lieu of blindly following existing procedures, seeing what breaks in your work when subjected to extreme duress leads to better software and better practices.