it-swarm.com.de

So vermeiden Sie die Verwendung von System.String mit Rfc2898DeriveBytes in C #

Ich erstelle eine .NET-Kernwebanwendung in C #, die ein Benutzerkennwort aufnimmt und es hascht, um es auf einem Server zu speichern. Ich benutze Rfc2898DeriveBytes Zusammen mit einem zufällig erzeugten Salz. Ich habe jedoch gelesen, dass ich die Verwendung von Zeichenfolgen im gesamten Prozess vermeiden sollte, da Zeichenfolgen nicht aus dem Speicher entfernt werden können. Ich weiß, dass der .NET-Kern ein PasswordBox hat, das das Passwort als SecureString behält, aber SecureStrings kann nicht in ein Byte-Array konvertiert werden, um an Rfc2898DeriveBytes 's Konstrukteur ohne viele Spielereien.

Da die Webanwendung nur auf meinem Server ausgeführt wird, kann ich die SecureString einfach wieder in eine Zeichenfolge konvertieren, sobald sie an meine Webanwendung übergeben wurde? Wenn es einem Angreifer gelingt, auf die RAM] des Servers zuzugreifen, um nach einer nicht gelöschten Zeichenfolge zu suchen, kann ich wahrscheinlich zunächst nur sehr wenig tun, um etwas zu schützen.

Wenn ich trotzdem SecureStrings verwenden sollte, was sind die Best Practices für das Hashing, um es zu speichern?

27
Jeff

Die korrekte Verwendung von SecureString ist schwierig und schützt vor einer Bedrohungsoberfläche, die für die meisten Anwendungsfälle unwahrscheinlich ist. Wie Sie sagen, wenn ein Angreifer Ihr Gedächtnis lesen kann, haben Sie andere Probleme. Ich würde empfehlen, normale Zeichenfolgen anstelle von SecureString zu verwenden, es sei denn, Sie sind besorgt über Angreifer mit flüssigem Stickstoff mit physischem Zugriff auf Ihren Server.

Wenn Sie SecureStrings wirklich verwenden möchten, sollten Sie die Windows-Krypto-API aufrufen, damit Sie die Kontrolle über den Speicher haben. Ich habe ein Beispiel in meinem Blog-Beitrag Vergleichen sicherer Zeichenfolgen in .NET .

34
Sjoerd

Das .NET Core-Team empfiehlt ausdrücklich, SecureString nicht für neue Entwicklungen zu verwenden. Siehe die Dokumentation zu SecureString :

Es wird nicht empfohlen, die SecureString-Klasse für Neuentwicklungen zu verwenden. Weitere Informationen finden Sie unter . SecureString sollte auf GitHub nicht verwendet werden .

sowie die Argumentation des Teams zu GitHub :

Motivation

  • Der Zweck von SecureString besteht darin, zu vermeiden, dass Geheimnisse als einfacher Text im Prozessspeicher gespeichert werden.
  • Selbst unter Windows existiert SecureString jedoch nicht als Betriebssystemkonzept.
    • Dadurch wird das Fenster nur kürzer. Dies wird nicht vollständig verhindert, da .NET die Zeichenfolge weiterhin in eine Nur-Text-Darstellung konvertieren muss.
    • Der Vorteil ist, dass die Klartextdarstellung nicht als Instanz von System.String Herumhängt - die Lebensdauer des nativen Puffers ist kürzer.
  • Der Inhalt des Arrays ist außer in .NET Framework unverschlüsselt.
    • In .NET Framework wird der Inhalt des internen char-Arrays verschlüsselt. .NET unterstützt die Verschlüsselung nicht in allen Umgebungen, weder aufgrund fehlender APIs noch aufgrund von Problemen bei der Schlüsselverwaltung.
49
Vivelin