Sinn von SecureString/ Sicherheit des .Net Frameworks

Integer kommen als Integer, also 4 Bytes hintereinander, vor.

Ach ja, stimmt. Vergessen...
Aber sehe ich das mit dem SecureString richtig?

Der SecureString wird laut Beschreibung "verschlüsselt". Selbstverständlich kann es keine Verschlüsselung in dem Sinne sein, weil man ja kein Passwort angibt, es handelt sich wohl mehr um eine Unkenntlichmachung. Das wird aber vermutlich ausreichen, um den String vor solchen generischen Suchalgorithmen zu verstecken, manuell kann man ihn natürlich immer auslesen (wenn man die "Verschlüsselung" kennt, die sollte man aber in den Framework-Assemblies finden). Außerdem verbleibt der SecureString nicht wie der normale String wirklich nur so lange im Speicher, wie er gebraucht wird, der normale String kann nicht vom GarbageCollector freigegeben werden.

Artentus schrieb:

[...]der normale String kann nicht vom GarbageCollector freigegeben werden.

Ach, das ist jetzt aber interessant. Wieso schafft das der GC denn nicht? Bei anderen Klassen als dem String schafft er es ja auch(Genau: Noch 'ne kurze Zwischenfrage: Bei IDisposable-implementirenden Objekten kann der GC die denn nicht selbst disposen? A la: Prüfen, ob nicht referenziertes Objekt IDisposable implementiert - wenn ja: disposen). Auch Strukturen werden doch zuverlässig freigegeben. Warum funktioniert das bei Strings nicht? Oder wird das erst veranlasst, wenn das Programm selbst beendet wird(So ein Finalize-Ritual :P)?

MSDN schrieb:

Eine Instanz der System.String-Klasse ist unveränderlich und kann, wenn sie nicht mehr benötigt wird, nicht programmgesteuert für die Garbage Collection geplant werden. Dies bedeutet, dass die Instanz nach dem Erstellen schreibgeschützt ist und dass nicht vorhersagbar ist, wann die Instanz aus dem Computerspeicher gelöscht wird. Wenn ein String-Objekt vertrauliche Informationen wie Kennwörter, Kreditkartennummern oder persönliche Daten enthält, besteht daher ein Risiko, dass nach der Verwendung auf die Informationen zugegriffen werden kann, da die Anwendung die Daten nicht aus dem Computerspeicher löschen kann.

msdn.microsoft.com/de-de/libra…curestring(v=vs.110).aspx

Higlav schrieb:

Bei IDisposable-implementirenden Objekten kann der GC die denn nicht selbst disposen?

Die Objekte selbst schon, der GC kann jedes Framework-Objekt disposen (außer es wurde entsprechend markiert). IDisposable implementiert man dann, wenn man auf externe Ressourcen wie z.B. COM-Objekte verweise, die der GC nicht disposen kann.

Ich werde versuchen, dich nicht länger mit Fragen zu löchern, die ich auch einfach hätte ergooglen können.
Allerdings leuchtet mir deine letzte Erklärung nicht ganz ein. Vielleicht verstehe ich es ja auch aus einem anderen Grund nicht, aber nach meinem Verständnis müsst Folgendes doch möglich sein:

GC findet nicht-referenziertes Objekt
GC prüft, ob das Objekt ein COM-Objekt ist
Wenn ja, Marshal.ReleaseComObject(Obj), beenden
Wenn nein:
GC prüft, ob das Objekt IDIsposable implementiert
Wenn ja, DirectCast(Obj, IDisposable).Dispose, beenden
Wenn nein:
GC löscht Objekt aus dem Speicher(normaler Weg)

Wo ist mein Denkfehler?

Ein COM-Objekt kann nur aus dem Thread zerstört werden, in dem es erzeugt wurde (so wie bei allen Aktionen mit COM-Objekten), der GC läuft aber in einem anderen Thread. Außerdem ist nicht alles ein COM-Objekt, z.B. GDI-Handles und dergleichen.
Dein Einwand, dass der GC auf IDisposable prüfen könnte, ist jedoch berechtigt. Tatsächlich wird das aber anders gelöst, bzw. nach IDisposable-Patterns sollte es zumindest anders gelöst werden. Gedacht ist es so, dass du den Finalizer/Destruktor so überschreibst, dass Dispose aufgerufen wird: msdn.microsoft.com/en-us/libra…0).aspx#finalizable_types

Ahh. Jetzt ist's auch mir klar. Und da die SyncronizationContext-Klassen nicht so gebaut wurden, dass man sie ohne Weiteres für jeden Thread anwenden kann(bez. keine aufwändige Lösung für das threadspezifische Ausführen von Code existiert), kann der GC das ja gar nicht tun, auch wenn er die Dispose-Methode aufrufen würde, da dies dann aus seinem Thread geschehen würde, oder?
Ich sehe gerade, ich habe in dem Fall mich nie der Dipose-Kultur des DotNet-Frameworks geöffnet(aus Unwissenheit). Ich muss das anscheinend bei Gelegenheit mal durchlesen.

EDIT: Krieg'sch von mir deine 900ste Hilfreich-Bewertung - Glückwunsch!

Higlav schrieb:

kann der GC das ja gar nicht tun

Richtig, da muss man sich dann selbst drum kümmern.

@Higlav
Ein Handle ist lediglich ein Identifer für'n Fenster, somit kann das System diese handhaben. Grundsätzlich kannst du mit dem Fensterhandle schonmal das gesamte Fenster kontrollieren. Controls hinzufügen/entfernen, Größe ändern, Text setzen etc. man kann einfach stumpf Nachrichten senden. Man kann auch mal ebend ne Funktion in den Speicher des fremden Prozesses schreiben und dann aufrufen und somit direkt auf den Speicher des Prozesses zugreifen. Meistens reicht's die Anwendung zu disassemblieren und sich durch die ganzen Methoden zu wühlen und abzuändern. Strings im Klartext sind sofort sichtbar (s. PEViewer). Sowas bietet nicht mehr Sicherheit. Das soll's ja auch garnicht