Pages:
Author

Topic: Bad security advice again: shred - page 2. (Read 9272 times)

member
Activity: 98
Merit: 10
June 17, 2011, 05:29:58 PM
#2
so this is good news for the guy that used the shred command on his wallet?
full member
Activity: 168
Merit: 103
June 17, 2011, 05:01:23 PM
#1
After the bullshit advice that security noobs give here all the time about VMs and TrueCrypt, this time I will discuss shred.


Problem:
Destroying wallet.dat files with shred does not work.

Why?
That's not shred's fault. shred is just from another millenium. Modern operating systems use modern file systems, that don't store files at a fixed place any more. That has a lot of reasons that reach from performance improvement to better error correction after system crashes.
When you use shred on these filesystems (anything more modern than FAT and ext2), shred will write random data to the file - but that does not actually hit the disk at the spot where the file used to be. The original data of the file may survive that. For more details see the man page quotes below.

What does work?
shred is still useful - for example if you wipe out entire drives before creating new filesystems. If you don't want to wipe out your whole disk every time, you have to choose between a prehistoric file system or cryptography (which is not trivial).



Read the f****ing manual!
Quote
CAUTION: Note that shred relies on a very  important  assumption:  that
       the  file system overwrites data in place.  This is the traditional way
       to do things, but many modern file system designs do not  satisfy  this
       assumption.
  The following are examples of file systems on which shred
       is not effective, or is not guaranteed to be effective in all file sys‐
       tem modes:

       * log-structured or journaled file systems, such as those supplied with
       AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

       * file systems that write redundant data and  carry  on  even  if  some
       writes fail, such as RAID-based file systems

       *  file  systems  that  make snapshots, such as Network Appliance's NFS
       server

       * file systems that cache in temporary locations, such as NFS version 3
       clients

       * compressed file systems

       In  the  case  of  ext3 file systems, the above disclaimer applies (and
       shred is thus of limited  effectiveness)  only  in  data=journal  mode,
       which  journals  file  data  in addition to just metadata.  In both the
       data=ordered (default) and data=writeback modes, shred works as  usual.
       Ext3  journaling  modes  can  be  changed  by adding the data=something
       option to the mount  options  for  a  particular  file  system  in  the
       /etc/fstab file, as documented in the mount man page (man mount).

       In  addition, file system backups and remote mirrors may contain copies
       of the file that cannot be removed, and that will allow a shredded file
       to be recovered later.

GNU shred manual from Ubuntu 11.04
Pages:
Jump to: