Announcement

Collapse
No announcement yet.

Textdatei (Inhalt) sicher löschen?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Textdatei (Inhalt) sicher löschen?

    Hallo,

    ich bin nicht sicher, ob's hier reingehört, wenn nicht ist einer der Mods so nett und verschiebt es bitte.

    Ich möchte eine Textdatei (nur ein Passwort enthalten) so löschen, daß die Wiederherstellung auch mit entsprechenden Tools nicht mehr möglich ist.

    Um das einfach zu lösen, dachte ich mir, ich überschreibe das Passwort in der Textdatei mehrmals mit Zufallswerten und lösche die Datei dann.

    Ist das eine zuverlässige Methode? Oder Pseudosicherheit?
    Nach meiner Vorstellung ist dann zwar die Datei noch herstellbar, aber nicht mehr mit dem ursprünglichen Inhalt.

    Muß ich noch etwas beachten?
    Zum Beispiel wieviel mal ich den Wert überschreiben lassen müßte...?
    ich würde das 10 mal überschreiben lassen, so wie es übliche Shredder-Software auf höchster Stufe macht.

    MFG John

  • #2
    Hallo,

    AFAIK reicht es auch wenn jedes Byte der Datei mit null besetzt wird und die Datei ist nicht mehr wiederherstellbar (auf RAID-Systemen ev. schon genauso durch ev. Schattenkopien).

    Das mit dem mehrmaligen Überschreiben mit Müll war früher als die Festplatten noch nicht so dicht beschrieben waren...aber das hat sich ja geändert


    mfG Gü
    "Any fool can write code that a computer can understand. Good programmers write code that humans can understand". - Martin Fowler

    Comment


    • #3
      Originally posted by John68 View Post
      Zum Beispiel wieviel mal ich den Wert überschreiben lassen müßte...?
      ich würde das 10 mal überschreiben lassen, so wie es übliche Shredder-Software auf höchster Stufe macht.
      Ich glaube es gab ne Untersuchung das eine mit 0 überschrieben Datei pro Bit mit 50,001% der korrekte inhalt diesers Bit wiederherstellbar ist (Wahrscheinlichkeit einfach zu Raten ist bei 50,000%).

      Ach ja. Mit so einem Überschreiben wirst du im Firmenumfeld natürlich nicht die vorhandenen Backups überschreiben können :-)

      Comment


      • #4
        Das sicherste wäre wohl das Passwort einfach nicht als Klartext zu speichern.

        Ist das eine zuverlässige Methode? Oder Pseudosicherheit?
        Wie schreibst du das File wieder auf die Platte und in welches Dateisystem? Wenn du einfach die Datei änderst und wieder über die normale Write API auf Platte schreibst wird die in den meisten Konstellationen die Datei woanders auf der Platte landen und die Ursprungsversion einfach nur dereferenziert. Ein solches vorgehen ist also als Wiederherstellungsschutz sinnfrei.

        Um wirklich die richtige Stelle auf der Platte zu überschreiben benutzen die Tools zum sicheren löschen üblicherweise die API die auch zum Defragmentieren (die muss ja naturgemäß absolut positionieren können) verwendet wird zum überschreiben.

        Wenn du den Soucecode von Systinternals SDelete irgendwo noch im Netz findest (der war mal frei zugänglich) kannst du dir ansehen wie man das machen könnte.

        Comment


        • #5
          Hallo,

          Das sicherste wäre wohl das Passwort einfach nicht als Klartext zu speichern.
          So ist es. Das Problem an der Wurzel packen



          Anstatt das selber zu coden gleich ein Tool nehmen...


          mfG Gü
          "Any fool can write code that a computer can understand. Good programmers write code that humans can understand". - Martin Fowler

          Comment


          • #6
            Danke erstmal euch allen für die Antworten...

            Ach ja. Mit so einem Überschreiben wirst du im Firmenumfeld natürlich nicht die vorhandenen Backups überschreiben können :-)
            Dessen bin ich mir bewußt. Im aktuellen Project-Szenario wird es keine automatisierten Backups geben, ausser Sicherheitskopie im Safe.


            Das sicherste wäre wohl das Passwort einfach nicht als Klartext zu speichern.
            In aktuellen Project sind Daten in einer Datenbank mit AES 128bit verschlüsselt gespeichert.
            Ich habe ein starkes Passwort gewählt, dessen manuelle Eingabe aus verschiedenen Gründen nicht möglich ist. Deshalb speichere ich es in einer Textdatei auf einem USB-Stick, der hinter einem Glaskasten hängt und per Anordung nur im Notfall zu verwenden ist. Der Rechner ist nicht vernetzt und das Gehäuse versiegelt. (Ich könnte es auch notieren und in enem versiegelten Kuvert hinterlegen. Aber so hat man im Notfall die fehleranfällige Eingabe des langen Passwortes gespart.)

            Wenn ich das Passwort dort nun wieder verschlüssele, habe ich ja schon wieder ein Passwort für diese Verschlüsselung. Und dann?
            Die Vorgabe verlangt eine AES 128 bit Verschlüsselung.


            Wie schreibst du das File wieder auf die Platte und in welches Dateisystem? Wenn du einfach die Datei änderst und wieder über die normale Write API auf Platte schreibst wird die in den meisten Konstellationen die Datei woanders auf der Platte landen und die Ursprungsversion einfach nur dereferenziert.
            @Ralf Das habe ich mir schon so ähnlich gedacht. Zu Deiner Frage Dateisystem USB-Stick FAT32. Ich wollte zum Überschreiben einfach IO.Streamwriter und WriteLine verwenden. Vor jedem Überschreiben die Datei öffnen und wieder schließen. Und hier dachte ich, daß mit dem mehrmaligen Überschreiben die Referenzierung zur Ursprungsversion und evt. zu zwischengespeicherten Cacheversionen irgendwann mal zu Ende ist. Ich kann halt nicht einschätzen wann sie zu Ende ist...
            ...und natürlich ob ich überhaupt auf dem richtigen Weg bin.

            Den Link zu SDelete schau ich mir in jedem Fall mal näher an.



            Momentan verfahre ich so, daß der Stick nach einer Benutzung physisch zerstört wird. Die Daten in der Datenbank werden neu verschlüsselt und ein neuer Stick mit neuem Passwort muß her. Ich kann darauf hier nicht näher eingehen, aber es spielen hier auch rechtliche Anforderungen und Vorgaben eine Rolle.

            Programmtechnisch interessiert es mich aber dennoch, da ich in meiner BaseClass eine sichere Löschfunktion einbauen wollte, die in zukünftigen Projekten nutzbar wäre...


            Anstatt das selber zu coden gleich ein Tool nehmen...
            @gfoidl Wenn's kostenpflichtig ist, kann ich auch den Stick opfern...
            Nee, im Ernst... interessiert mich ja auch programmtechnisch. Aber wie immer halt alles nicht so einfach...

            mfg John

            Comment


            • #7
              Hallo,

              zum Sicherheitsaspekt hatten wir mal eine Diskussion zu Screenshoot unterbinden. Vielleicht interessierts dich.
              Kurz: Die Datenbank kann noch so gut geschützt sein - es gibt einfache Mittel dennoch an die Daten zu kommen (keine Hackerkentnisse notwendig)


              mfG Gü
              "Any fool can write code that a computer can understand. Good programmers write code that humans can understand". - Martin Fowler

              Comment


              • #8
                Mein eigener Post @Ralf ...Und hier dachte ich, daß mit dem mehrmaligen Überschreiben die Referenzierung zur Ursprungsversion und evt. zu zwischengespeicherten Cacheversionen irgendwann mal zu Ende ist. Ich kann halt nicht einschätzen wann sie zu Ende ist...
                Das ist natürlich absoluter Müll. Ich habs selbst erkannt... Aber ich verzeih es mir selbst...

                Noch zur Erklärung. Wenn die Datenbank nach Benutzung mit neuem Passwort verschlüsselt wird, ist es ja eigentlich unlogisch das alte Passwort so beharrlich vernichten zu wollen... Dies zu erklären würde aber hier den Rahmen sprengen... Es ist aber tatsächlich eine Vorgabe...

                Hab ich gelesen. Ich find solche Discussionen auch mal interessant.

                es gibt einfache Mittel dennoch an die Daten zu kommen (keine Hackerkentnisse notwendig)
                Gewaltfantasien?

                mfg John

                Comment


                • #9
                  Bin ja auch nicht der einzigste der solche Überlegungen anstellt.

                  http://www.vb-archiv.de/tipps/tipp_1...-loeschen.html

                  mfg John

                  Comment

                  Working...
                  X