Securestring-Klasse: Sensible Daten in .NET 2.0 besser schützen

Man mag sich fragen, warum die Securestring-Klasse nötig ist, wenn in .NET bereits die einfache String-Klasse zur Verfügung steht. Das Problem ist im Aufbau der String-Klasse begründet. Gibt es zum Beispiel eine Instanz der String-Klasse, die eine Sozialversicherungsnummer enthält, ist es ratsam, diese während der Anwendungsverarbeitung sicher zu speichern, um sie vor neugierigen Blicken zu schützen.

Das Problem ist eben dieses sichere Speichern von Text, da die String-Klasse diesen einfach als Text speichert. Um herauszufinden, wo die Daten gespeichert werden, sind einige Kenntnisse über .NET-Strings vonnöten.

.NET-Strings sind nicht veränderbar. Das heißt, dass jede Veränderung eines String-Wertes einen neuen String im Speicher erzeugt. Folglich befinden sich schnell mehrere Kopien sensibler Daten im Speicher, auf die gewissenlose Nutzer mit ebensolchen Programmen zugreifen können.

Dieser Ansatz ist nicht der effizienteste, und dies wiederum erklärt, warum es das Stringbuilder-Objekt gibt. Man mag glauben, dass das alles kein großes Problem ist, da es ja die automatische Speicherbereinigung gibt, aber die Speicherneubelegung bei String ist nicht plangleich mit der automatischen Speicherbereinigung von .NET. Die String-Klasse sollte also gemieden werden, wenn es um wirklich sensible Daten geht. Dafür bietet sich die Alternative der Securestring-Klasse an.